Landing Zone design: head in the clouds, keeping feet on the ground

The Public Cloud fascinates me. It gives off an image where everything is simple, where the problems related to the infrastructure are disappearing, giving a way to magic. The most impressive thing is that this promise is also a reality, it is possible and easy to build a new operationnal environment in five minutes.

Is that a good thing? Yes of course, it is a formidable vector of acceleration for innovation in many cases.

Is it always that simple? Unfortunately not, in the context of a company, it is necessary to have the control, to build an infrastructure that will be able to best support its activity, processes and organization. Magic can help us, not doing the work for us.

The magical vision we have of the Cloud and the very technical view we have of the infrastructure often make us forget the notion of service, which should be at the heart of the preoccupations of all the teams working for the company.

There is a work to do to ensure that the cloud infrastructure that is going to be built will meet the needs of the company and stay aligned with its strategic objectives. It is a governance task that must be carried out upstream and as part of a continuous improvement process. This responsibility must be identified and assumed by a structure in the company. Among our customers this type of structure is often called Cloud Center of Excellence (CCOE).

The set of resources and processes that implement the cloud strategy and the governance at the corporate level constitute what is known as the Landing Zone (LZ). It contains everything that is offered to teams for working in the cloud, in terms of tools, constraints and organization.

Quick and dirty

It’s really very easy to get started with the cloud. Moreover, when a customer is wondering or starting to be interested in it, we start by proposing a Proof of Concept (PoC) on a small and low-risk perimeter so that the notion of cloud becomes more concrete for him.

After this demonstration, often using a lot of magic, some might be tempted to project themselves and imagine how quick and easy it could be to reproduce this at scale and abandon all or part of their physical datacenter in favor of the cloud, launching what we called a Move to Cloud project.

A common mistake: considering the PoC has been realized under the target conditions.

It is at this precise moment that we observe a common mistake that must be avoided: considering the PoC has been realized under the target conditions ! And deduct on this basis a budget or a deadline for the creation of the whole company-wide infrastructure.

In fact, in order to be quick and reduce costs, the PoC was on the contrary carried out completely outside of the company context. The scope of the study was precisely chosen so as not to be subject to too many constraints and not to require a long and precise audit of the company’s organization before. We have deliberately ignored a large number of issues that will necessarily have to be addressed in order to build a robust and company-wide landing zone. The landing zone is the foundation of the cloud infrastructure, its design quality determines the return on investment in terms of quality, reliability, agility and potential financial savings.

At this stage of the project, the stakes are far too high to think of a quick and dirty approach, it is crucial to adopt instead a pragmatic and iterative approach to carry out in-depth design work. Contrary to what one might think, design is as important when using PaaS, Saas or serverless services.
It’s always magic versus control !

One-size-fits-all ?

Ok, it’s important to start with a well organized landing zone, but is there any landing zone models that can be used to guarantee the success?

What need to keep in mind is that the cloud infrastructure, as on premise one, must fit your needs and be fully aligned with the organization of your company: the actors, the processes, the perimeters of responsibility, the strategy. Using a generic model would also necessarily involve a lot of compromise.

Cloud providers are beginning to offer tools to help create landing zones based best practices and feedback from their customers, one example is AWS Control Tower. This type of tool offers to assist us on the implementation but they will not do the necessary design work for us. Moreover, they are generally console oriented and therefore may not integrate well with an infrastructure as code approach. Even so, things are changing rapidly, so you have to keep an eye on it.

When you copy a landing zone model, you must be ready to adapt your organization to match it.

What about reusing a landing zone set up by another company? When you copy a landing zone, you must be ready to adapt your organization to match it. For a company that is in the process of building itself, this may be possible, but for an already established company, having to adapt the organization to the product is very complicated and most of the time goes against the business stakes.

The construction of a landing zone must be an iterative process where we do not directly build the final product, we refine it little by little with a continuous improvement process. The path taken by the teams to achieve the result is at least as important as the result itself. The experience, maturity and mastery of what has been produced by teams is the best guarantee that they will be able to maintain it and that the landing zone will continue to fit your needs over time.

