Will Database in the Cloud (DBaaS) meet your Business Growth Needs?

The demands on enterprises to improve time to market is driving firms of all sizes to move their databases to the cloud. Even companies used to rolling their own technology solutions are drawn to cloud databases. While DBaaS cloud offerings are gaining more traction as a solution for changing workloads and environments, that need to evolve and meet new business demands comes with its own set of caveats and issues.

Will Database in the Cloud (DBaaS) meet your Business Growth Needs? Source: Percona

Before moving to the cloud, it is important to carefully define your database needs, plan for the migration and understand what putting a solution into production entails.

This article discusses the following subjects on moving to the cloud:

What is “the cloud” exactly, and why are businesses moving to it?
Should you move your business environment to the cloud?
What questions should you ask a potential DBaaS provider?
What are the things you need to plan for and be aware of to ensure a smooth transition?

Read on this article to find out how to define your cloud provider requirements, plan for the migration and understand what putting a cloud solution into production entails.

Content Summary

Introduction
Taking the Plunge
Provider Attributes
(Geo) Location
Latency
Compliance
Services
Service Level Agreements (SLAs)
Architectural Decisions
Availability
Scalability
Backup Strategy
Compatibility
Migration
Testing
Conclusion

Introduction

Today, keeping your enterprise agile and flexible is not just an advantage, it is a requirement. Many of the systems and processes that once were owned by businesses are being moved offsite to “service” models: Platform as a Service (PaaS), Software as a Service (SaaS), Infrastructure as a Service (laaS), etc. These services are usually referred to as being “in the cloud”- meaning that the infrastructure and management of the service in question is not maintained by the enterprise using the service.

A recent RiqhtScale survey of enterprises has 72% of respondents using some form of cloud services• This number is expected to grow.

When it comes to database environment and infrastructure, more and more businesses are moving to the cloud to manage this vital part of their business organization. Database services provided in the cloud are often referred to as Database as a Service (DBaaS).

Data storage has, for most of its existence, followed a consistent model: stable and static big box devices that were purpose-built to house data. Needing more storage space meant obtaining more (or bigger} boxes. Classic scale-up storage. Need more, go to the data storage vendor and order a bigger box.

The problem is that data is exploding, and has been exponentially for the last decade. Some forecasts predict that IP traffic generated worldwide will increase at a rate of 22% CAGR per year. That kind of increase, and at that speed, doesn’t leave a lot of ramp up time to make long term big box hardware investments. Things are changing too fast. At the same time, the database performance requirements are also increasing. Convenience and cost savings can’t be had at the expense of performance.

The immediate trend- evident by declining revenues of class storage boxes- is placing a database in a cloud of scale-out storage.

Cloud computing benefits include scalability, instantaneous configuration, virtualized consumables and the ability to quickly expand base specifications. Moving workloads to the cloud brings with it numerous business benefits, including agility, focus and cost:

Agility. The cloud enables businesses to react to changing needs. As the workload grows or spikes, just add compute cycles, storage, and bandwidth with the click of a mouse.
Focus. Deploying workloads to the cloud enables companies to focus more resources on business-critical activities, rather than system administration.
Cost. Businesses can pay as they go for the services level they need. Planning and sinking money into long term plans that may or may not pan out is not as big a problem.

Not everything in the cloud is always “better.” Cloud deployments have issues that could be construed as downsides:

Security. The biggest red-flag for many companies is loss of security control. Once you move to the cloud (especially a public cloud) you are ceding your privacy and security practices to whatever that cloud institutes. This might not work with the type of data you want to house in the cloud- for example, online trading records or medical information.
Lock-in. Moving to a cloud services provider for some or all your database(s) means that you can become dependent on that provider. Once you are in, it can be practically or economically impossible to move away from the chosen solution.
Loss of insight. The freedom from infrastructure oversight that the cloud provides can also have a downside: lack of insight into your database. If you aren’t monitoring your database from day-to-day, how and why it runs the way it does becomes less transparent.
Passivity. It’s easy to be more passive with the way your database and application consume resources when you can upgrade with the click of a button in the cloud. But this passivity can come with a steep price if “more, please” is your go-to solution. Being diligent in fine-tuning your database, application, and eliminating unnecessary data storage is important to keeping cloud costs at a minimum.

Taking the Plunge

Now that you’ve decided to move to the cloud, what are the things you need to be aware of in order to make sure you make the transition as smooth as possible? These decisions can be divided into four main areas:

What provider attributes matter?
What architectural decisions matter?
How do I migrate my database?
What pre-production testing should happen?

How can you address these concerns? Read below.

Provider Attributes

There are many, MANY different cloud providers out there, and most provide a lot of the same services and guarantees. How do you choose one for your data? It’s going to depend on your specific use case and needs. Different workloads have different requirements.

Four key provider attributes that can affect performance are location, latency, compliance and services. Most providers have these attributes, but it really comes down to a matter of size: bigger and more popular providers will have a greater number of options (but will cost more). It’s important to make sure the provider you select matches the needs of your database environment.

(Geo) Location

