Sentia’s Azure Landing Zone allows us to deploy and operate Azure environments via Infrastructure-as-Code (IaC) to ensure a manageable cloud. We caught a glimpse of the service in Sentia’s building blocks for a manageable cloud blog post. In this article we will give a more complete picture of the service without going into the technical details of it. We will also check out how Sentia’s Azure Landing Zone stands out compared to other landing zones so you can understand the difference.

Sentia’s Azure Landing Zone Concept

When we started building Sentia’s Azure Landing Zone (LZ) (about 4 years ago) we decided to see what management problems customers have. After all, as a Managed Service Provider (MSP), management is a foundational part of Sentia. We saw a lot of usage of legacy methods and tools even when customers migrated to the cloud. This kind of approach of course led to one or more of the following problems, some of which could be classified as a violation of privacy law or a breach of security:

• Resources sprawl
• Un-optimized cost
• Un-optimized cloud efficiency
• Redundant usage of resources
• Resources that do not comply with company policies
• Resources that do not comply with other regulations and policies the company is obligated to follow
• Service failures due to poorly architected services and solutions
• Shadow IT
• Failure in show-back and charge-back in resource usage
• Unsecured resources
• Un-monitored resources
• Lack of cloud knowledge
• Lack of cloud design patterns
• Failure in automation

These are only some of the problems, there are many more. Looking at these problems we wanted to build a service that provides a complete lifecycle for deploying and maintaining Azure resources. To address that challenge we took inspiration from Microsoft Docs article What are the Azure Management areas?. That article helped us pinpoint the areas that we needed to cover with Sentia’s Azure Landing Zone.

The article helped us define some main principals we want to honor with our landing zone:

• We should use templates as a main way to deploy Azure services. That way, we can achieve easily idempotency.
• We should use building blocks to deploy one more Azure service/feature. For example one building block will deploy Azure Web App and another building block will deploy Azure SQL Database.
• These building blocks will be called Landing Zone Solutions.
• The building blocks will be stored in Git repositories and will thus have versions.
• The solutions should be generalized as much as possible so they can fit into different architectures and designs. They should be able to serve any customer.
• The solutions will be scalable.
• The solutions should be deployed via CI/CD.
• The solutions will cover both green- and brownfield scenarios.
• For rare cases where we cannot use templates we can use PowerShell to automate.

NOTE: We initially started with ARM Templates but managed to fully move to the more concise and easier to read Bicep.

Microsoft’s Azure Landing Zone

Microsoft also has an Azure Landing Zone which is part of the Microsoft Cloud Adoption Framework for Azure. The framework provides guidance and best practices for a full lifecycle of Azure adoption and management.

To learn more about the concept of a Landing Zone, I suggest to read What is an Azure landing zone? and related documents after which you will probably ask yourself: “What is the difference between Microsoft’s Azure Landing Zone and Sentia’s Azure Landing Zone?”

How Sentia’s Azure Landing Zone differs

When you look at Microsoft’s Azure Landing Zone you will notice a lot of similarities with Sentia’s Azure Landing Zone. That is because both are based on the same concepts. It is important to say that Sentia’s Azure Landing Zone perfectly aligns with the Cloud Adoption Framework. In fact those concepts are not even Azure specific and applicable to cloud and non-cloud environments.

Engineers behind Sentia’s Azure Landing Zone believe our service provides a way better experience compared to others. Microsoft’s Azure Landing Zone is a little over two years old where Sentia’s Landing Zone has been around for four years. If we have to compare it to Microsoft’s Azure Landing Zone, here are some of the key advantages Sentia offers:

• Sentia offers its Landing Zone as a service where we design, build and operate it, instead of the customer. We also provide a way to operate it on your own. This eables any engineer to take advantage of our robust building blocks.
• Sentia’s Landing Zone can work in both green- and brownfield scenarios so you can migrate in phases instead of a big bang.
• We provide regular updates to different solutions/modules by implementing the latest features. We test these updates and when there are breaking changes we provide guidance and capabilities to migrate to a newer version. We have a change log for each solution/module that describes every change. You can choose exactly which version of a solution you want to deploy and move to a newer version at your own pace.
• The configuration/parameters files for solutions/modules are following a hierarchical structure, allowing you to easily distinguish what is deployed and how it is configured. For example if you are deploying SQL logical server and SQL database in a resource group, at first level you will define the resource group that needs to be created, on second level the SQL logical server and on third the SQL database. That way you get a clear picture of how the resources are related and which setting applies to which resource.
• We simplify the configuration for each solution/module that you can specify as much as possible, so engineers who use the Landing Zone can focus on the design and architecture part.
• Sentia’s Landing Zone solutions/modules cover a quite large area of Azure Services from Azure VMs, Virtual Networks, Kubernetes, SQL Database to Web Apps and many more. We do not just cover some basic management and networking services.
• For every Azure service that we can deploy from the Landing Zone we have backup, security and monitoring solutions/modules for it.
• Every property that can be configured for an Azure service can be configured from the configuration/parameters file. For example you can configure the resource to be zone redundant or which availability zone to assign, if you have two Virtual Machines in the same resource group you can configure different tag and value pairs for each one.
• As every solution/module is deployed via a separate CI/CD pipeline we can pass values between different solutions. For example, usually public IP(s) are assigned upon resource creation. If a resource has one or more public addresses the solution outputs those addresses and you can reference those outputs in configurations of another solution. That way you can deploy the two solutions sequentially without having to wait for the first solution deployment to create the configuration for the second one.
• There are certain sets of configurations that are applicable for most resources like tags, system and user assigned identities, zones, etc. We have standardized them, so the way you provide configuration for user assigned identity is the same across all solutions.
• You can share configurations/parameters between solutions/modules. If you have two solutions where you can configure diagnostic settings to send logs and metrics to Log Analytics you can put the reference to the Log Analytics workspace in one configuration and the configurations for those two solutions can reference this. That way certain configurations have one source of truth.

These advantages make Sentia’s Azure Landing Zone richer in functions and capabilities, reliable and predictable and way more flexible compared to other landing zones.

Interested in a manageable cloud?

Would you like to benefit from a manageable cloud by deploying your infrastructure as code via the Sentia Landing Zone solutions, get in touch!