So, without surprise, there is no single one-size-fits-all model. It is possible to reuse some things, but the best path is to build your own tailor-made landing zone to ensure maximum productivity and return on investment.

How to build a landing zone

We have talked about the importance of conducting a serious pre-study, but what are the important topics?

Expression of needs

The landing zone must reflect the target organization, so the first thing to do is to describe precisely the target organization and the governance you want to set up. The quality of the expression of needs and the setting up of a governance structure from the outset will be decisive for the project.

The landing zone is an enterprise-level infrastructure layer, i.e. it is the interface between cross-functional functions (governance, security, access management, network, etc.) and project teams.

Implementation choices often consist of positioning a cursor between the level of mutualization we want to get (governance, coherence, control, rationalization) and the autonomy we want to give teams (empowerment, agility, encouraging innovation). On this point there are no good or bad decisions, just a cursor that must be placed and moved afterwards if necessary.

Positioning a cursor between the level of mutualization we want to get and the autonomy we want to give teams.

Concerning the scope of responsibility of each team, especially to describe the interactions between cross-fonctionnal teams and business project teams, the production of RACIs (Responsible, Accountable, Consulted and Informed) or RAM (Responsability Assignment Matrix) is a real plus for making relevant choices concerning the landing zone, as well as for sharing the same vision accross the company.

Implementation

The expression of needs describes what needs to be implemented. On the other hand, the cloud provider provides a generic set of resources that should be viewed as a toolkit. The implementation consists in giving our own meaning to these resources in order to build a particular landing zone, including specificities of the company.

Let’s take a concrete example from AWS. A landing zone will generally rely on several AWS Accounts belonging to an unique AWS Organization. These accounts can then be split into different OUs (Organizational Units) and each of the accounts may contain one or more VPC (Virtual Private Cloud). This is our toolbox, with these elements we have complete freedom to implement what we want. So, what do we want ?

AWS IAM access management is mainly based on roles, each containing a set of permissions, given to the user in a given account. The cost management also allows to track separately the consumption from different accounts. The notion of account can therefore be used to isolate “things” that should be accessible to different populations or tracked differently. It is important to be able to give a rule defining the perimeter of an account in the context of the company. From an operational point of view and for each new business need, it should be easy to know whether it is necessary to create a new account or if we can reuse an existing one.
The OUs allow you to group accounts with common points, but they can also carry some Service Policies that will apply to all their child accounts. These policies are directly linked to the governance strategy that we want to put in place. So we have to ask ourselves which grouping strategy would make sense in the enterprise context, but also if we want to regulate the cloud usage for some of these groups. As for the notion of account, a global rule must define what means the notion of OU in our context and thus know precisely in which OU a new account must go.

Of course we could mention many other subjects on which working to implement the company’s strategy:

Naming and tagging conventions
Identity, Access, DNS or compliance management
VPC granularity
Network access and interconnection
Security of flows coming from or going to the Internet
Addressing plans,
etc.

Everything that is developed must be designed to support agility and facilitate the maintainance.

In a Infrastructure as Code (IaC) approach, it will also be necessary to think about the granularity of infrastructure projects. With tools like Terraform, it is possible to factorize the code to get something powerful that acts all at once on the entire landing zone. On the other hand factorization of code also implies a strong coupling between resources which is not always a good idea for day-2 operations. Everything that is developed must be designed to remain agile while facilitating maintainance. It is necessary to avoid that a minor technical change could have an impact on too many resources at the same time because it would be practically impossible to plan such a change, considering the constraints of each project involved.

Conclusion

Through this article I wanted to share a little bit of the experience I have acquired during missions carried out for our customers.

We have seen that:

The magic side of the cloud may be practical but we prefer to keep control in an enterprise context
An efficient landing zone is a landing zone that is fully aligned with the company’s specificities
In order to do this, the definition of needs and the establishment of a governance structure are essential
Special care must be taken in the implementation to remain agile while facilitating maintenance, especially for transversal components

I’m aware that there’s still a lot to say on this subject and I will be happy to exchange with you through comments or by email.

Also don’t hesitate to send me your possible suggestions to improve this article. Thanks.

Deploy enterprise AKS environments

Initialement publié sur Medium.