As you probably know by now, the release of Sitecore 8.2 update 1 included full Sitecore Azure Web Apps support. I, along with the entire Sitecore community, am very excited about this release.
This release provides a number of benefits for all Sitecore developers, partners, and customers. Here are my top five reasons why Azure Web Apps and Sitecore together are a very good match.
It takes 15-20 minutes to provision a vanilla Sitecore environment. 90% of that time is spent waiting on Redis Cache to provision.
You have two options to spin up your Sitecore instance in Azure.
The first is to use Azure Marketplace which provides Point and Click setup of Sitecore-approved topology and provisions a vanilla Sitecore deployment to the selected datacentre. While this option is very easy and requires no knowledge of Azure, you are tied to the Sitecore-approved topologies.
The other option is deploying using Azure Resource Manager (ARM) templates, which allow you to configure and deploy your full Azure resource setup for your solution, including all services and server roles. The great benefit of the ARM templates is that they can be used to deploy the Azure Resources consistently and repeatedly. You can use Web Deploy and DACPAC packages to fully automate the deployment including the setup web sites and databases.
If you’re a developer, the ARM templates would be the preferred way of working.
We did not supply a custom installer for Azure Web Apps as this would limit your deployment options (which is what happened with the Sitecore Azure Module). We want to make sure you have the full capability and flexibility of ARM at your disposal for deploying Sitecore into Azure.
Does this mean that you have to know more about Azure than you did before? Yes, but you gain a lot more flexibility than you had previously. We didn’t choose to build a custom solution for deployment, but instead based our solution 100% on Azure standards. By doing this you have a lot of resources available on Azure Web Apps. You can use these resources to educate yourselves and apply it on your Sitecore solution.
We also released scripts with the Sitecore Azure Toolkit to provide basic examples of how to execute an ARM template. It is supposed to serve as a starting point evolves to suit your needs. Currently, we provide PowerShell CmdLets to simplify Azure provisioning, with ARM templates with default server setups.
Don’t forget to check out our getting started documentation to help you out. We’ll expand those topics over time to suit your most common pain points.
As general guidance I would definitely suggest that everyone learn about ARM and ARM template deployments via courses like Plural Sight.
One of the great benefits of hosting your web site in Azure Web Apps is the ability to automatically scale your instance.
There are different ways for auto-scaling. The first is to choose your min and max amount of server instances, and then choose a metric (e.g., CPU Percentage) and a target range for it. If the metric goes above the target range a new instance will be created (until you get the max instance count). If the metric goes below the target range max on an instance then that instance will be deleted unless you are already at the min number on the instance count.
A second option for auto-scaling is to use rules, which can be defined in a way similar to how you would create rules in Outlook. Much like Outlook you can create multiple rules and chain them together to create a more specific scenario. Each rule you create can use the same set of metrics available in the previous auto-scaling approach. Note: Sitecore metrics cannot be used here.
While auto-scaling should be the preferred approach because it enables you to keep your costs low, you also have the option of simply picking a specific number of instances and sticking with it.
Scaling-out is not the only option, customers can also scale-up their Web Apps (on the associated App Service Plan). Scaling up simply means increasing the resources available on the App Service Plan that a Web App lives on and typically you will only do this for increased number of CPU core and RAM, but there are addition benefits such as an increase in the number of potential instances of an App Service Plan you can create.
By hosting Sitecore in Azure you’re already encouraging your development team to use best practices. Best practices that weren’t that important for on-premises hosting might be crucial for the success of your solution on Azure. Hosting your solution on Azure forces you to think differently and will encourages you and your team to build applications that are robust, scalable, and that support elasticity.
However, along with benefits come a few restrictions to the system. For example, you can’t change any register settings, run custom DLL or programs, use the filesystem, change IIS settings, or forget to update Windows or SQL. These restrictions might be annoying at the start, but these “restrictions” will make your solution faster, stable, and more robust down the line. While this might take some additional effort, time, and increase complexity, these restrictions will actually prove to save you pain in the long run.
This is one of my favorites benefits of Azure and Sitecore; the increase of productivity in development, debugging, and monitoring. Our close alignment with Microsoft Azure means we maximized the value and benefits for you. We extended default Azure, so you can use all the greatness of Azure in combination with Sitecore.
This pays off in with a decrease in development time, error handling, and proactive monitoring of your solutions.
With the new Sitecore Azure PaaS approach you only ever need to worry about publishing your customizations to Azure and not an entire Sitecore setup. This makes developing in Visual Studio easier because you will have far less files in your solution and publish much quicker.
Also by leveraging the Web App and Source control integration you get a consistent, repeatable, fully automated deployment. This helps to lessen the possibility of manual mistakes during deployment.
It becomes much easier to roll back to a previous version of your code base as new changes are automatically picked up and deployed
If you run into issues in an on-premises hosted solution you will typically deploy a web project with the customErrors flag in the Web.config file set to On or RemoteOnly. After this you get error messages, which in general aren’t as helpful as you hope they would be. Even if you get a detailed error message, it doesn't provide enough information, and of course, in the beautiful world of software development, you can't re-create the error locally.
With Azure Web Apps you can use Visual Studio to connect and interact with the cloud as if the whole cloud is sitting right under your desk. You can create, publish, and debug Azure-hosted websites all from a single development environment.
With the availability of Remote Debugging, Visual Studio brings you a cohesive and unified web-development experience from beginning to end. You can set breakpoints, manipulate memory directly, step through code, and even change the code path!
Have you ever waited for IT to provide the log files or other information from the live server? With the new update, all Sitecore logging, tracing, and performance counters are rerouted to Application Insights that you can access through the Azure Portal. You don’t have to wait anymore...
With Application Insights you can monitor the health of your Sitecore solution. This single interface allows you to see the health of your Sitecore infrastructure right from within your browser.
The details you can get are great—you can do high level monitoring with Application Map, drill all the way into the log files and bad requests, and build custom charts using both Azure and Sitecore telemetry data. You can even create email or web-hook alerts based on Sitecore or Azure metrics.
All Application Insights data can be synced into a PowerBI. This synchronization enables you to create health monitoring dashboards for your site that is more approachable to people outside of development and IT.
With Sitecore hosted on Microsoft Azure you will save money on hosting, maintenance, and costs of employee. You use only the hardware you need. Azure will automatically scale up and—maybe more important—down based on server load or other defined rules/thresholds.
There is no need for you to maintain a big server farm. You can host a Sitecore solution without a big hardware investment up front and without the worries of hardware failure like hard disk failures, failover systems, and power outages. This also cuts down on worries about software like operating system updates, database updates, and software licenses. In short, no need for active support from IT.
And I haven’t even talked about the big cost reduction that comes from increasing day-to-day work productivity around: quicker setup of DEV, QA, and live environments; out-of-the-box integrated deployment processes with Visual Studio or your own Continuous Integration/Development solution; remote debugging; and pro-active health monitoring with App Insights.
The idea of this post was to keep is short and simple, but that didn’t work out well. There is just so much great stuff around this release. That’s why I tried to list my five highlights to get you started. There is much more greatness and details around this release, but I couldn’t fit it all into one blog post.
Luckily I’m not the only one that’s very excited about this release—the community is loving it! The reaction on Twitter and Slack have been very positive and there is already a fair amount of blog posts written about the release.
You can! Everything around Sitecore Azure is based on the standards of Azure Web Apps. So basically you can start educating yourselves on Azure Web Apps and use that knowledge for your Azure Web Apps-powered Sitecore solutions. Here is a list of resources you can use to get started.
(last update: 8 December 2016 - 1 week after release)
Do you have something (blog post, webinar, video, etc.) to share about Sitecore Azure? Join our great community! Ask your question on community.sitecore.net or sitecore.stackexchange.com, or join the conversation on Twitter (#Sitecore and @pieterbrink123) or on Sitecore Slack chat.
Pieter Brinkman is Director of Technical Marketing at Sitecore. Follow him on Twitter @pieterbrink123.