What is your Azure Maturity Level?

image

Figure 1 – The Azure Maturity Model

In my blog About page, as is tradition, I have been very careful to state that the views in this blog do not reflect the view of my employer. In this case, however, I am going to violate that rule. The views expressed in this post exactly do reflect the views of my employer, Coretek Services. For that reason, I have asked our Director of Solutions Architecture Brian Barnes to co-author this blog post with me. Brian was instrumental, together with Ray Jaksic, our Chief Technical Officer, in defining our cloud offerings based upon the varying needs of clients at different levels of Cloud (and thus Azure) Maturity.

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 . Smile

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

image

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.

image

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”.

image

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.

image

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.

image

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”  Smile

Brian Barnes

Bill Zack

August 2017

Posted in Cloud, Cloud Computing, Governance, Microsoft Azure, Windows Azure | Tagged , , , | Leave a comment

A Cloud is a Cloud is a Cloud?

It never fails to amaze me that it seems like every vendor in the industry, every hosting company and every virtualization or database vendor that puts something in one of the Public Clouds is quick to claim that “They have a Cloud”. A while back they even invented a term for that. The term is “CloudWashing” (i.e. naming everything that you have as “Cloud”)

Let’s apply some common sense. Back in 2011 the National Institute of Standards (NIST) produced a concise and clear definition of what it means for something to be a Cloud. You can read about it here. This is the standard against which all Cloud pretenders should be measured. In case you don’t have time to read it I will summarize.

The NIST model defines a Cloud as “Enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. (The underlining is mine)

It is composed of:

  • 5 Essential characteristics
  • 3 Service models
  • 4 Deployment models

The 5 essential characteristics are:

  • On-demand self-service
  • Broad network access
  • Resource pooling
  • Rapid elasticity
  • Measured service

The 3 Service Models are:

  • Software as a Service (SaaS)
  • Platform as a Service (PaaS)
  • Infrastructure as a Service (IaaS)

The 4 Deployment Models are:

  • Public Cloud
  • Private Cloud
  • • Community Cloud
  • • Hybrid Cloud

Let’s take the definitions apart a bit and see what makes them tick:

The 5 Essential Characteristics

On-demand self-service: Being able to self-provision and de-provision resources as needed, without vendor involvement.

Broad network access: Resources available over a network accessed through standard protocols from all kinds of devices. For Public Clouds, these resources are typically available all over the world with data centers that accommodate all country’s need for data sovereignty and locality.

Resource pooling: Lots of resources that can be allocated from a large pool. Often the user does not know, or have to know, their exact location. Although, in the case of Public Clouds like Microsoft Azure, locality is often under the user’s control. In many cases the pool of resources appears to be nearly infinite.

Rapid elasticity: The ability to scale up and down as needed at any time, in some cases automatically, based on policies set by the user.

Measured service: Providing the ability to track costs and allocate them.  Public Cloud resources are often  funded using an Operating Expenditure (OpEx) rather than the Capital Expenditure (CapEx) accounting model used where hardware purchases are involved.

The 3 Service Models

In the case of Public Clouds these service models are defined by who supports various levels in the technology stack; the customer or the cloud vendor.

This Microsoft Azure diagram has been in existence, in one form or another, at least since the 1970s:

clip_image002[4]

It illustrates who is responsible for what part of each service type the Vendor (in blue) and the customer (in black).

Software as a Service (SaaS) asks the customer to take no responsibility for the underlying hardware and software stack. In fact, the customers only responsibility is to use the service and pay for it.

Platform as a Service (PaaS) lets the vendor manage the lower layers of the technology stack, while the customer is responsible for the Application and Data layers.

Infrastructure as a Service (IaaS) corresponds most closely to what the customer must manages  in a typical data center and what the vendor is responsible for. With IaaS, the vendor takes care of everything from part of the operating system layer to the bottom of the stack. Notice that in Azure the operating system layer is partly the vendor’s responsibility, and partly the customer’s. The customer is still responsible for applying operating system patches, for instance. (This may differ slightly for other Public clouds.)

I often include a slide in my Cloud presentations that addresses the question of what to use when. In my mind the decision tree is fairly obvious:

  • It’s SaaS until it isn’t
    • Then It’s PaaS until it isn’t
      • Then It’s IaaS
  • Or Hybrid with any of the above

