The last few weeks when I was speaking at a workshop I spend quite a lot of time talking about Governance. Specifically building landing zones, implementing policies and using Azure Blueprints to manage your Azure environment. As it turned out, this was something a lot of the participants were looking for and would solve a lot of the challenges they were having. A lot of companies are not looking at building the landing zone they need before deploying their solution. I've written some posts on leveraging Azure Blueprints before but I found that it needs some background information. In the next few weeks I will follow up with additional posts on governance, building landing zones and using Azure Blueprints and pipelines to lower the effort and increase the chances of successful governance on Azure. I'm doing a session for Azure Advent Calendar as well on Azure Blueprints (https://azureadventcalendar.com/) which will come with a blog post and a video. Do take a look at the other sessions on there - December is going to be amazing!
Alright, back to landing zones.
People usually start building and deploying their solution and when everyone is happy - let's go to production! Sure, that works. But when you become successful and your customer base is growing, customers will demand some form of compliance, trust and efficiency. And if you want to scale your business, you want that too.
When this happens, you will have to implement those guard rails on an existing platform and solution. And even though that doesn't sound like a problem, in reality this is what's giving governance a bad name. Introducing guard rails into an existing environment usually results in a bunch of non-compliance notifications and limitations. Someone needs to fix that, and what's going to happen is that you have to go back to the people who build and deployed the solution and ask them to fix it.
That's the challenge with public clouds. If you look at Microsoft Azure, you generally have multiple ways to go about building your solution using different technologies that Azure provides. Literally hundreds of them. And then you can choose to scale them as big as you want and deploy them in whichever region you want. The fact that you have those capabilities does not mean you have provide everyone with the ability to use all of them. In fact, you want to focus on specific technologies and make sure people deploy them the way that you and your customers expect them to be deployed. Think about sizing, location and role based access control.
Let's look at a common scenario.
A software company landed a contract with their first customer. They started building a new solution and they are deploying that solution directly to the Microsoft Azure platform. The developers were provided with owner level access to the subscription and are free to deploy whichever resource they want without limitations. They are using source control and are deploying their solution using Azure DevOps. Over time they have added new customers and it turned out their solution was single tenant which required a new deployment for each individual customer. At some point it became challenging to keep up with the customer adds and the focus shifted from adding features and innovation to onboarding new customers and maintaining the environment. As deploying new customers turned out to be quite time consuming they decided to inspect what was really happening within their Azure environment.
If you have experience with managing public clouds, you could say that this is not the way you would go about building an Azure solution. But in reality, this is what's happening. From the example scenario we can identify multiple risks:
- Bill shocking: there are no limitations, which introduces the risks of deploying over sized or unnecessary resources which can have a significant financial impact;
- Non-Compliance: are you deploying where you customer expects their solution to run, did you think of regulatory compliance (where's your data?!)
- Latency issues: Are resources deployed within the same region and is that actually the region your customer is operating from?
- Lack of consistency in resource naming, scaling and role based access control
- You're spending more and more time on deploying and managing resources as opposed to development and innovation
This is just to name a few and the list can go on and on. But to prevent these risks you need a proper landing zone and build guard rails. Additionally, most of your customers will have identical requirements so deploying them manually, one by one, makes no sense. We want to implement to guard rails as early as possible and manage governance from the start of the development life cycle (shifting left).
This is where landing zones come in.
For the tech-savvy and hands-on people things get real during the "Ready" phase of the Cloud Adoption Framework (read up on readiness here: https://docs.microsoft.com/en-us/azure/cloud-adoption-framework/ready/). And this is exactly the phase we're talking about in this blog post.
A landing zones refers to the place where you solution will live. That place has rules and regulations that your solution most conform to. You can choose to enforce those rules or to trigger a notification when your solution is not following the rules (non-compliance) this is what we use Azure Policy for. However, solutions need actual resources to be deployed on as well. Sounds like a job for ARM Templates. Additionally, when we change the rules and upgrade the landing zone, we want all the customers to benefit. We also don't want to edit and deploy templates manually for each need customer Long story short; we need Azure Blueprints. I've talked about Azure Blueprints before and Microsoft has provided us with some good documentation regarding blueprints so I will not go into detail on how to work for now. This will the case in future posts but for now a summary will do. With Azure Blueprints you can standardize your deployments and define a repeatable set of resources and guard rails. You can version your Blueprints and group the following technologies into a single package:
- Role Assignments
- Policy Assignments
- Azure Resource Manager templates
- Resource Groups
You need an Azure Blueprint to deploy a landing zone
No, but it sure comes in handy. ARM templates provide you with a "fire-and-forget deployment". There's no life cycle management and versioning there. Yes you can deploy all of this using Azure DevOps and do your versioning there. But isn't it easier to group your solution, policies and access control into a single package?
If we're going by the Cloud Adoption Framework landing zones then there are two landing zones specifically labeled as "CAF Foundation". One for green field solutions and one for a migration landing zone (containing Azure Migrate). Both of them deploy a set of resources and Resource Groups for you to build your solution within and providing you with the best practices regarding guard rails.
But chances are these are not the perfect fit for you. And as we're talking about a framework (read up on it here) you can modify them to your liking. Azure Blueprints provide many samples and to be honest, they're all landing zones. Because these are sample templates, you can easily adjust them to your needs after creating the initial draft.
As you can see, all your regulatory requirements, naming conventions, resource types and resources can be defined within the Blueprint. For example: this Blueprint contains an "Allowed Locations" policy and an "Allowed Virtual Machine SKUs" policy. Allowing us to define which regions and which Virtual Machines are allowed when deploying them to a subscription.
And this is why Blueprints and Landing Zones are so powerful. We can actually define a Blueprint that fits most of our customers. The nuances are usually not about the type of Policy (for example "allowed locations") but more about the configuration of that Policy (which location?).
By assigning those values upon deployment we can actually work with very few Blueprints and apply them to multiple customers (can you see how much time this will save you?). The same goes for Resource Groups and Resources. They're probably similar for each customer (going by the examples I've written up earlier), just the naming is different. Again.. assigning values upon deployment.
And by going about using Blueprints this way, I'm now managing multiple subscriptions using a single Blueprint definition.
The only different is that I'm providing different parameters during the assignment. But in the end, all subscriptions are being managed from a single Blueprint definition (which I've published on a management group level).
The result is standardization and consistency but still being able to have slight nuances per customer environment. If you're looking for a deep dive on using parameters read my post from earlier this year on Blueprint level parameters.
This concludes the first post and motivation to get started on using and building your own landing zones. In the next few posts I will follow up on the concept of landing zones and Blueprints and how you can go about automating large part of your deployments and governance by leveraging these technologies.