Skip navigation

Geek Speak

6 Posts authored by: michael.otey

In the past few articles I’ve discussed the different aspects of moving your databases to the cloud. Based on the feedback and the talks I’ve had with people in the industry clearly most businesses have no intention for moving their production databases into the cloud. The cloud is a good fit for startups and for many businesses using the hybrid cloud provides some affordable options for disaster recovery. Although today cloud usage for production database workloads is limited there’s another place where the cloud makes perfect sense: test and development.

 

 

 

 

When your development team is working of a project they often have the need to spin up new VMs from database servers, web servers as well as development and staging systems. It’s not uncommon to need several of these for each developer. While you can certainly do this using in-house resources you need to have the capacity to do so and many times provisioning all these new VMs requires the involvement of the virtualization administrator and sometimes even the storage administrator. These VMs and server systems are usually only needed on temporary basis but this process takes both time and resources.

 

The cloud like Azure or Amazon AWS really makes sense in a situation. Developers can provision the VMs with the applications that they need from the cloud without requiring any outside support or internal compute or storage resources.  Plus, in cloud providers like Microsoft Azure provide a number of prebuilt VM templates that can speed up the creation of fully provisioned VMs from hours to just minutes. For instance, to provision a VM on-premise you typically need to provision storage for the VM, create the VM, install the OS, configure the OS, and then install whatever applications are required. This can take hours for just one VM. If you’re using a private cloud this might be faster but most businesses don’t have private clouds. To provision a SQL Server VM in Azure you simply use the Azure Portal select the SQL Server template then select the size of VM that you want and the Azure storage account to place it in and hit the button. Azure will take care of creating the VM, installing the Windows Server operating system, optionally joining a domain, and installing SQL Server. The administrator doesn’t need to be involved and the whole process is much faster than provisioning an on-premise VM. When the project is completed the developer can just tear down the VMs and get ready for the next project.

 

Testing scenarios have similar advantages. There’s no need to deploy VMs on-site. Instead you can use VM templates from your cloud provider to rapidly deploy the scenarios that you want to test and discard them when you’re done. For instance, if you need to test a SQL Server AlwaysOn deployment then you can use something like the Azure AlwaysOn template to rapidly roll out a five VM deployment that includes two domain controllers, a file server witness and two SQL Server VM with AlwaysOn already configured enabling you to rapidly deploy your test environment. You pay for the resources that you use while you use them.

 

The cloud may not make sense for most production SQL Server workloads but it makes a lot of sense for test and development work.

 

Over the course of the past few articles I’ve been covering some of the issues around moving your databases to the cloud.  While the cloud is rapidly becoming an integral part of many IT infrastructures businesses have been reluctant to move their database workloads from on-premise into the cloud – and rightfully so. The primary concern centers around the ability to remain in control of your data. When that data is on-premise you are in control of it. When that data is in the cloud that control is in the hands of the cloud provider. There are other concerns as well. The ability for multitenant cloud hosts to provide adequate performance is an important concern. Security is another big issue and for some countries there is the need to ensure that all of their data is maintained within that country’s geographical boundaries. These sort if issues make moving to the cloud difficult and in some cases impossible. However, the cloud doesn’t have to be an all or nothing affair. The hybrid cloud provides a middle-of-the-road solution that can enable you to leverage cloud technologies where they make sense yet still maintain control of and security over your on-premise databases.

 

With the hybrid cloud you can utilize your on-premise infrastructure for your day-to-day operations but also take advantage of the cloud for other related operations like backup, high, availability or disaster recovery, For instance, one of the scenarios that utilize the hybrid cloud can be seen in SQL Server’s AlwaysOn Availability Groups. AlwaysOn Availability Groups were first introduced with SQL Server 2012. However, SQL Server 2014 adds several enhancements that enable you to take advantage of the hybrid cloud. AlwaysOn Availability Groups enable you to replicate the changes in multiple related databases to one or more secondary replicas. These secondary replicas can be on-premise and used for high availability or in the case of the hybrid cloud the secondary replicas could be located in the cloud and used for disaster recovery, reporting or backups. On-premise replicas typically use synchronous replication and can provide automatic failover. Secondary replicas in the cloud typically use asynchronous replication and they require manual failover for disaster recovery scenarios. SQL Server 2014 provides built-in Azure integration that enables this kind of hybrid cloud scenario. Likewise, SQL Server 2014 also has the ability to backup to Azure enabling you to easily leverage the cloud for offsite storage. The key to making hybrid cloud scenarios work is the network link between your on-premise network and the network that’s provided by the cloud provider.  Typically you need to have a hardware or software VPN in place that bridges your local network and the cloud.  The VPN is responsible for securely routing your local network traffic to the cloud.

 

