Figure 1 – The Azure Maturity Model

The Azure Maturity Model is based on the Cloud Maturity Model developed by the Open Data Center Alliance. Its purpose is to help you determine where you stand in your ability to adopt the cloud successfully.

We have adopted it and adapted it to be an Azure Maturity Model for guiding companies that are at various stages in their adoption of Azure. We have also used it to structure our Azure service offerings to match what is needed by companies at various levels of maturity.

The Azure Maturity Model

The Azure Maturity Model levels are shown in Figure 1.

• Azure Watchers are organizations that are developing cloud strategies and plans but have not yet deployed applications or workloads into Azure. Azure Watchers want to evaluate available cloud options and determine which applications or workloads to implement in the cloud.

• Azure Starters are new to cloud computing and are working on proof-of-concepts or initial Azure cloud projects. Azure Starters want to gain experience with cloud in order to determine future projects.

• Azure Explorers have multiple applications or workloads already deployed in Azure. Azure Explorers are focused on improving and expanding their use of cloud resources.

• Azure Focused companies are already heavily using Azure and are looking to optimize their Azure cloud operations and costs.

How to tell where you are.

To determine your maturity level, you must be honest with yourself and do a self-evaluation based on the above criteria. Or you could hire an experienced consultant to come in and help you do it .

How to get to the next level (and why you want to)

Regardless of the level of Azure maturity that you are at you will need to look at your existing applications and workloads in terms of factors such as

• Competitive pressures forcing you to the cloud
• The shift from Capex to OpEx and Cost Control
• Your desire for agility in capacity
• The need for a hybrid architecture leveraging the cloud and on-premises resources with each other.

Workloads that cry out to be moved to the cloud

One of the primary reasons for moving to Azure has to do with Capacity Planning and Scalability. Capacity Planning in the data center is often a linear process. An IT director must make an estimate of the company’s capacity requirements over time, in most cases on a yearly basis. Then it is their job to make sure that those requirements are met. Ideally there should be no time during which capacity is wasted and no time during which the capability needed by the business is not available.

Unfortunately, reality is messy, and the capacity needs of the business are never represented by a straight line. (See the curved line in Figure 2 for a typical example.)

Adding to the difficulty of matching capacity to requirements is the server quantum effect. You cannot normally buy and bring in servers of the exact size and timing to match the real demand curve. So, you have to buy servers in relatively large chunks as shown in the step-function in Figure 2

Figure 2 – Data Center Capacity

Contrast that with Figure 3 which shows that in Azure it is possible to match capacity requirements to available capacity because of the ability to scale up and scale down as needed to match demand.

Figure 3 – The Azure View

Applications and Workloads fit for Azure

Of course, Scalability is important, but it is not the whole story. You also have to look carefully at the applications and workloads that you have in your data center that you may want to move to Azure. You need to consider their “fitness” for the cloud. Figure 4 (from the dawn of Azure) seeks to define the characteristics of application (and workload) types that are “Fit for the Cloud”.

Figure 4 – Workload Patterns

Predictable Bursting

This is the pattern that started the Cloud revolution. We do have to give Amazon credit for this. Having a lot of capacity during the Christmas season that remained idle most of the year they decided to sell that idle capacity.

Examples of Predictable Bursting are the Christmas Rush I retail (the Amazon pattern), Tax Season in CPA firms, etc.

On-Off

Given the ability to scale up and down in Azure a prime target are those applications and workloads that do not have to be always on. Examples might be processing that is only done at month-end, at end-of day or as otherwise required.

This is, by the way, a very significant pattern and one that can save a company a lot of money. One recent Migration Assessment that we performed for a client showed that they could save 35% of their entire compute costs by simply automating the shutdown and startup of Virtual Machines in Azure to match this pattern.

Growing Fast

I call this the “Grow-Fast” “Fail Fast” pattern. This is an application or workload that is new and may require a high level of resources. Or not. Only time will tell. No point in buying a lot of server capacity only to have it sit around idle if the expected demand does not materialize. An example might be a new web site that just might be the next Facebook. Or not.

Unpredictable Bursting

This one is a bit hard to distinguish form the predictable bursting case. This is the case where a lot of traffic hits your web site because Microsoft or Slashdot tells the world about it.  Initially there is heavy traffic to it, but it may not last. Again, no need to buy capacity that may not be needed in the long run.

Who is responsible for what in Azure?

There are multiple ways to move applications and workloads to Azure. They are: Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). A third method Software as a Service (SaaS) is not actually a method supported by Azure as discussed below. These approaches differ primarily in who is responsible for the various levels of the hardware/software stack. The diagram below (also from the dawn of Azure) illustrates the typical on-premises hardware and software stack and contrasts it with your complete responsivity for everything in the data center to your more limited responsibilities in Azure.

Figure 5 – Cloud Services – Shared responsibility

Everything in black letters represents your responsibilities. The items in blue are handled by the cloud vendor, in our case by Microsoft Azure.

On-Premises

No issue here. You are responsible for everything. (Unless you contract out management of your infrastructure to a Managed Service provider that acts like you own IT staff).

IaaS

In IaaS, the vendor (Microsoft) is responsible for everything up to 1/2 of the OS layer. Why 1/2? Because, although Microsoft takes responsibility of most to the OS layer you are still responsible for performing maintenance such as patching the OS when fixes come out.

PaaS

PaaS was actually the first Azure service delivered back in 2010. IaaS was added after that to accommodate all the clients that wanted to get into the cloud quickly using a “Lift and Shift” approach to move applications and workloads to Azure. In PaaS, you have no responsibility for the non-application and data parts of the stack. You just bring your applicants and data to the stack and process it there. It should be mentioned that in many cases you can move applications to the cloud unmodified, however in some case they require modification (called “Modernization”) to make the transition successful and more cost effective.

SaaS

A discussion of SaaS is somewhat misplaced in a discussion of Azure, but it needs to be contrasted with IaaS and PaaS. In SaaS, the vendor has complete responsibility for the entire stack. You just use the service provided by the SaaS vendor. Of course, you do need to bring your data but the application processing is provided by them. Good examples of SaaS would be Microsoft’s Office 365 and (from the dawn of computing) ADP Payroll processing and QuickBooks. (Which are not often recognized as pioneers in the SaaS space, but they are.)

Conclusions

Making the decision to take a Lift and Shift approach with IaaS, to take a Modernization approach with PaaS or to take a provided service approach such as SaaS can be hard decision to make. When we help our clients make that decision through a process we call “Migration Assessment” we evaluate all the criteria above. Not to over-simplify but figure 6 illustrates the thought process of deciding between SaaS, PaaS and IaaS.

Figure 6 – When to Use What?

Clearly if you can find a SaaS solution that does the job for the right price adopt it.

If the application or workload is amenable to Modernization that might be the right choice. Effort expended in modifying it to run better in Azure might result in lower costs and fewer maintenance headaches.

If neither of those approaches are appropriate then you can always take the Lift and Shift approach provided by IaaS to get the application or workload into Azure quickly. Accountants think in terms of Return on Investment (ROI) and Total Cost of Operation (TCO). In a world where business needs change rapidly and it is difficult to predict the future Time to Value (TTV) can often be a more important determinant of what to move to the cloud first.

And yes, I know that we haven’t discussed the Hybrid approach (blending cloud and on-premises resources together) in this post. Microsoft is the number one cloud provider in the Hybrid space, but that will have to be saved for another post on another day. As Mark Twain once said, “Sorry for the length of this letter, I did not have time to make it shorter” 

Bill Zack

August 2017