Skip to main content

ARM Scripts - Extending T-shirt size concept

Working with Azure Resource Manager (ARM) deployment scripts as with any other scripts can be a challenge. Especially in the moment when you want to run a deployment script.

Why?
How often did you discover that to be able to run a script you need to specify a lot of parameters? The happy case is when a default value is already specified and even if you don't know what happens behind you don't care and only 'click next button'.
I observed that the number of parameters is directly connected with the size and complexity of the deployment. After a specific threshold, the number of parameters that don't have a default value is high, making almost impossible to run the scripts.
Because of this, complex pre-deployment steps would require a lot of time, especially when it is the first times when you make that deployment or something change.

I remember one time I saw a deployment scripts written in ARM and PowerShell that was a state of an art from the way how it was designed and written. As long as you would be able to understand and specify the correct value of each parameter, the deployment script would create and configure for you an ultra complex system, with more than 1.000 components.
Making the script working by specifying the right value of each parameter is another story.
There were many other configurations, but you made an idea.

VMs T-shirt Size
The T-shirt concept is simple, can be understood by anybody and is extremely useful when you need to specify the tier size.
It's more simple to specify a size of a T-shirt like Small, Medium, Large or X-Large than having to specify the VM size and/or the number of instances.
Without T-shirt size you would need to ask yourself how many instances of a specific VM I need ? 2, 6 or 12? Are 4 or 8 enough? What is the minimal size of a VM that is acceptable, should I use the default one or I need another size?

The T-shirt size resolve this for you. By allowing the person that defines the deployment script to specify the size of T-Shirt for number of VMs and/or for the VM tier.
Number of
"vmsNumber": {
      "small": 2,
      "medium": 6,
      "large": 12   
    }
"vmsSize": {
      "small": A2,
      "medium": A4,
      "large": A8   
    }
In this way, not only the number of parameters is reduced, by also the complexity of parameters is reduced to a basic concept - to words not numbers. Now, based on the load of our system and other parameters we only need to specify small, medium or large.
You might say that this reduces the level of customization - yes, you're right. In the same time, don't forget that not all the time you need this customization and flexibility level. In most of the cases the scenarios are simple and clear.
A great article about this topic can be found on Endjin blog.

T-shirt at next level
T-shirt size helped us to resolve the parameters values, making this value more clear and simple to understand. Even with T-shirt size, the number of parameters was not reduced to much. We still need to specify values for different configurations like:

  • Redundancy levels
  • Replication level
  • VPN type
  • Backup policy
  • Encryption level
  • ... and many more...
But, if we analyze the parameters we will observe very often that there are multiple parameters that are connected between each other. When value of one of parameter is X, another parameter value is Y and so on.
This means that we could group together parameters under a T-shirt model. By having parameters for configuration like:

  • Deployment Size (small, medium, large)
  • Security Level (low, medium, high)
  • Redundancy Level (low, medium, large)
  • ... 
By specifying this values we could have default values for:
  • Deployment Size (small, medium, large)
    • VM Tier and Number
    • DB Tier and Number
    • Service Fabric cluster size
    • App Service Tier
  • Security Level (low, medium, high)
    • Encryption level
    • VPN connectivity (if is not required or not)
    • Routing and firewall configuration of appliances
  • Redundancy Level (low, medium, large)
    • Storage replication
    • DB and VM Backup policy
    • Communication 
As we can see, we can use this simple concept to group other parameters also, making scripts more simple, easy to read and understand.


Conclusion
Being technical persons, we try all the time to make a scripts configurable, adding as many values as possible in the parameters. Often we forget that the person that runs this scripts might not be so technical as we are or to understand all the dependencies between all parameters. 
Offering a deployment scripts with less parameters might be useful especially when our target audience are sciences or persons that are not technical. 

Comments

Popular posts from this blog

Windows Docker Containers can make WIN32 API calls, use COM and ASP.NET WebForms

After the last post , I received two interesting questions related to Docker and Windows. People were interested if we do Win32 API calls from a Docker container and if there is support for COM. WIN32 Support To test calls to WIN32 API, let’s try to populate SYSTEM_INFO class. [StructLayout(LayoutKind.Sequential)] public struct SYSTEM_INFO { public uint dwOemId; public uint dwPageSize; public uint lpMinimumApplicationAddress; public uint lpMaximumApplicationAddress; public uint dwActiveProcessorMask; public uint dwNumberOfProcessors; public uint dwProcessorType; public uint dwAllocationGranularity; public uint dwProcessorLevel; public uint dwProcessorRevision; } ... [DllImport("kernel32")] static extern void GetSystemInfo(ref SYSTEM_INFO pSI); ... SYSTEM_INFO pSI = new SYSTEM_INFO(

Azure AD and AWS Cognito side-by-side

In the last few weeks, I was involved in multiple opportunities on Microsoft Azure and Amazon, where we had to analyse AWS Cognito, Azure AD and other solutions that are available on the market. I decided to consolidate in one post all features and differences that I identified for both of them that we should need to take into account. Take into account that Azure AD is an identity and access management services well integrated with Microsoft stack. In comparison, AWS Cognito is just a user sign-up, sign-in and access control and nothing more. The focus is not on the main features, is more on small things that can make a difference when you want to decide where we want to store and manage our users.  This information might be useful in the future when we need to decide where we want to keep and manage our users.  Feature Azure AD (B2C, B2C) AWS Cognito Access token lifetime Default 1h – the value is configurable 1h – cannot be modified

What to do when you hit the throughput limits of Azure Storage (Blobs)

In this post we will talk about how we can detect when we hit a throughput limit of Azure Storage and what we can do in that moment. Context If we take a look on Scalability Targets of Azure Storage ( https://azure.microsoft.com/en-us/documentation/articles/storage-scalability-targets/ ) we will observe that the limits are prety high. But, based on our business logic we can end up at this limits. If you create a system that is hitted by a high number of device, you can hit easily the total number of requests rate that can be done on a Storage Account. This limits on Azure is 20.000 IOPS (entities or messages per second) where (and this is very important) the size of the request is 1KB. Normally, if you make a load tests where 20.000 clients will hit different blobs storages from the same Azure Storage Account, this limits can be reached. How we can detect this problem? From client, we can detect that this limits was reached based on the HTTP error code that is returned by HTTP