In September, Microsoft Ignite Azure Stack was introduced to the market. It finally arrived after an extensive period of testing. Ever since, people’s curiosity has been sparked about what it is for and what men can do with it? Although many have heard about Azure Stack, they might not have the wright understanding of it. Therefore I will try to shine a light on this matter in this blog and in short clarify what it is. This will however not be the complete story.
When Microsoft first started to talk about Azure Stack, they let us believe it was going to be something that you could install on your own hardware and in your own datacenter. Today however, we know that this is not the case and for good reasons. If you think about it, it would have been a real mess with all the different types of hardware available in the world. It would have been uncontrollable. Therefore, Microsoft made the right choice to only use certified hardware’s, so that they can guarantee that it will work as it is supposed to. Thus, what does it mean then…. certified hardware? It means that there are only a couple of “qualified” hardware vendors that can deliver Azure Stack. Such hardware vendors include HP, Dell EMC, Lenovo and Cisco, although more vendors will follow shortly.
The following features are currently available:
More features will follow.
Firstly, you can deploy Azure Stack as a private Cloud or as a hybrid Cloud. You can place an Azure Stack scale unit in your own datacenter or you can use a provider that offers a hosted solution. If you use the Hybrid solution, you will get the most options. In my opinion, this gives you the best features out of both Azure and Azure stack. I tried to capture the ideal deployment in the following image.
So, why would you want to start using Azure Stack? For starters, one reason could be because you want to work in the same manner on-premises as in the public Cloud and want to benefits from all the features the cloud offers. Such benefits include; on-demand self-service, elasticity and measured services. Another reason could be that due to compliancy reasons, you must keep certain data on-premises, but when that is not necessary, you want to use the public cloud. Lastly, Azure Stack gives you access to Azure Resource Manager which offers you many perks plus the use of templates (infrastructure as code) for fast deployment and smart deployment of applications. These JSON templates can be used in Azure Stack and in Azure.
Azure Stack is an appliance and it looks something like the box in the image below:
The top part of the image resembles the available user space and the lower part of the picture shows the Azure Stack infrastructure. As you can see, the infrastructure has several machines among which an AD, a DNS and a DHCP. Beneath these machines, you can also see the Admin portal- and the User portal machine, which shows that there are two portals being used. In the following paragraph I will go into more detail the portals and the roles which are associated with them.
Azure Stack Roles
Once the stack has been set-up, the owner can start creating subscriptions, offers and plans for usage. This is where I get to the next part; to your Azure Stack environment. This environment shows how the organisation is arranged, what roles there are in the organisation and what actions need to be taken care of.
There are four roles in the Azure Stack environment:
All roles are part of the company that owns the stack. The Cloud architect is responsible for the Cloud strategy within the organization and for the design of the Azure Stack environment. The Cloud operator takes care of the environments day-to-day operations. The operator monitors the stack and keeps on eye on the available capacity of Azure Stack. In case problems occur, the operator contacts the vendor or Microsoft to solve the issue. Both the architect and the operator work with the Admin portal. As the name implies, the Admin portal is for administration of the Azure Stack environment.
The other two roles are that of the Cloud administrator and the DevOps role. The Cloud administrator manages the Azure Stack subscription and the capabilities of these subscriptions. The administrator makes plans and offers which in turn, can be added to a subscription. A subscription defines what you can do, which services you can deploy. The image below provides an overview of the connections between subscriptions, offers and plans.
An elaboration of each of the connections is provided below;
Services – A “service” as shown in the picture above, can be several things such as networking, compute, storage, SQL, MySQL etcetera.
Plan – A “plan” is where you define which services you can use (e.g. network, compute or storage). You can put a limit to the services in your plan as well. For example, a quota that says that you can build 10 VMs, 500 Gb of storage and use a maximum of 6 network adapters. The Cloud administrator can make multiple plans, all depending on the needs of the Azure Stack users and requirements of the business.
Offer – An “offer” is a collection of one or more plans.
Subscription – A “subscription” is a boundary for deploying Azure Stack resources. It is the Cloud administrator will assign to users. There can be multiple subscriptions and based on what the subscription, the offers and the plans consist of, the user gets certain capabilities in Azure Stack. Essentially, you can compare the subscriptions in Azure Stack with the subscriptions in Azure. In Azure there are also different subscriptions, trials, msdn, pay as you go, and so forth.
The last role in the Azure Stack environment, is the DevOps role. DevOps is a consumer of resources and is responsible for the deployment and configuration of these resources. What DevOps can do, depends on the subscription and the functionalities the cloud administrator added to that subscription.
Azure Stack in a hybrid environment can be a region in this hybrid Cloud. A region can exist of multiple scale units as shown in the picture below.
This scenario gives you the possibility to implement high availability through dividing the used machines in an application between two scale units.
Note: This will not be possible at the moment, but will be implemented at a later stage!!
There are two possible license options; pay as you use and the capacity license. Pay as you use is like is says. It is a license you can use in the hybrid situation. You must have a connection with Azure though because the usage of Azure Stack is recorded in Azure. If you do not want to use the hybrid scenario, you can use the capacity license. It is an addition on the Enterprise Agreement and is based on the amount of hardware of the stack. If the owner of the stack wants to charge for the usage of the stack, the owner has to take care of the billing.
Azure Stack is just like Azure in a continuous development, so new updates and new resource providers will arrive to the platform. Third parties will also develop resource provider for their solutions, so the product will evolve over time. Already known is that the microservices resource provider is in development. This will bring new capabilities to Azure Stack. Nevertheless, this will still take a while probably.
Before I come to the end of this blog, I would like to mention one more thing I like about Azure Stack (apart from the reasons given above). Azure Resource Manager is the part what I find makes Azure Stack stand out. Infrastructure-as-a-code with ARM and the smart and quick deployment and configuration of applications. Spreading application VMs over Azure Stack and Azure by using JSON templates, template you can re-use and that work both in Azure and Azure Stack. So, should you go for Azure Stack? Hopefully this blog helps you to make a decision.