The cloud doesn’t need to be an all or nothing solution. The hybrid cloud can be an effective way to leverage cloud technologies while still maintaining your primary database workloads on-premise.

 

In the past few articles I’ve been covering the issues around moving your database from on-premise servers to the cloud. And there are definitely a lot of issues to be concerned about. In my last article I dug into the areas of latency and security but there are a host of other issues to be concerned about as well including the type of cloud implementation (IaaS, PaaS DBaaS), performance, geographical ownership of data and the last mile problem. While its clear that the cloud is certainly becoming more popular it’s also clearly not an inevitable path for everyone. Even so you shouldn’t necessarily seal the cloud off in a box and forget it for the next five years. Cloud technologies have evolved quickly and there are places where the cloud can be a benefit – even to IDBAs and IT Pros who have no intension of moving to the cloud. In this article I’ll tackle the cloud database issue from another angle. Where does using the cloud make sense? There are a few places where the cloud makes sense: disaster recovery (DR), availability, new infrastructure. Let’s take a closer look at each.

 

Backups

Off-site backups are an obvious area where the cloud can be a practical alternative to traditional off-site solutions. For regulatory and disaster recovery purposes most businesses need to maintain an offsite backup. These backups are often still in tape format. Maintaining an offsite storage service is an expense and there isn’t immediate access to the media.  Plus, there is a high rate of failure when performing restores from tape. Moving your offsite backups to the cloud can address these issues. The cloud is immediately available plus the digital backup is more reliable.  Of course since connection latency is more of an issue with the cloud than it is with on-premise infrastructure one important consideration for cloud-based backups is the time to backup and to restore. The backup time isn’t so much of an issue because that can be staged. Cloud restores can be speed up by utilizing network and data compression or low latency connections like ExpressRoute.

 

DR and HA

One of the places where the cloud makes the most sense is in the area of disaster recovery. The cloud can be a practical and cost effective alternative to a physical disaster recovery site. Establishing and maintaining a physical DR site can be a very expensive undertaking leaving it out of reach for many smaller and medium sized organizations. The cloud can be an affordable alternative for many of these organizations. Various types of technologies like Hyper-V Replica, VMware Replication and various third party products can replicate your on-premise virtual machines to cloud-based IaaS VMs. This enables you to have near-real time VM replicas in the cloud that can be enabled very rapidly in the event of a disaster. This type of solution leverages cloud storage and provides a disaster recovery solution that your normal day-to-day operations do not depend on. The cloud is utilized for off-site storage and possibly a temporary operations center if your on-premise data center fails.

 

Another closely related area is application availability. Technologies like SQL Server’s AlwaysOn Availability Groups can protect your on-premise of even cloud databases by using cloud-based VMs as asynchronous secondary replicas. For instance, you could setup a SQL Server AlwaysOn Availability Group that had synchronous on-premise secondary replicas that provided automatic failover and high availability and at the same time have asynchronous secondary replicas in Azure. If there was a site failure or a problem with the synchronous replica then the asynchronous replicas in Azure can be manually failed over to over with little to no data loss.

 

Startups

Another area where the cloud makes sense is for startups or other smaller businesses that are in need of an infrastructure update. For businesses where there’s no existing infrastructure or businesses that have aging infrastructure that needs to be replaced buying all new on-premise infrastructure can be a significant expense. Taking advantage of cloud technologies can enable business to get up and running without needing to capitalize a lot of their equipment costs.

 

Cloud technology still isn’t for everyone – perhaps especially not for DBAs and database professions -- but there are still areas where it makes sense to leverage cloud technologies.

 

 