If you can find a SaaS service that meets your objectives, use it. Let the vendor have all the stack support headaches. If you can’t, then consider using PaaS by either buying a 3rd party application or building your own.

Finally, if none of these approaches work, you can always take advantage of IaaS since that most closely matches what you have in your own data center. Even there, however, the vendor will take care of a great deal of the plumbing. (As an aside IaaS is often the approach of choice for taking a “lift and shift” approach to migrating what you already have running in your data center up into the cloud.)

And yes, I know we haven’t discussed Hybrid yet, but patience, we will get there.

The 4 Deployment Models

A Public Cloud is a pool of computing resources offered by a vendor, typically, on a “pay as you go” basis. It supports Self-Provisioning by its customers as discussed above. It also often has a massive global presence and appears to have near-infinite capacity. In general, it is available to anyone.

Gartner defines a large number of Leadership Quadrants, but the ones that are most relevant to our discussion are the ones for Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). The Gartner Leadership Quadrant for IaaS includes just Amazon and Microsoft. The one for PaaS just includes Microsoft Azure and Salesforce. There are other lesser Public Cloud vendors including Google, IBM and Rackspace.

One other point: Unless a company can spend the many billions of dollars necessary to create a global datacenter presence it is hard for them to be considered a Public Cloud leader.

A Private cloud on the other hand is normally local to a single company. It is normally located on their own premises. If a customer creates a data center, or a complex of data centers, that conforms to the NIST definitions discussed herein then it can rightly be called a “Private Cloud”. Be cautious here, however. Remember the term “CloudWashing” as defined above. Just because a customer has a large number of computers in a data center does not make that a Private Cloud no matter how vehemently they insist on calling it one.

Although there is no requirement for the architecture of Public and Private Clouds to be the same most companies agree that compatibility between them would be helpful to support CloudBursting. That is, the ability to move applications and data freely between the data center and the Public Cloud. (See the discussion on Hybrid Cloud below.)

A Community Cloud is a variation of a Public Cloud that restricts its clientele to a specific community of users. For instance, there are Community Clouds for Government and Education as well as for other communities. Each of these may have different levels of security and compliance requirements or other unique characteristics. The NIST document does state that it may be operated for the community by one of the companies in it, however, it is typically operated by a Public Cloud vendor using a walled-off subset of it resources.

A Hybrid Cloud is typically formed by the integration of two or more Public and/or Private Clouds. In the typical case a company utilizes both a Public Cloud and resources in their own data center structured as a private cloud with strong networking integration between them.

A high degree of standardization between them is desirable in order to make it possible to distribute resources across them or to load balance or cloudburst resources between them. This is often done for security and compliance reasons where a company feels that some data and/or processing must remain behind their own firewall, while other data and/or processing can take advantage of a Public Cloud.

In the case of Microsoft technology there is one example where compatibility will be extremely high and advantageous. I expect the Private Cloud space to be dominated, at least in data centers utilizing Microsoft technology, by the new Azure Stack appliance coming out this summer from 5 initial vendors. Make no mistake about it. Azure Stack is Azure running in your own data center. In effect Azure stack is pretty much like Just another Azure Region  (JAAR?) to the Public Azure Cloud. Having that high degree of compatibility will help facilitate the Hybrid Cloud architecture discussed above. I have already blogged about Azure Stack and why I feel that it is so important so I will not go into that in detail here. See this bog post: The Future of Azure is Azure Stack.

We also should distinguish between true Hybrid Cloud and an IT Hybrid Infrastructure In the case of the latter the resources in the data center need not be in the form of a Private Cloud as discussed above. Microsoft is the clear leader in this space now because of its traditional enterprise data center presence and it’s leadership in converting itself to be a Cloud Company.

So, don’t be fooled by Cloud Pretenders. Apply the NIST litmus test.

Bill Zack

Posted in Architecture, Cloud, Cloud Computing, Windows Azure | Tagged , | Leave a comment

The Nashville Microsoft Azure 2017 Bootcamp

Those of you who know me know that I am also the Founder and President of the Nashville Microsoft Azure Users Group.  This group has grown from four members four years ago to 563 members today. In fact, the group has doubled in size in just the last year alone. This is a testimonial to how Azure is catching on here in Nashville, and globally.

And speaking of globally, we just held our annual Global Azure Bootcamp Event all day Saturday April 22nd in conjunction with Azure groups all over the world.

Keynote

