Now that all offerings have been defined, we can go one step ahead: the sizing of the environment.

As you know already, Azure Stack is not just a software solution; it will be delivered as an integrated system. This means that it consists of hardware and the appropriate software on top. There are numerous reasons for that. If you go directly with the Public Cloud Azure offering, you do not have to care about the underlying hardware. As Azure Stack is nothing more than bringing Azure to your data center, this is simply the same. For general availability, we will have the following OEMs that offer Azure Stack:

• Dell EMC
• HP Enterprise
• Lenovo
• After GA, additional hardware vendors (like Cisco and others) will soon join. Their offerings nearly look the same; only some minor things such as disk size will be different.

This integrated system is, to be honest, a hyper-converged system, which means that Hyper-V nodes and storage nodes are the same physical hardware. It does not have dedicated hardware for each layer.

In addition, for Proof of Concept (PoC), there is a software-only release available that is running all components but will be delivered as a one-node solution. This means that all features are available, but you are lacking performance, stability, and high-availability tests within your PoC. In addition, no updates are published for the PoC release; you always need to redeploy Azure Stack if new bits are published.

The smallest footprint of Azure Stack in production is a four-node setup, which includes the top-of-the-rack (ToR) switches and maybe the aggregate switch. If you are later scaling resources, you will have to order another rack and add it to your Azure Stack. If the first rack is missing an aggregate switch, this needs to be added too. One thing you need to have in mind is that the portal and Azure Resource Manager will always be in your first rack for version 1. This means that you will need to take special care of your first rack, because if you lose it, your complete Azure Stack management is gone. For this, I would prefer you have a working and tested backup and restore process in place to make sure that if something happens with the first rack, you would be able to restore it as priority number one.

Why do we have this special design? Maybe you know that the initial versions of Azure had the same setup and it changed later. So with Azure Stack, we could expect the same in future releases.

A good question is what your hardware OEM will need to set up your Azure Stack deployment as expected. There is a deployment collection Excel file that you will get from the hardware vendor you have chosen. All information in this document needs to be collected, and then, it will be the basis for the deployment.

So we need to prepare all these details within our planning of the design. Let's start first with the sizing of the solution. The following questionnaire will help you get an answer for the design:

• How many end customers are you planning today and within the next 5 years that will be onboard to the solution? What kind of customers are you offering your services to, keeping in mind you have a buffer of 30-50% for unexpected growth?
• How many resources do your offerings require per service implementation? Think about a gold, silver, and bronze offering for performance, and keep in mind to have a buffer too if, unexpected load will run in these 30-50% services.
• Are you willing to offer highly available solutions to the end customer's (fault domains)? If so, how many and in which different fire locations would you like to place the stacks? Which service will be highly available? What does that mean to the connectivity? Do we need quality of service (QoS)? Think about offering different solutions as non-HA or HA ones.
• How many regions are you planning? (For GA, only one region is planned, later on, additional ones will be possible, too.)
• Are you planning to offer your services on a national or international market? This will give you an idea of the compliance regulations you will need to map.
• What's your monitoring concept for the solution? Do we need to add Azure Stack to an existing monitoring service (such as Nagios, System Center Operations Manager, and Operations Management Suite)? What does this mean to the existing load? How should we connect this, as an installation of an agent is not possible because the system is locked down?
• That backup solution needs to be added, so what does this mean to your resources? Do you need to add a certain percentage of resources for the placement of the backup?

A lot of Azure Stack customers would ask whether they would need to run the complete project with the hardware OEM. This is really not the case as the consulting company you are currently working with might have a deeper knowledge of Azure Stack than the hardware supplier. The consulting company can help you prepare your Azure Stack project and decide which hardware OEM would be the one you want to go with. They could even help you fill in the Excel sheet. Later, when the hardware is up and running, your consulting company could help you prepare the offerings with Azure Stack and even create the ARM templates with or for you.

The best thing would be to have a workshop to define a basic concept of Azure Stack in your data center. During this, the answers to the previous questions should be the basis of the discussion. After having answered these questions (including the sizing ones), we can now go on and describe the big picture of your Azure Stack deployment.

After deciding how many hosts the footprint would go live for a start, the next question is always based on regions. For version 1, we could only set up one region; if we need more, there are two basic options to go with:

• Make sure your second data center is well connected and you have all management in your primary data center.
• Set up a different Azure Stack installation in your second data center and deploy all ARM templates and the portal again without any connection to the primary one.

For future releases, we can expect to have connectivity and single points of deployment of more than one region.