The Cloud: What Does it Mean for your Current Applications?

Andrew Philp 15th February 2016

What are you running? You may be running applications like SharePoint, Exchange, SQL Server if you look after a Windows environment, or MySQL, Tomcat, Apache and MongoDB if you’re looking after a Linux environment.

Let’s use Microsoft SQL Server as an example. In the on-premise world, you’d perform a capacity plan, finding out how much resource you need to dedicate to each database and any special requirements. You’d then place an order for a server, or ask your team to create you a VM with the required amount of IOPS, CPU, bandwidth and so on.

How does this differ in the Cloud?
The Cloud – a magic pill for the enterprise?

The real answer is it doesn’t. You still need to plan, implement and maintain the same way you would on-premise. The real magic happens when you want to adjust the amount of resources dedicated to one database.

On-premise, you’re most likely going to over-provision your resources to ensure there’s never a surge that exceeds your available capacity. In the Cloud, you can provision towards how much capacity you’ll need most often, rather than over-provisioning.
Cloud Services that can make this happen

One great service that can help you do this is Elastic Database Pools in Microsoft Azure SQL. This service allows you to specify a number of DTUs or “Database Throughput Units” which give you the ability to cover surges in capacity, then scale the performance back to where you need it once the surge is over. It also means you can start developing an application using a low price tier of Azure SQL, then move it up to a Standard or Premium tier with no customer downtime.

Another service that can help achieve this is Amazon Relational Database Service, or “RDS” for short. Although lacking the granular ability to scale performance like Azure SQL, you are still able to resize according to demand. Using the best practice Multi-AZ option, downtime is reduced to a matter of minutes.
Cost implications for these services

In the Cloud, you have to remember that these “magic” solutions carry a cost benefit when used correctly. Rather than over-provisioning and paying for the extra capacity all the time, you can closely follow your demand and scale accordingly. This means when the database is least used, you pay less and when you need more performance you only pay for that extra performance when required – usually on an hourly basis.
I really need “full fat” Microsoft SQL Server!

Even if you need a Microsoft SQL Server with SQL Server Agent available, this is an option in the Cloud. You can easily run it on a VM or EC2 instance (major Cloud providers actually give you an image with SQL installed which is charged at a higher hourly rate to cover the licensing costs) with the same amount of control over settings that you would have on-premise.

This allows you to build clusters, AlwaysOn Availability Groups or even use good old fashioned mirroring or log shipping. Running SQL Server on a VM also means you can have more architectural choice over where files are stored, for example a best practice Cloudreach follow in Amazon EC2 is to:

  • Ensure tempdb is on ephemeral storage for best performance, there is no need to ensure this data is retained after a reboot as SQL Server rebuilds it as required
  • Ensure the Transaction Log is on the fastest storage available, usually Provisioned IOPS
  • Ensure that the data files are on quick storage, usually General Purpose SSD

 

Magic still needs a DBA

All these great solutions make it easier than ever to get exceptional performance, save money, and work effectively in the Cloud.

The most important thing to remember with hosted database engines in the Cloud, such as Amazon RDS or Azure SQL, is that the fundamental job of a DBA still exists. DBAs must ensure they perform the same steps that they would in an on-premise environment in terms of sizing Transaction Logs appropriately, ensuring tables have the correct indexes and making sure not to overload a database instance with too many heavily used databases.

Oh, and don’t forget backups!