Unleash the Potential of Power Platform With a Center of Excellence
Business innovation often comes from within. Discover how to empower innovation from non-traditional developers with the Microsoft Power Platform.
Like all of my peers here at Perficient, I have an MSDN Subscription that comes with a sweet monthly credit for a Microsoft Azure Subscription. By default, your Azure Subscription will have a spending cap, so that if you use up your credit you don’t have to spend any dough just because you forgot to turn off a beefy VM (although now they have a helpful Auto-Shutdown feature). The problem this causes is that you cannot use the Azure Marketplace Sitecore 9 app.
If you try to deploy Sitecore version 9, your deployment will fail with a cryptic message, “Bad Request”. All of the resources needed for Sitecore 9 look like they were created, but unfortunately because this step failed the downstream configuration and installation doesn’t continue. If you trace the details you will find that it comes from the ARM template for the CurrentBillingFeatures component in Application Insights. If you browse to the Application Insights resource and select “Features + Pricing”, you will see that you cannot configure your cap because of the Azure subscription cap. The ARM template fails because the daily cap cannot be changed. The only way to allow it to be changed is to remove the spending limit indefinitely. I know this sounds scary, and it actually should frighten you as even the smallest Sitecore 9 configuration will destroy your wallet. I’ll get to some cost saving tips and recommendations for Sitecore later.
If you update your subscription to remove the spending limit, you should know that you won’t be able to add it back until the beginning of the next billing cycle (which likely doesn’t align with the beginning of the month, BTW). If you want to try this at home I recommend waiting until near the end of your billing cycle, or be prepared to delete everything pretty quickly after creating it. Removing the spending limit does allow the installation to succeed.
If you pick the smallest Sitecore topology, “Single”, you will have two App Service resources (each one costing $44 a month)- one for your CD/CM/Processing/Reporting etc., and another for xConnect. You also get a whopping TWELVE (12) Azure SQL Databases. If you don’t know about DTUs then you should take a minute to read up. The default configuration gives you three S1 DBs and eight S0s, for a total of 150 DTUs. I would immediately put all of them into a single SQL Elastic Pool. I went with the smallest size, 50 shared DTUs. In my limited testing this was more than sufficient for an idle website, but a 50 DTU pool is $100 a month, whereas the Sitecore default configuration would run you $210 a month. You’re welcome! I will leave updating the ARM template and submitting a pull request to the Sitecore ARM Template repo as an exercise for the reader.
You also get a Search service resource, which is what will really break your bank. It looks like you might be able to get away with the free version of the Search service if you deleted one of the 4 indexes that Sitecore creates, as the other limits (number of documents, index size) are well under the threshold by default. The Search service in its default configuration will run you about $8 a DAY. You cannot currently change the price tier of a Search service, so you’d have recreate a new search service resource and delete one of the indexes (maybe the suggested test index?). You are probably well past the point of this being worth it, as you can get a 8 vCPU, 32 GB memory VM for less than $100 a month (assuming you only run it 10 hours a day Monday – Friday). However, if you only have access to a browser and you absolutely have to have a new Sitecore 9 instance running in approximately 30 minutes, accept no substitute.
* Not really that cheap, I guess
Greetings. Excellent article.
I’m planning to deploy XM scaled using msdn subscription. Will face similar spending limit issue?
Yes, XM will also use Application Insights and you will run into the same problem using an MSDN subscription.