Location refers to where the cloud provider’s servers are physically located. If you’re accessing remotely, why care about this? As we’ve all recently seen in the news around hacking, natural disasters and other issues, geographic areas can be affected by outages beyond the control of the provider. If your data is crucial to your business, you might want to know exactly where a provider houses their data infrastructure, and if it is in more than one place.

For example, AWS has multiple “Availability Zones” and data centers across the globe, connected by fiber optics. These centers can help pick up the traffic and load of an out-of-commission center in case of an emergency.

Another important point is that the closer you are to your data, the faster your response times will be. More and more, things like web page load times are crucial to retaining customers and maintaining brand strength. As microseconds are counted in how we measure user experience, the time it takes data to travel over the physical network can matter.

Latency

Closely tied to location (and your distance from DBaaS data center), is latency. Speed and performance are of the essence today. The cloud only performs at the level of its slowest connection.

There are several factors that can affect latency: connection location, network speed, network routes, mobile vs. hardline, etc. An application user requests something (such as a web page). The application sends a request to the database via the network (usually in part over the Internet). The database processes the request and returns a response along the same path. Each point in this journey requires a certain amount of time. The collective amount of time required to send, process and return the request is known as latency.

Latency. Source: Percona

According to TechTarget, the database can be one of the biggest sources of latency issues.

The length of time between a user request and the cloud database response could be a deciding factor in your provider selection. For example, in Google’s Site Performance for Webmasters video, presenter Maile ohye states that “2 seconds is the threshold for e-commerce website acceptability. At Google, we aim for under a half second.” You can bet it’s even less now. If the user’s experience (and your applications’s responsiveness to their requests) is paramount to your business goals, then latency (and the database’s contribution to it) should concern you.

Compliance

Compliance is another potential stumbling block for cloud adoption. When you move your database to the cloud, you are reliant on the compliance policies of the provider – and they may not meet the criteria that are required for you to do business. There are several compliance standards and agencies that stringently enforce data rules (HIPAA, PCI, SEC, ISO/IEC, etc.).

The main questions regarding compliance you should be asking are:

Where is our data residing?
Who is watching it?
Who can access it?
How is it protected?

With these answers, you can determine if the cloud provider can manage your data within compliance standards.

Services

From a management standpoint, you need to understand what services a database cloud provider can offer. Do they use a relational or non-relational model? Both? Are they just housing your data, or can they help you manage, monitor, architect and troubleshoot your database? Is your current database language compatible with the cloud service provider? Does the provider in question use proprietary languages or tools? Knowing the answers to questions such as this can prevent getting “locked in” to a cloud vendor that doesn’t meet the needs of your database environment.

The more you pay, the more services can be provided. But as your company grows (and with it, your data) you want to make sure that your database cloud provider can grow with you (without breaking your bank). You will also want to know if they can help you troubleshoot issues as they arise, and what the turnaround time on the solution will be (otherwise your business can be seriously impacted).

Service Level Agreements (SLAs)

This discussion around services directs us to service level agreements (SLAs)- the guaranteed time within which services are delivered by the provider. SLAs are the standard measure of how well a provider is doing. These can be crucial to your business goals, if you rely on database to do business.

You should be sure to get SLAs in a contractual agreement, signed by both parties. The contract should cover the following:

Lists the minimum levels required for each element of the service, as well as actions or penalties for not meeting these levels
Guarantees that you own your data, and have a right to get it back
Discloses the system architecture and security, and your ability to review it
Lists reasonable methods for terminating service

Architectural Decisions

The architecture of the database cloud provider can be a crucial factor in determining whether they are right for your data. One of the most important questions is how open is the architecture. The more open the architecture, the more flexible it can be in meeting your requirements, and the less likely you are to get “lock-in” to the vendor.

The key question to ask a provider is “Will my database share its resources with other databases and companies?” A vendor is most likely sharing your resources with others, and thus must restrain the activities of your data so that it doesn’t affect others using the same resources.

There are three main cloud architecture layers:

Enterprise Resource Layer. This layer includes things such as hardware, storage, virtualization and network infrastructure. You should already be familiar with what works best with your data. You must decide if you will insist on using the same thing as on-premises, or trust the cloud to either match your resources, or find resources that work as well.
Platform Layer. This layer hooks applications into the stored data via an API or similar methodology. How this interacts with the applications can affect things such as latency and performance, and can create new levels of overhead that can hamper the user experience.
Platform Management Layer. This layer provides the methods of interaction between developers, IT, the business and the enterprise’s cloud infrastructure. Do you need to manage a hybrid cloud, or multiple clouds? Do you need to bring up and tear down instances regularly, and quickly? Are you looking to accelerate application innovation? This layer is where these functions can occur.

Making the correct choices regarding architecture is important to avoid “lock in” with a provider that prevents agility, flexibility, scalability or an ability to manage cloud resources. The various layers of the cloud infrastructure, while distinct, must interact in a way that complements data use and application requirements. There are many configurations and options at each layer, and no provider will share the same strategy- just as no enterprise will have the same cloud architecture needs as another. You must clearly define the data requirements for your business that will engender success in the cloud.

Availability

