A cross indicating indicating a button to close the menu

Don’t build a cloud landing zone in the dark

‘Digital Transformation’ in its many forms is without doubt one of the most pressing objectives for almost all firms across every industry. Cloud migration is at the heart of creating any sort of digital environment or DevOps culture. But despite all the hype, commentary, white papers, consultancy firms advice, and dollars spent, it is still one of the most difficult challenges that most organisations are facing. My experience is mostly financial services related but I don’t believe the problems are exclusive to this sector. Everyone has security, data, legacy technology and budget constraints. ‘Getting to the cloud’ is the modern day industrial revolution and those who don’t start their journey in the most efficient and cost effective way are the ones who will suffer – potentially catastrophic consequences.

A ‘Landing Zone‘ in cloud terms is defined as, ‘A configured environment with a standard set of secured cloud infrastructure, policies, best practices, guidelines, and centrally managed services.’. Most large firms will adopt a multi cloud strategy and will require a landing zone for each provider, be it Amazon Web Services (AWS), Google Cloud Platform (GCP), Microsoft Azure (Azure) etc… This is an incredibly time consuming to build, resource heavy and experience reliant approach – something most companies don’t have the luxury of in house. In reality, the majority of firms are building their landing zones for the first time without access to battle hardened professional expertise. And with the best will in the world the likely outcome is going to be less than perfect. We are all either suffering from a lack of information on best practise or exactly the opposite, information overload. The result is that many organisations are now fumbling around in the dark trying to build just one landing zone, let alone one for each cloud solution provider (CSP).

Building a cloud landing zone can be daunting. Sometimes, at the start of the build, it doesn’t look too difficult. But as the project progresses, many companies find out that ignoring the devil-in-the-detail at the outset can be a significant barrier to success.

I often say that building a cloud landing zone is like you have just walked into an enormous, empty warehouse and were told to build a datacentre in there for your entire company. All you have is a single power supply terminating in one corner of the building. Everything else has to be built from scratch. Herein lies the challenge. Who are you? A network, storage or security engineer, a Linux admin or SQL DBA? Believe me when staring into this vast, empty space, you need to be all of the above and more.

  • What’s the plan?
  • Where do we start?
  • What have other people done?
  • What are the potential pitfalls?

If we take GCP, Azure or AWS for example, their cloud platforms are essentially a collection of 50+ individual products that need to be mastered and integrated for a successful outcome that can be managed, controlled and supported.

There are a number of common business challenges and questions when building a landing zone:

  • Should we go cloud native?
  • Open source?
  • Cloud agnostic?
  • Multi-cloud?
  • Do you mix some open source products with cloud native products and how will you choose?
  • How to encrypt everything – not only at-rest but on the wire?
  • How do we harden the default security?
  • How do we maintain our new cloud environment?
  • What happens when we need to upgrade?
  • How do we bill internally?
  • How do we follow ITIL with regards to permissions and change management etc?
  • How long will it take?

You might have already answered these questions for on-premises data centres – but this is based on knowledge the entire technology community has amassed over many many years. Very little of which relates to modern day cloud migration requirements.

The promise of cloud is to make provisioning simple, fast and cheap. It should enable developers to become highly productive very quickly – many aim to adopt DevOps (and FinOps etc.). CSPs can be amazing development environments, if you complete the necessary building blocks using tried and tested best practice techniques.

In order to adopt a positive DevOps culture you need to consider the following:

  • How will developers deploy their infrastructure in this environment?
  • How can you be agile and let them deploy what they need, when they need it, but still maintain control?
  • You don’t want a different setup (or datacentre!) for each team.
  • If you work in a regulated environment, how will you demonstrate that this is under control, and secure?
  • How to get the account structure correct with least-privilege access and the networking between VPCs correct, with internal firewalls.
  • Secrets management and certificate rotation.
  • Create and deploy automated pipelines to support the DevOps function.

There are many examples where we have seen customers end up with multi-month cycles to provision infrastructure with multiple manual steps and sign offs. All using the CSPs web UI. This introduces a huge amount of complexity as all the configurations need to be stored. We’ve also seen development teams pushing to use the latest cloud technology, but we often find there are many “gotchas” when you dive into the detail and not all cloud products are feature complete or available in every datacentre. This is crucial when you want to implement Disaster Recovery and Business Continuity Planning capabilities.

All of these considerations take a huge amount of time to work through and the potential solutions are endless. Even if you don’t feel like you’re completely in the dark, the chances are you’re going to be blindsided by a vast array of options to choose from.

The great news is that all doubts and fears end here. Tranquility Base has landed.

Tranquility Base is an open source multi cloud infrastructure as code Landing Zone. A configured environment with a standard set of secured cloud infrastructure, policies, best practices, guidelines, and centrally managed services. And we are creating a landing zone for each of the major CSPs. Along the way we have found many, many engineering issues and each CSP has their own strengths and weaknesses that makes some things easy to do, and others really hard. But the best news is – it works. We are already working with our first client to use Tranquility Base to create a cloud platform which they can use to deploy all of their applications, across all departments and all geographies.

We chose to create Tranquility Base, not because it was easy but because cloud migration is hard. You don’t have to struggle in the dark anymore, the lights are on, it’s as easy as 3, 2, 1 – Lift Off!