I’ve recently done a couple of articles about cloud databases and there have been a several common responses. First, it’s clear (and I can understand why) that moving your databases to the cloud is not something most IT and database professionals are keen on doing. However, more interestingly there were a couple of common concerns that kept coming up regarding cloud database implementations that I’ll tackle in the this article. The first is security and the second is latency.

 

Security Concerns

The first and foremost concern is security. Having toured the facilities provided by several cloud hosting vendors I can definitely say their physical security far exceeds the security that I’ve seen in the normal IT environment. While I’m sure that there are very secure private IT infrastructures, I’ve never seen private IT security equal to what cloud vendors offer. For instance, last year I toured two different facilities offered by different cloud providers. One of these facilities even had ex-military armed guards at the check-in. Next, inside the facilities there were man-traps at every door where the first set of doors must close before the second set opens. Then the actual computing hardware was located inside locked cages – sometimes two locked cages that required different security access codes in order to gain access to the real hardware behind the cloud. In addition, the electrical conduits came from two different providers. This far exceeds what most business provide. Most business do not have these levels of security and reliability. However, I realize that physical security isn’t the only concern. You do have to trust that the cloud vendor will respect your privacy concerns and that is not an issue when you are in control of the data security.

 

Minimizing Latency

The next biggest concern that readers have expressed is about latency of cloud applications. The primary concern isn’t about latency caused by lack of compute power or storage performance. The bigger concern is network latency. If everything is in the cloud then network latency not an issue you really need to worry about. For instance, if your SQL Server database is primarily the backend for a web application that lives in Azure and the web application also lives in Azure then network latency really isn’t an issue. In this example, you don’t really have to worry about the latency that the public internet can introduce because the database and the application never really have to send data across the Internet. But what if you have local processing that depends on a cloud-based SQL Server database? In that scenario Internet latency really can be an issue. While Azure to Azure connections between the application and database will not be subject to Internet latency Azure or other cloud connections to on-premise systems clearly can be subject to Internet latency. The Internet is a public domain and you can’t be guaranteed that bandwidth will be there if you need it.

 

Fortunately, there are alternatives to using the public Internet to access your cloud databases. Both Azure and Amazon support private high speed on-premise to cloud connection technologies. Amazon calls it Direct Connect while Microsoft Azure calls it ExpressRoute.  Both of these technologies are essentially private cloud connections that offer more reliability, faster speeds, lower latencies, and higher security than standard Internet connections. Essentially, they connect your private network directly to your cloud provider of choice without crossing the public internet. Noam Shendar, Vice President of Business Development, Zadara Storage stated that ExpressRoute provided one to two millisecond response time for Azure access. Very fast indeed. There low latency alternatives to the public Internet can help to overcome the latency hurdles for cloud-based databases.

 

The Bottom Line

Cloud vendors typically have implemented security measures that exceed most IT organizations. However, it really boils down to trust. You need to trust that the cloud personnel will secure your data and not permit or accidentally expose your data to unauthorized access. Next, while the Internet may be an unreliable medium, high performance alternatives like Direct Connect or ExpressRoute are available. Both can provide very fast on-premise to cloud database connections – at a price. To find out more about Direct Connect check out AWS Direct Connect to find out more about ExpressRoute look at look at ExpressRoute.

 

Moving your databases to the cloud clearly isn’t for everybody however there definitely are implementations where that makes sense. Smaller businesses and start-ups can often save considerable capital outlay by not having to invest in the hardware and software required to run an on-premise database. In addition, to cost saving there can be several other advantages as well. The cloud offers pay-as-you-go scalability. If you need more processing power, memory or storage you can easily buy more resources. Plus, there’s the advantage of global scalability and built-in geographical protections. By its very nature cloud resources can be accessed globally and most cloud providers have built-in geographical redundancy where your storage is replicated to secondary regions that could hundreds or thousands of miles away from your primary region. Finally, the cloud offers simplified operations. Business don’t have to worry about hardware maintenance or software patching. The cloud provider takes care of all of those basic maintenance tasks.

 

Choosing a cloud destination

