Parameters vs Architecture

As an architect that works with Microsoft partners, I often get direct perspectives and opinions about Azure. These insights are sometimes obvious to me but are completely new to partners. Here's something that happened recently and I thought I'd share to help all architects everywhere on their cloud journey.

Automation

We all know that the cloud makes it easy to spin up some service, try it out and shut it down when we're done. The cloud also makes it easy to automate doing these things. If we build some parameterization into our automation then it's easy to spin up services for different kinds of environments.

• Basic/cheap tiers for dev and test, and
• Premium/expensive tiers for production. Easy right? Not so fast!

The reality is that many times there are architecture implications based on what SKU or tier of a service you are going to deploy. The basic tier usually does not support all the features and integrations of a premium tier. This makes building automation a little more complicated. You can't just swap out parameter values - you will need to adjust other architecture components.

An Example

Azure Database for MySQL is a PAAS database service from Azure. It comes in several tiers - basic, general purpose and memory optimized. The basic tier does not allow for a feature called Service Endpoints.

Service Endpoints are a way for you to lock down who can access the service. With a service endpoint, you can say, 'only allow traffic from this subnet in this network to access my service.' That's a useful feature in a production scenario when you want to really restrict who can access the service. There are other ways to lock down access but that is beyond the scope of this article.

If you set up a Basic mysql database and try to connect from a VNET that has a Service Endpoint enabled. You will get an error.

But, if you set up a General Purpose mysql database and try to connect from a VNET that has a Service Endpoint enabled, it works.

You can build an Azure Resource Manager (ARM) Template to automate deploying these service. But when you want to deploy in a real production environment with a Service Endpoint, you will need to add additional components. See the example below.

        {
            "type": "Microsoft.DBforMySQL/servers/virtualNetworkRules",
            "apiVersion": "2017-12-01",
            "name": "[concat(parameters('servers_mrichtermysqlgeneral_name'), '/serviceendpoint')]",
            "dependsOn": [
                "[resourceId('Microsoft.DBforMySQL/servers', parameters('servers_mrichtermysqlgeneral_name'))]"
            ],
            "properties": {
                "virtualNetworkSubnetId": "[concat(parameters('virtualNetworks_hcm_perf_vnet_eastus_externalid'), '/subnets/serviceendpoint')]",
                "ignoreMissingVnetServiceEndpoint": false
            }
        }

You need a way to build automation that includes this for production environments and excludes this non-production. It's a little more complicated than swapping parameters when deploying this arm template.

Obviously this is just a simplistic example. You can imagine a solution with many different services can get much more complicated.

Just Be Aware

As you can see, targeting different environments can have an impact on your automation. Azure does give you some ways to address this. ARM Templates support conditions, logical functions and nest templates. You can build a template that says If MySQL is Basic tier, use dev template, otherwise use prod template. You can learn more about flexible arm templates from this blog article.

So, yes: it is possible to create a single set of automation for a solution that targets different service tiers, utilizing different features for different environments. It's just a little bit more complicated than swapping parameter values. Be aware of this when planning your Azure cloud journey.