Recently, we launched a brand new site for one of our clients. The website is sports-related, updated many, many times a day and gets a high volume of users.
Degree 53 were tasked with rebranding and replacing our client’s existing site with a new fully responsive, content managed site. The site had a massive user base, so the user experience of transitioning from the old site to the new site had to have minimal impact on them, while maintaining performance.
For the new site we decided to go with an Umbraco CMS hosted on Microsoft’s Azure cloud platform.
From the start, we hit the ground running with Umbraco, and the site was built in next to no time, with a decent functional website demo in our first sprint. Umbraco 7+ is built upon ASP.Net MVC which enables us to take advantage of its cleanliness, ease of use and ability to debug in Visual Studio.
Additionally, from version 7 onwards, the interface for Umbraco has been completely revamped making it easy and simple to use from the perspective of the administrative user. As you can see from the screenshots below, it’s changed from a clunky old fashioned looking CMS to a new slicker and simplified one.
One of the most welcome and newest additions to the CMS is the grid editor. The grid editor allows the user to insert different types of content into a predefined layout of your choice to build pages easily. Once content is in, you can add more, edit, drag and drop in one of the easiest to use interfaces I’ve seen in a CMS yet. Traditionally, developers would have to define properties of certain types that need to be filled in for a page, which sometimes made making a page dynamic a little difficult, but with the grid editor, this is no longer an issue. I’ve seen similar products in alternative CMS’s, but not one that has been ‘baked’ in so seamlessly. Additionally, it’s extensible, so we can build components that will work with it ourselves, rather than having to use and rely on a predefined library.
Hosting with Azure
To host the project, we went with Microsoft’s cloud platform, Azure. I could mention all of the reasons why we went for Azure over their competitors but our very own Dave has already done that in his article about Cloud Computing.
Azure lets you configure an environment for your project without having to setup a new, empty virtual machine, which leaves you with more time to develop and deploy better code, spending less time fiddling with servers.
Azure now comes with a new more powerful management portal. It lets you see all of the services you have subscribed to in a single convenient place. Services such as database and hosting are offered in tiers, where the higher end tiers allow for greater traffic and more computing power, for a greater cost. The great thing about this is that you can switch seamlessly between them without any disruption to a website’s services. So if you feel you’re paying too much, and can see that you’re not getting much traffic, drop it down a tier. On the flip-side, if your site is starting to get some serious attention, you can scale up and prevent your site from falling over. In a nutshell, It just works.
Autoscale is a feature that allows you to automatically increase or decrease the number of instances that are used by your site, based on either average CPU usage or a target number of queue messages. Average CPU usage is quite self explanatory, if the site is under a lot of strain, and the instance CPU is having to work harder, you can set how much you want to push it before spinning up another instance to share the load. Similarly, queue messages are configured to send via triggers, and a certain number can indicate a reason to spin up a new server. Applications will automatically scale down once they are no longer triggering these conditions after a safe, set period of time.
Additionally, and arguably more importantly, there is a whole host of data visualisations including bandwidth usage, database usage, error reporting, with data going back days. As we’ll mention later in the article, this proved invaluable.
Static IP Address
One of the issues we faced was the website needed to connect to a third party API where access to the data was only granted once the IP address was whitelisted. This proved difficult as the site is an ‘Azure Web App’. By nature, these don’t have static outbound IP addresses, as they are designed to take the most efficient outbound route.
Quote from Azure: "Web Apps is intended to be useful for corporations, developers, and web design agencies. For corporations, it's an easy-to-manage, scalable, highly secure, and highly available solution for running presence websites. When you need to set up a Website, it’s best to start with Azure Web Apps and proceed to Cloud Services once you need a feature that’s not available."
The static IP was the feature we needed from the Cloud services, and the ‘Web Role’ is one of the cloud services that would give us up to 5 free ones. Our solution was to implement a separate small web role project, that would act as a proxy between the site and the third party API.
You may be wondering what the difference between Apps and Roles are, I know I had been. Apps are designed to be similar in operation to those offered by traditional hosting companies, with the added benefits that Azure can offer. Such as removing the need to tinker and configure web servers and removing a level of maintenance that other providers require. Web Roles are one of the cloud services, which you may also see by competing vendors as ‘Platform as a Service’. They provide developers with much more control over the environment, without having to worry about updates, upgrades and maintenance. We live in an age where time is a commodity, and if Azure gives me this, I’m smiling.
Now that the proxy has a static IP, it could be whitelisted and accessed via the main website, which didn’t have any barriers to it as it is all contained on the same ‘network’.
Content Publishing with Multiple Instances
For sites with a lot of traffic, load balancing can be used to distribute traffic across multiple servers to improve reliability and performance.
With Umbraco, traditionally to allow for failover, multiple servers would have to have been set up, each with their own instance of the site. Setup for this was a little cumbersome, each of the servers had to be acknowledged in configuration files. Replication would then be setup to copy media between the servers by configuring Microsoft Distributed File System (or a different method) which was a difficult and time consuming task.
Azure helps us do this as every instance of the site uses a shared, single file system. No configuration required and no need to worry about replicating the files to each of the instances. Using this method of sharing a file system, we can also take advantage of the Autoscale feature, which allows Azure to intelligently increase or decrease the number of instances in use, meaning you only pay for what you use.
When content is published in Umbraco, content data is written to the umbraco.config file. Umbraco reads the file into memory, to serve data the fastest way possible to a user’s browser, without the need to retrieve from the database. Umbraco has a setting in it’s configuration, ‘XmlContentCheckForDiskChanges’, that means that it will keep an eye out on the umbraco.config file for changes, and if so will update the data in memory. As they all share the same file system, this means that all instances will update.
It’s worth noting, that the constant monitoring of the file did nothing noticeable to degrade site performance.
Breaking: As of version 7.3 of Umbraco, configure-less load balancing come out of the box. All that is needed is for each of the instances to point to the same database, the functionality to monitor changes is all automatic!
At Degree 53 we specialise in amongst other things, sports-related websites and mobile apps. These can gain a great deal of its traffic through social media or a push notification in a mobile app. We know this can cause large spikes in traffic to a website’s services, and these could occur at any moment. What this means for us, is that we have to carefully select the hardware tiers that the site and the database run on. For example, if we leave it on a high tier to accommodate for the spikes in traffic, bandwidth and processing power, the client would end up paying for all of this extra power, even at times when the site isn’t particularly busy.
To further reduce the amount of power required by the site, caching is our friend. Caching is not a new concept, so we implement it as much as we can throughout our websites, as standard practice. Umbraco has a built in content cache and has a dynamic cache for any macros which gives the site a huge performance boost, ensuring a better experience for users.
A final challenge we faced that I think is worth mentioning was the task of user migration. The client’s existing website had a very large number of existing users, that had to be persisted on the new site. The greatest obstacle here was ensuring that members could still login to the new site, however, the previous site was a Wordpress one, and the new one, Umbraco. Long story short, we were able to overcome the issue by writing a custom Membership provider, and using an encryption method known as Blowfish. Although this isn’t specifically a reason to use Umbraco, it’s worth knowing that changing CMS to Umbraco is not a problem.
What we’ve learnt is that by using Umbraco, we are able to develop highly bespoke solutions for our clients, safe in the knowledge that they will be up to the task with scalability and performance in mind and a great user experience. By coupling with Azure we are able to offer reliable performance. The nature of software development means that we are provided with challenges every day. But, by testing and using these tools, we’re even closer to delivering products and services, pain and hassle free.