Recently we finished another landing zone project and want to share some learnings. But first, we probably need to explain what we are talking about.
minimal viable landing zone
Google came up with the idea of packaging the basic structure of a GCP environment as a minimal viable landing zone to avoid bringing PoCs to production. Great idea as we saw in our projects with customers that the starting point was often already in a state that was hard to maintain. The complexity of a cloud environment is high and users can feel overwhelmed taking their first steps on GCP.
I usually compare public cloud environments to data centers. If you buy a new one it’s packed full of expensive (and noisy) things that do not do a lot except converting energy into heat. So you have to set up your access control, networks, configure storage systems, install an operating system, bring up VMs, and more. This is not only time-consuming, but it also requires quite some knowledge (who remembers the difference between raid 10 and 01?).
In the cloud world, your cloud environment looks pretty similar to the empty data center. You have to take care of the same things just at a different level of abstraction. To simplify your take-off, the concept of a minimal viable landing zone came to play.
It’s an environment based on best practices that are created together with the customer, supported by a google cloud partner (like us 😉 ) so the customer can look into the deployment of the apps instead of the details of the networking. Within 90 days you have a solid, compliant, and secure starting point which is the baseline for your cloud journey.
the use case
We got approached by Google that an enterprise customer wanted to add GCP to their portfolio of public clouds they use. They wanted to rely as much as possible on low-maintenance solutions like Cloud Run, Cloud SQL, BigQuery, and others. The challenge they faced was their pretty complex organization which contains various departments in various regions in the world which needed to be mapped to the GCP environment in a way that scales but does not slow down the teams. They needed a pretty complex network design as well as direct connections to their on-premises data centers. All the services needed to follow security best practices and be compliant with their governance. On that scale, it is important to have an eye on clear ownership principles that can be implemented directly into the cloud console. Spending budgets on specific playground projects reduce the surprise and the end of the billing period.
It worked out well and we left another happy customer with a super smart and motivated team that is eager to dive deeper into the GCP ecosystem. But that’s just our view, if you like more details, please have a look at a session we had with Google to tell the story from the customer’s perspective.
Google provided amazing support throughout the whole process. Thanks, Google!
Plan & update stakeholders As the goal is to run this kind of project in an agile way we have to make sure the planning is done right. Of course, plans change during the process of the project but it is important to know which goals we are trying to reach. So over the whole process, it is critical to plan and replan the work and align it with the goals. There might be various stakeholders involved and all of them should be aligned.
Share the progress Sprint reviews with the engineering teams offer a great opportunity to share the progress across the organization. As the landing zone offers opportunities for a lot of teams it is critical to communicate across teams about progress and challenges since the teams can provide a lot of useful information that may be integrated into the architecture of the landing zone.
Enable the teams Introducing a bunch of new technologies can feel overwhelming for the customer’s teams. We noticed that learning and enablement for some customers is the most important part. So it is very important to make sure they understand and can maintain whatever we create for them. So having an eye on good documentation and regular Q/A sessions helps. Giving them some time to study some theory on GCP is a nice idea too, in case that’s possible. Context switching should be avoided as usual but for sure there are other things to maintain for SREs. If they have the feeling it is hard to focus on the new things, the management should make sure there are dedicated time boxes for the topics.
Control the scope A landing zone should provide the baseline for future growth. It is pretty hard to set the scope right as (of course) the super motivated customer teams like everything now. That’s great but to get the landing zone we try to focus on the basic parts first. So if there is an application that can be used as part of the MVP, I recommend going with something that uses most of the created environment but does not add more complexity for now.
Add an addendum to SoW with the actual plan in some cases the SoW is written (together with the customer) in a situation where the actual work is not completely defined. That might be caused by missing insights or unclear targets. Ideally, that should be avoided but in reality, that’s not always possible. So I would recommend adding an extra page to the SoW (which is the contract basically) after the first workshops are done and defining the scope and as many details as possible in there. That might still not be final but it is closer to reality than before those workshops.
The next step after a nicely made landing zone is the actual migration of the workloads but with a solid foundation, these goals are way easier to achieve. We recommend getting some help from a Google Partner for that too (like us 😉 ) as that’s what we do all day and we can probably provide some tips and tricks.
We are looking forward to the next landing zone project. If you have a similar challenge feel to reach out to us.