Azure is Microsoft’s cloud offering, which comes in private, on-premise (Azure Stack), government, and public versions (refer to this link for further details https://azure.microsoft.com/en-us/overview/what-is-a-private-cloud/). It was announced on October 2008, released on February 2010, and is the next evolution of virtualization. The magic of Azure is built on top of a technology called Service Fabric and Fabric controllers; it works as a distributed application system that handles the allocation of servers or services, monitors the health of these, and heals them as needed. Each Fabric Controller orchestrates all the resources needed within the Azure platform. All the network resources and servers have been abstracted out of your view and there is no longer a need to support and maintain these resources. This will create what is referred to as a closed ecosystem, and Azure offers its services in this closed ecosystem for mass consumption. This closed ecosystem allows its consumers to not have to worry about the underlying technology and, in most cases, the operating system needs to support that technology. This has helped in abstracting away the need to support the many facets of technology in today's organizations.

As I grew up in the development world, I had to learn firsthand how frameworks moved the line of responsibility. In the development of applications, this leads to some uncomfortable moments as I had to learn to adjust to these new lines. This learning process allowed me to focus more on the application I was developing and less on how each piece needed to be integrated with the underlying system. New frameworks such as the Entity Framework for database integration or the Windows Identity Framework for security integration simplified these layers in application development. Azure begins the next evolution of these abstractions and is referred to as a closed ecosystem. A closed ecosystem gives the infrastructure resources or operations managers within an organization new lines of responsibility. 

These new lines have created an opportunity for organizations to support their daily operations and have put less pressure on underlying infrastructure concerns. This has led to a new way for operational engineers to secure organization resources, which has been simplified and codified. Cloud resources have also stretched passed the need for managing virtual machines alone and have moved to a more utility-based structure (referred to as compute), as you can just deploy your enterprise applications without much regard to the underlying infrastructure. Now, in the past, I have been asked by these operations folks Why would they want to eliminate my job function? The simple answer is the same as it was for the developer. It will enhance your ability to complete your job function, and not eliminate it. My answer, personally, when asked this question, is do you like getting up in the night and on weekends to patch or support your infrastructure?, to which the answer is always a resounding No!, I then ask, If I could remove this from your view, would that be ok? This is always answered with a Yes!, and I then say, Welcome to Azure! 

Overall, this is to helped organizations focus on their application development, infrastructure resource needs, and security, without the concern of maintaining, patching, or updating the underlying resources or technology. One of the biggest things organizations have to grasp is the changes to budgeting in this new utility-based cost model. Gone are the days of needing to rent data centers or rack space to house your servers and routers. In their place steps the consumption model. This model follows more of a pay as you go aspect for resources and has opened the door for organizations and startups to better structure budgets and the upfront costs of development or infrastructure. With that comes some caveats, as with electricity, some things you put into this model can create unexpected costs. For example, plugging in a refrigerator or pool pump can increase your monthly bill, and so resources such as CosmosDB or VM sizing can affect your Azure monthly bill.  As we progress through this book, we will hopefully bring more of these issues to light and learn how to control costs better.

With the adoption of the cloud, there has come new guidance on the usage of resource types, cost, as well as deployment needs. These needs and deployment strategies differ by a cloud provider, but one I have been very accustomed to us is Azure.  Azure provides Platform as a service (PaaS), Software as a service (SaaS), and Infrastructure as a service (IaaS) for a large variety of programming languages. One of the biggest hurdles in your journey beside which type of resources to use is the cost associated with spinning up that type of resource. Most of the clients I work with have struggled with cost management. I try to leverage the Azure pricing calculator as much as I can; however, with Azure being a utility, it never tells the tale of consumption.  So, as we begin our journey to Azure enlightenment, we will look at the cost or highlighting the things you need to consider when selecting a resource. Let’s take a moment to look at the responsibility to understand what responsibilities you are keeping and are releasing Microsoft, in following figure:

Now that we understand the responsible parties on the type of resources we pick, let’s dive into Azure and see how to leverage it to run solutions.