High availability environments provide substantial benefit for databases that must remain available. A high availability database environment co-locates a database across multiple machines, any one of which can assume the functions of the database. In this way, a database doesn’t have a single point of failure.

There are many HA strategies and solutions, so how do you choose the best solution among a myriad of providers? The first question to ask is “what is the problem am I trying to solve?” The answers boil down to redundancy versus scaling versus high availability. These are not necessarily all the same!

Do I need multiple copies of a database in event of a disaster? {Redundancy)
Do I need to increase read and/or write throughput? {Scaling)
Do I need to minimize outage duration? {High availability)

When you are planning your database environment, it’s important to remember the CAP Theorem applies. The CAP Theorem breaks problems into three categories: consistency, availability, and partition tolerance. You can pick any two from those three, at the expense of the third.

Consistency. All nodes see the same data at the same time
Availability. Every request receives a response about whether it succeeded or not
Partition Tolerance. The system continues to operate despite arbitrary partitioning due to network failures

High availability databases attempt to eliminate single points of failure, and prevent the end user from experiencing any loss or diminishment of service. Attaining a highly available database environment in the cloud is possible, but comes at an ever-increasing cost (depending upon requirements). Determining the level of high availability necessary for your environment is crucial to determining the nature and configuration of your database cloud infrastructure.

Scalability

Scalability, in general, refers to the ability of something to function as it grows larger. For databases, this means the ability to perform at expected levels as the database workload increases. When building an enterprise, and growing your user/customer base, database scalability concerns can be critical to meeting business goals.

There are two main paths to scaling: vertical and horizontal. Vertical scaling is adding more resources to a single server. This means more memory, more CPUs, more instances, etc., within the specified machine. Horizontal scaling is adding more machines to a specific function (for example, the database). This allows you to balance the workload across several separate machines (which can also be scaled vertically).

Vertical scaling cuts down on operational costs and management overhead, but puts a hard limit on the amount of scaling that can be done within a specific machine. Horizontal scaling provides more flexibility, but can quickly become cost-prohibitive.

When selecting a database services provider, you should understand what the opportunities and limitations are, from the perspective of scaling. Will your provider be able to continue to provide agreed upon performance levels even as you scale up your business, and what are the costs of that scaling going to be?

Answering these question helps “future-proof” your cloud database deployment.

Backup Strategy

Database crashes can and do happen, and you need to be prepared. A highly-available architecture, when it makes sense for business objectives, should be the first line of defense. However, high availability cannot prevent disasters from happening. In the event of such an instance, it’s evident such a crash will cause downtime- and surely some business impact in terms of revenue. Can you do something to reduce this impact?

The simple answer is “yes” by doing regular backups (of course). Choosing your provider might come down to: will their current backup strategy really work if an outage occurs? How much precious time will pass (and how much revenue will be lost) before you get your business back online? And will there be any data loss associated with recovering from a backup?

Backups can be considered the step after high availability fails. If we’re using a multi-master database environment, and something occurs that kills the database and the high availability can’t save the day, what do you do? Backups are a key piece of “business continuity.” Also, factor in the frequent need to restore data that’s been altered by mistake. You may think you have checks and balances in place to prevent these issues, but user-error has been the cause of several highly-publicized, recent outages for well-known, respected companies. These mistakes will inevitably happen given time and this is where backups are invaluable.

Compatibility

Another important architectural consideration is software versioning. If, for example, you are up-to-date with the latest version of MySQL (5.7), and your desired provider is only using 5.5 (for whatever reason), you might lose database functionality by migrating.

Are the key database features that your application leverages available in your provider? Are you dependent on these features to enable your applications? Are the storage engines, plugins, connectors and data specifics you are using in your application and database environment compatible with your chosen cloud provider’s environment? These are the kinds of considerations that can be often overlooked. They can make a migration turn into a nightmare or worse a failure, causing a rollback to be necessary.

Migration

Once you’ve made your decision to move, how do you do it? Actually, this part is simple and well-defined. It depends on the provider, of course, but through such common practices as replication it’s relatively easy to move an instance to the cloud for staging in a provider environment. Additionally, a migration provides a unique window to question your original assumptions and make necessary changes. Often, users undergoing a major migration, such as a move to the cloud, seize the opportunity to make necessary architectural changes.

Any provider is going to have a migration strategy that they use (and it should be well-proven).

This migration process minimizes downtime and prevents data loss (assuming it’s enacted correctly, and the procedure is fully followed and adhered to).

Testing

A final component to moving to the cloud is testing, testing and more testing. As in any major IT restructuring, simply making the move and then hoping it all works isn’t really an option. You need to find out how easy, comprehensive and feasible it is to test your new cloud database infrastructure (at real-world levels) BEFORE going live.

Does it work with the applications correctly? Is it meeting the required performance levels for a good user experience? Are the provider SLAs being met? Is your backup strategy reasonable and workable? These questions are essential to answer before making the switch.

Conclusion

The keys to successful deployment are asking the right questions of the provider, and making sure the answers match the requirements of your database environment:

What provider attributes matter?
What architectural decisions matter?
How do I migrate my database?
What pre-production testing should happen?