Years ago, before the virtualisation technology became mature enough to support critical production applications such as SharePoint, companies would invariably be required to setup a whole new set of physical servers to support such applications. Then along came virtualisation and that task got a lot easier, once we didn’t really need to worry about each one of those physical servers individually, but rather focus on big resource pools like the VM hosts. Unfortunately, when resourcing such hosting servers, we still needed to account for peak performance requirements even though such resources may lay underutilised for the most part of a day. But what if we could eliminate the cost associated with all that idle time?
While it’s close to impossible to achieve such an objective within our own private datacentres, that’s exactly what a cloud hosting platform such as Microsoft Azure allows us to do. Azure has been designed from the ground up to be elastic, allowing for resources to be allocated and de-allocated on demand. There’s absolutely no commitment to minimum usage, you pay only for what you have consumed. Although we will eventually get to a point where there will be a fully elastic model, now where resources are automatically allocated and de-allocated, today there’s still something we need to do ourselves to achieve a similar result. It’s up to you to allocate and de-allocate resources.
The concepts I will discuss here will definitely apply to most applications to be hosted within a virtual machine environment, but I’m focusing specifically on details regarding a typical SharePoint farm deployment. Please note that this is potentially the first part in a series, and today I’m going to focus on architectural aspects of such a solution. I’m planning to return with more technical details regarding the implementation and automation of the concepts discussed here, but for now I’m going to remain at a more conceptual level. Feel free to reach out to Empired in case you have any specific questions regarding any particular technical details of such implementation until then.
Before I proceed, let me list the basic concepts and assumptions you should have in mind. Those will not be discussed in detail here, therefore you may need to look for further reference in case you are not familiar with some of these concepts:
- This is not a discussion regarding the use of Office3665 (O365) versus an Azure hosted SharePoint farm. I’m assuming you have already evaluated the use of O365, and have found very specific reasons to have your own deployment instead. This includes occasions where a hybrid deployment is required
- Azure allows you to setup a site-to-site VPN, and although SharePoint servers are sitting on Azure’s datacentres, they are effectively part of your Domain Network. That’s not the only possible setup, but potentially the one you will be after for an application such as an intranet
- Although the site-to-site VPN setup can be done over the Internet, Azure allows you to connect to your own datacentres directly via the ExpressRoute
- While some of the infrastructure licenses (for example, Windows and SQL Server) are included within the VM subscription rates, not everything is included. For instance, SharePoint licenses (including the required CALs) must be handled separately
Okay, now that we are all set you may be wondering what the key benefits of this approach are.
Ensure your users experience the best performance a SharePoint farm can offer by utilising premium resources, such as high performance storage and processors and also large amounts of RAM. Such resources can be quite expensive to purchase on your own, but they are available at a very compelling rate via Azure, as Microsoft provides those resources at a very large scale, ensuring optimal price.
- Tune resources up when most needed, while tuning them down - or even completely off - when not needed. With Azure, you only pay for the resources that are effectively allocated at any point in time, therefore, such operation may represent massive savings. Here’s an example considering current hardware resources/rates available, and a typical small farm topology:
a. Total yearly cost of a high performance farm: $140,000.00
i. 4x SP Servers (8 cores, 56GB RAM, SSD Storage)
ii. 2x OWA Servers (8 cores, 14GB RAM)
iii. 2x SQL Server Ent (8 cores, 65GB RAM, SSD Storage)
b. Total yearly cost of a reduced performance farm: $35,000.00
i. 2x SP Servers (8 cores, 14GB RAM)
ii. 1x OWA Server (4 cores, 7GB RAM)
iii. 1x SQL Server Ent (4 cores, 14GB RAM)
c. Total yearly cost with elastic farm approach: $65,000.00 (savings: $75,000.00)
i. High performance [a] running Mon-Fri, from 8am – 6pm
ii. Reduced performance [b] running during remaining off-peak window
NOTE: dollar figures above have been obtained using Azure Pricing Calculator (as of 24/07/15), and have been rounded for simplification.
The specifics would vary greatly depending on company specific requirements, and yes, this may not be always feasible, however for most typical scenarios we are effectively providing users with better performance, while benefiting from a reasonable amount in direct savings. I’m also not even considering other indirect savings such as productivity improvements due to higher performance.
Okay, this sounds good so how do we set it up? As I’ve mentioned before, I’m not going to go into the specific technical details in this post, but from a high level architecture perspective, here’s what’s involved:
- Setting up your SharePoint farm in Azure. This may be a brand new farm, or just moving out from current on-premises deployments. As mentioned earlier, you will probably be looking into setting up a site-to-site VPN with Azure in case you don’t have one yet. Overall the experience should be completely transparent to end users, as SharePoint is effectively running within your domain network
- Evaluating server activity logs and identifying inactivity windows where specific roles/servers are being underutilised
- Scripting out the transition between high/low performances resources for each one of the roles where a reasonable inactivity window is identified. This may also include turning off redundant resources in the event there are specific windows where high availability is not required. Such operations will typically take between 1-5 minutes to complete
- Re-evaluate your farm topology and identify any additional benefits that can be obtained with further flexibility on server resources. You may, for example, consider the use of dedicated servers for specialised loads instead of being restricted to small/medium farm topologies
- Orchestrate the scripts for dynamic resource allocation according to utilisation windows, and potentially some manual/automated triggers that will support exceptional scenarios. For example, you may consider an option to allocate additional resources during specific periods where you expect heavier usage, or when special activities are taking place. Please note that Azure offers additional services to support you with such automation, so should be able to implement everything within the platform itself
So there you have it. Although this is just a bird’s eye view, hopefully it is enough to raise you awareness to the benefits of cloud hosting solutions that are available today, no matter how large or small your solution is.