Azure Migration Series - the Approach and the Layers

The Approach

Based on what we have seen so far, CIT might seem daunting. But what we follow in this book is a simple and consistent approach that can make things easy to understand, design, and implement. Without such a simple approach the IT department will not be able to shift its focus from the routine tasks required to maintain IT assets to more transforming ones including building innovative solutions or quick application turn around.

The approach applies to all layers of the cloud architecture and is split into three components: what, how, and who. We simplify the required tasks to what has to be done, how it should be implemented, and who is in charge of doing it. Many books or articles – including online Microsoft Azure documents – talk about what components exist and sometimes they show how to build them in isolation. However, the lack several important notions:

What is practical?

Devils lie in the details. If we review Azure documents they seem natural and make sense. But as soon as we try to apply them within our organization we are faced with many questions. For example, if we want to build our infrastructure for high availably, we can find nice diagrams showing traffic managers combined with application gateways and load-balancer to build a multi-regional CNET. But as soon as we start to build such a network we are faced with major questions like which department will own the traffic manager? Do we need one traffic manager per department? If so should different department VNETs in the same region talk to each other over internet via the traffic managers or they should be paired?

With so many options, what is the right way to do stuff?

Looking at the Azure portal we see plethora of options to do the same thing. This is probably due to the fierce completion that Azure and AWS have in providing the latest and greatest services to their consumers. At the same time, it creates great confusion on which options work best to satisfy our means. For example, in order to secure a VNET we can provision a firewall but at the same time we can do the same with combing NSGs and monitoring resources.

Who is in charge?

Knowing what to build and how to build it is not enough. For example, when thinking about a resource group that can contain a group of assets, we need to know who within an organization can create them. If the answer is the network admin, then we need to know how a developer could add an asset to the resource group once it is built. If the developer becomes the owner of a resource group, then what type of assets are allowed to be built. CIT cannot be run as a democratic society without imposing clear governance since a developer may provision a very expensive resource without knowing how much it would cost to the organization.

How to build a system?

Another aspect is how different components can work together. For example, if a data analyst trains a model and builds a deployable PaaS service, how it would be able to access a database which is provisioned as IaaS. Should it be via integration with the VNET - that can cause security concerns since it can expose the VNET to internet - or it should access the data via external facing APIs.

How to manage a transient IT?

In the book, we specifically pay attention to migrating organizations. For such an organization, we are faced with complex scenarios where some of the assets are on-premises and some on the cloud. Following an ad hoc approach to provide connectivity between this two networks creates confusion and major security concerns.

In order to solve the mentioned problems and many more we always follow our three-step approach: what is needed? How to build it? And who is in charge? This will let us define clear processes around all aspects of the CIT.

The Layers

When designing the CIT, we organize resources in layers. These layers are not just how the system is designed but also where and how the code or scripts defining each layer is stored and deployed. Having resources in separate layers provide several benefits:

Separation of Concerns

Related resources are kept and managed together. Most of the time the languages and tools applicable to defining and deploying each layer are different. Also, if we try to analyze the system it would be much easier to look at one layer at a time rather than everything together. For example, if we are assessing the security we can start by looking at the security layer and see if the NSG rules are set correctly. Once security assessment is complete we can overlay it on the infrastructure layer and see if NSGs are associated to the correct resources.

Separation of Duties

Another benefit of a layered architecture is that people who are responsible for the infrastructure i.e. network admins, can work independently from people who are responsible for security i.e. system admins, and people who write code for applications i.e. developers and so on. Of course, there are situations that these people have to cooperate like when the CIT is designed for the first time, network and system admins should work together to make sure the network is designed in a way that can be assigned different NSGs for each specific subnet.

Independent deployment

Each layer has its own deployment cycle. For example, the core infrastructure is only deployed in its entirety once but after that will only be modified using small modifications to fix identified issues as needed. However, the applications are deployed continuously – at least in the DEV environment. Keeping layers separate allows for different deployment cycles.

Table 1 specifies the languages, tools, and staff for each of the five layers. We will look at each of them in great details in chapter 3 to 7.

In the next chapter, however, we begin with preparing for the migration. Knowing the existing system and do some early analysis on how the migration will look like and how much it will cost allows us to assess the architectural choice at each layer in a more objective way.