On torrentially rainy day in Nashville, with a flood watch in effect, we had 40 attendees out of the 77 that signed up for our event. Not a bad turnout for a rainy all-day Saturday event.  Smile  We will be doing a satisfaction survey soon, but all the informal feedback was positive, even effusive. We even picked up 14 new members for the group as a result.

We had 12 sessions in two simultaneous tracks, including 4 presenters from Microsoft.

Topics included:

  • Microsoft Cloud Vision and Roadmap (Keynote)
  • Azure Security
  • Backup, High Availability and Business Continuity/Disaster Recovery
  • Operations Management Suite
  • Hybrid Networking Services
  • Citrix on Azure
  • Azure Storage
  • Azure Compute
  • Infrastructure as a Service (IaaS) and the Azure Resource Manager
  • Azure Stack
  • Azure Service Fabric
  • Azure Container Service

I did the talks on Operations Management Suite and Azure Stack.Smile

Alert Logic provided an excellent breakfast from Jason’s Deli. Lunch was provided by Microsoft, and the afternoon break was ice cream provided by Vaco, our perennial refreshments sponsor for the last four years.

The raffle gave away stuff from the global and local sponsors, including two $100 gift cards. There was also SWAG in the form of trial subscriptions of software from the global sponsors. Our thanks to all to our local sponsors, including:

  • Microsoft
  • AlertLogic
  • Vaco
  • Provisions Group
  • Coretek Services

As well as the global sponsors that provided SWAG for the event.

Lots of great photos were taken by Ukela Alred and will be uploaded to the Meetup Site Photos Section/Bootcamp Album shortly.

And a big shout out to Ukela and Scott Schreier who helped with registration and getting folks in and out of the building when the elevators stopped stopping at the 4th floor at Microsoft at  2PM. Smile  Also to Scott for providing those two big agenda posters in front of each meeting room.

We will do this again next year

Bill Zack

Posted in Uncategorized | Leave a comment

Tale of Two Clouds: A Feature Comparison of Azure and AWS

  image

Comparing Azure and AWS is a bit like comparing apples and oranges. Each platform has features that either duplicate or overlap with features of the other platform.

In reality the focus needs to be on solving the business problem and not the technology problem. That being said a lot of companies either have both platforms or are struggling with deciding on, or moving from, one or the other.

Last night at the Nashville Microsoft Azure Users Group I presented a technical comparison of Azure and AWS features.

Despite my admitted bias towards Azure I nevertheless believe that I was pretty fair and objective. Smile

  The topics I covered were:

– Cloud Service Models
– Deployment, Management and Automation
– Compute
– Storage
– Messaging
– Email
– Networking
– Security and Identity
– Operating System & Data Transfer
– Internet of Things (IoT)
– Development Languages and Runtime Support
– Marketplaces
– Media Services
– Mobile Services
– Visualization
– Machine Learning
– Non-Technical Considerations
– Pricing Models

The deck from that presentation is in the files section of the Nashville Microsoft Azure Users Group.

Bill

Posted in Amazon Web Services, Cloud Computing, Microsoft Azure, Windows Azure | Tagged , | 1 Comment

The Future of Azure is Azure Stack!

image

image

I realize that the title above might be a bit controversial to some. In this blog post I will attempt to defend that position.

The two diagrams above, taken from recent Microsoft public presentations,  symbolically represent the components of Public Azure and Private Azure (Azure Stack).  If you think that they have a lot in common you are right.  Azure Stack is Azure running in your own data center.  Although not every Azure feature will be delivered as part of Azure Stack at its initial release (and some may never be delivered that way because they require enormous scale beyond the reach of most companies) , it is fair to say that they are more alike than they are different.

Back in 2012 I wrote a blog post on building cloud burstable, cloud portable applications.  My theses in that post was that customers want to be able to run their applications on local hardware in their data center, on resources provided by cloud providers and/or even resources provided by more than one cloud provider. And that they would like to have a high degree of compatibility that would allow them to defer the choice of where to run it and even change their mind as workload dictates.

That thesis is still true today.  Customers want to be able to run an application in their data center. If they run out of capacity in their data center then they would like to shift it to the cloud and later potentially shift it back to on-premises.

That blog post took an architectural approach using encapsulation and modularity of design to build applications that could run anywhere.

The Birth of Azure