If you’ve decided to that a move to the cloud might pay off for your business it’s important to realize that not all cloud databases are created equal. There are essentially two paths for running your databases in the cloud. The main database cloud providers used by most business today are Amazon RDS and Microsoft Azure.  When you go to deploy a database in the cloud you can use an Infrastructure as a Service (IaaS) approach where you run your database inside a virtual machine (VM) that hosted by a cloud provider or you can use Database-as-Service approach where you use the database services directly. An example of an IaaS implementation could be an Azure VM running Windows Server and SQL Server. An example of the DBaaS approach is Azure SQL Database. The trade-off between the two essentially boils down to control You have more explicit control over the OS and the SQL Server settings in an IaaS VM implementation and less control over these type of factors in a Azure SQL Database implementation.

 

SQL Server - Azure Migration Tools

After you’ve decided to go with either a DBaaS or an IaaS type of cloud implementation then the next step is to pick the tools that you will need to migrate your data to the cloud. For a IaaS SQL Server implementation you can use the following tool:

 

  • Deploy a SQL Server Database to a Windows Azure VM wizard -- The wizard makes a full database backup of your database schema and the data from a SQL Server user database. The wizard also creates an Azure VM for you.

 

If you are migrating to an Azure SQL Database then you can consider the following migration approaches.

 

  • SQL Server Management Studio (SSMS) – You can use SSMS to deploy a compatible database directly to Azure SQL Database or you can use SSMS to export a logical backup of the database as a BACPAC which can be imported by Azure SQL Database.
  • SQL Azure Migration Wizard (SAMW) – You can also use SAMW to analyze the schema of an existing database for Azure SQL Database compatibility and then generate a T-SQL script to deploy the schema and data.

 

Up in the Clouds

How you actually get to the cloud depends a great deal on the type of database cloud implementation that you choose. If you want more control then the IaaS option is best. If you want fewer operational responsibilities then the DBaaS option might be the better way to go.

 

 

There’s no doubt that over the past couple of years the cloud as gone from a curiosity to a core component of many companies IT organizations.  Today Amazon AWS and Microsoft Azure are well known commodities and the cloud-based Office 365 has proven to be popular for businesses as well as well as consumers.  Today it’s even common for many business applications to be cloud based. For instance, SalesForace.com is a popular Software-as-a-Server (SaaS) application and many organizations have moved to cloud-based email. However, one notable holdout has been database applications. While there certainly are cloud-based database options business have been more than a little reticent to jump abroad the cloud for their databases.

 

Why the reluctance to move to the cloud?

 

The fact of the matter is that for most organizations their relational databases are the core of their IT infrastructure. Business critical applications are built on top of those databases and availability is paramount. While businesses can tolerate some downtime in their email downtime connectivity problems with their relational databases are unacceptable.  While there’s no doubt that internet and cloud connectivity is better than at any point in the past it this past year’s well publicized outages have shown that it’s far from perfect.

 

And then of course there are the control and security issues. Many organizations are just uncomfortable moving their data off premise. While the security of most cloud providers exceeds the average IT organization putting your critical data into someone else’s hands is a matter a trust that many organizations are not willing to make. When you data is on-premise and backed up you know you can restore it – the control remains within your own organization.  That’s not the case if your data is in the cloud. There you need to depend on the cloud provider

 

Another key issue for many international organizations is data sovereignty. In many countries like Canada, businesses are required by law to keep their data within their countries borders. In the past this has been a hurdle for many cloud providers as cloud servers could be located anywhere and they are not typically aligned with national boundaries. This is beginning to change as some cloud providers are beginning to support national data boundaries.

 

Where Cloud Database Fit Best?

 

So does this all mean that databases will never make to the cloud? The answer is clearly no. While established medium and enterprise sized businesses may have reservations about moving to the cloud, the cloud can make a lot of sense for smaller business and startups. Using the cloud can result in considerable capital savings for new businesses. SMB that may be faced with considerable hardware upgrade costs could also find the cloud to be a compelling alternative. Just as important is the fact that cloud database move many of the maintenance tasks like patching and upgrades into the hands of the cloud vendor freeing the business from them.

 

The move to cloud databases is far from inevitable but cost and labor savings make it a compelling option for new businesses and SMBs. In the next posting I’ll look at what happens if you do make that jump to the cloud.

 

Filter Blog

By date: By tag: