One of the things that is so “fun” about working with Microsoft Azure, is the near constant rate of change in the platform. I did put fun in quotation marks, but I really mean it—if I had to work on the same things every day my job would become quite boring. Part of this constant rate of change, means there are always new products and features in the pipeline. While there are some architectural standards around availability and design, each Azure service has some its own unique nuances.
As MVPs and Microsoft Partners, the way we get new features and services to our customers typically goes down the following path:
- A product group announces plans for a new feature or service, and we get excited about it
- We might play around with the service in a test environment so we can confirm it does the thing we expected it to do
- We then find or encounter a customer scenario which could benefit from new feature or service
- We implement the service at a customer
Of course, given that we are talking about cloud computing, most services have direct costs that are associated with them. We expect cloud to cost money, but Microsoft is quite generous with cloud credits to MVPs and Partners to allow us to test and do proof of concepts. However, because of cost models, some services are just untenable for MVPs and customers because of high cost of entry.
StretchDB—A Case Study
When SQL Server 2016 was in preview, Microsoft introduced a feature called StretchDB. This feature allowed you to extend a table or tables to an Azure SQL Database. While the feature had limited functionality, conceptually it was cool. If you had cold data that wasn’t actively queried, and needed storage space, you could archive that cold data into the cloud for a relatively low cost, as initially you could choose whichever tier of Azure SQL DB you wanted—I frequently demo’ed this feature with a Basic SQL Database that cost $5/month. Sometime before SQL Server 2016 went generally available (GA), the decision was made at Microsoft that StretchDB was going to be platformed on a StretchDB SKU of Azure SQL Data Warehouse with a minimum cost of thousands of dollars of month (it used a premium SKU of SQL DW). This effectively killed the feature to the MVP community and frankly most customers—I haven’t seen any adoption of this feature, which also means there probably won’t be investments from Microsoft into the feature gap.
StretchDB isn’t the only service that I’ve encountered with this problem. Azure services that either have extremely high fixed costs or have highly unpredictable variable costs are really unattractive to customers.
What Should Microsoft Do?
Some services are inherently expensive—if you think about Azure SQL Database in the Business Critical tier, you have the functional equivalent of a three node availability group, with three copies of your data on local flash storage. That’s a solid amount of compute resources, and I can understand why it cost what it does. However, SQL Database also provides the Basic service tier at $5/month, which is nearly the functional equivalent of a $40,000/month 80 virtual core business critical database. (There are some minor functional differences and the obvious capacity differences) This allows developers and partners to get comfortable with the service at a low price point and grow their adoption over time.
I have a few basic architectural tenants that a lot of Azure services do, that I think should be across the board for all service offerings:
- Ideally, have a low-cost SKU, that has enough compute power for demos and proof of concepts
- If your service must have a very high fixed cost, ensure that the service has a pause functionality, so that the compute costs do not have to run 24/7
- If your service has a high degree of variable costs, share internal (Microsoft use) customer scenarios and billing, so that customers can get a decent idea of what their costs are going to look like
Making cloud services cheaper to get started with will help overall adoption. When a new service is launched and I can’t tell a customer what their bill is going to be, or that the costs are going to be thousands of dollars a month just to try them out, adoption is going to be limited. I think adopting these tenants across Azure services would help adoption.