A bit of additional perspective might be useful.  Back in 2007 I was working as an Architect for Microsoft and I came across what would eventually become Azure. (In fact that was before it was even called Azure!) I had worked on an experimental cloud project years before at Bell Labs called Net-1000. At the time AT&T was planning on turning every telephone central office into a data center providing compute power and data storage at the wall jack.  That project failed for various reasons some technical and some political, as documented in  the book The Slingshot Syndrome. The main technical reason was that the computers of the day were minicomputers and mainframes and the PC was just emerging on the scene.   So the technology that makes today’s cloud possible was not yet available.  Anyway, I can say that I was present at the birth of Azure.  History has proven that attaching myself to Azure was a pretty good decision. Smile

The Azure Appliance

What many do not know is that this is actually Microsoft’s third at tempt at providing Azure in the Data Center. Back in 2010 Microsoft announced the Azure Appliance which was to be delivered by a small number of Vendors . It never did materialize as a released product.

Azure Pack and the Cloud Platform System

Then came Windows Azure Pack and the Cloud Platform System in 2014 to be delivered, also in appliance form, by a small number of selected vendors.  Although it met with some success, is still available today, and will be supported going forward, its clear successor will be Azure Stack.   (While Azure Pack is an Azure-like emulator built on top of System Center and Windows Server Azure Stack is real Azure running in your data center.)

Because of this perspective I can discuss how Azure Stack is Microsoft’s third attempt at Azure in the Data Center and one that I believe will be very successful. Third times a charm Smile

Azure Stack

The very first appearance of Azure Stack was in the form of a private preview, and later a public preview: “Azure Stack Technical Preview 1”.  During the preview it became clear that those attempting to install it were experiencing difficulties, many of them related to the use of hardware that did not match the recommended minimum specifications.   

Since Azure Stack is so important to the future of Azure Microsoft decided to release it in the form of an Appliance to be delivered by three vendors (HP, Dell & Lenovo) in the Summer of 2017.  According to Microsoft that does not mean that there will be no more technical previews, or that no-one will be able to install it on their own hardware.   (It is generally expected that there will be additional Technical Previews, perhaps even one at the upcoming Microsoft Ignite! conference later this month.) It simply means that the first generation will be released in controlled fashion through appliances provided by those vendors so that  so that Microsoft and those vendors can insure its early success.

You may not agree with Microsoft (or me), but I am 100% in agreement with that approach.  Azure Stack must succeed is Azure is to continue to succeed.

Bill

Posted in Azure Stack, Cloud, Cloud Computing, Microsoft Azure, Windows Azure | Tagged , | 1 Comment

Microsoft Virtual Academy’s new more agile approach to Azure IT Pro training.

image

Microsoft Virtual Academy is launching a new series for IT Pros that will be delivered in smaller replaceable chunks that will be more consistent with how Azure Features are delivered, rather than long recorded units that are obsolete by the time they are released.  This will be a more agile approach.

They have already released several samples published today (I understand that some of the demos will be added later):

They made the point in the launch event today that that the Azure Active Directory unit was made obsolete last night by the move of Azure Active Directory into the “Current” portal from the “Classic” portal. They will replace that unit and re-release it soon. Just one example of their new agile approach.

Although this series is for “IT Pros” I suspect that they will take the same approach for Developers soon if this works out.

Bill

Posted in Microsoft Azure | Tagged , , | Leave a comment

My Favorite Azure References

image

  In my “day job” as an Azure specialist I am often asked for Azure references on various topics. Here is a list of some of the most important references that I have been sending out recently:

Sizes for Windows virtual machines in Azure and Sizes for Linux virtual machines in Azure cover the specifications of the VM sizes that you can run in Azure:

Microsoft server software support for Microsoft Azure virtual machines covers what is (and is not) supported running in an IaaS VM:

Cloud Platform roadmap covers what has been recently released and what Microsoft is working on. 

Microsoft Azure and Amazon Web Services covers AWS Compete is a good reference to have if the question of comparing AWS and Azure features comes up.

One additional great resource is the Azure Learning Paths.  Azure is so broad that it is difficult to know where to start learning about a particular service or feature. The Learning Paths are step-by-step flowcharts that guide you through the documentation and videos on about 35 of the Azure services. (Not every service is so documented, but the ones that are are well done.) Highly recommended.

Bill

Posted in Amazon Web Services, Architecture, Microsoft Azure | Tagged , , | Leave a comment