Migrating Your Database to the Cloud? Look Beyond MySQL

Companies are migrating infrastructure to the cloud in order to achieve advantages and agility that they need to remain competitive. However, they may have difficulty achieving one extremely important benefit of cloud computing as they attempt to run their MySQL databases in the cloud - scalability in true utility fashion. Similar to the power utilities we are all familiar with, this entails the ability to get what you need, when you need it and pay for only what you use, even during peak demand.

Why switch to the cloud if databases like MySQL limit scalability and performance? It's very simple: the advantages of shedding the headaches of managing one's own machines and reducing operating and capital expenditures are still too great to ignore. However, organizations are in many cases shortchanging themselves by focusing narrowly on these financial and operational benefits, not realizing that the right cloud database will dramatically increase flexibility and agility.

People far too often assume that "going to the cloud" is synonymous with "having the ability to migrate to a scale-out database." In reality, one does not necessarily follow the other. Adding more confusion, many companies are migrating to the cloud to use Aurora, which provides marginally more write/read scale than RDS MySQL, but still imposes a write performance ceiling.

This lack of ability to achieve true utility will be particularly acute for applications with OLTP (online transaction processing) workloads that are both high in volume and need to maintain data integrity through ACID compliance. These characteristics are shared by most applications that serve e-commerce, ad tech, gaming, social and IoT functions, and the inability of MySQL to meet their demands in utility fashion is largely attributed to one fact: it is architected for "single node" deployment.

The single-node conundrum: when "cloud" doesn't equate to "scale out"
MySQL databases are often the initial solution of choice for OLTP applications because of their ability to maintain ACID compliance. Though MySQL databases are commonly deployed in the cloud, they also run on a single server, and don't allow you to "scale out" by adding server nodes like most cloud applications. Eventually, this lack of ability to scale by adding nodes means that organizations running MySQL in the cloud will be hamstrung by the same performance problems that existed before they made the migration from the data center.

Scaling comes in many flavors, and some taste pretty bad
If the company in question is an e-commerce provider, for example, it is likely to experience dramatic seasonal changes in demands on the database that coincide with major shopping holidays, which requires flexibility. If the company is a rising star in a data-intensive industry like digital healthcare, it may find that its need for rapid scaling of capacity is the most important consideration.

If they're using a single-node solution like MySQL or Aurora, a primary method of increasing capacity, once they've scaled to the upper limit of the server they're using, will be to "scale up" by moving the database to a more powerful server. This method - which is neither rapid, nor flexible - will set you back a ridiculous amount of money for large, expensive hardware that can achieve the maximum level of performance that might be required. Inevitably, this capacity will lie unacceptably dormant for some period of time, which means you will be stuck paying for unused capacity for off-peak traffic periods (i.e., most of the time). This is an unnecessary waste of money and resources, one that the cloud is supposed to help companies circumnavigate.

For many companies, this is only the start of the problems associated with scaling their database. Even the largest server will impose a capacity ceiling, and once that is reached, they often resort to alternate methods for scaling performance, such as creating additional read slaves, master/master configurations and then finally sharding. These, however, are problematic - they either:

• Don't add write scale (read slaves)
• Have conflict management issues (master/master)
• Don't provide ACID transactional guarantees (sharding)

In short, in seeking to extend write scale beyond the limits of MySQL on the largest available server, painstaking programming and a highly undesirable level of complexity and fragility are often added to the application. Instead of a streamlined application, you wind up with a makeshift patchwork that requires a lot of effort to keep afloat.

Of the three scaling techniques mentioned, read (only) slaves are the most common technique for scaling out capacity once the upward limit of a single-node implementation has been reached. In fact, Amazon RDS provides 15 "read replicas" very simply via their AWS Console. However, as Marc Staimer of Dragonslayer Consulting pointed out in "Why Traditional SQL Databases Fail to Scale Effectively," while read-only slaves require nominal setup and maintenance, they "cannot overcome the bottleneck of the master SQL database, especially for write-intensive applications." Which brings us to a consideration that is of paramount importance - the ability to scale in both reads and writes.

Scaling reads isn't enough, but sharding isn't the answer
Scaling along the read axis can be helpful, but services that handle OLTP loads will eventually hit a wall if writes cannot be scaled in addition to reads. There is no shortage of services out there, like Amazon's Aurora, that do a good job scaling reads in the cloud, but don't scale writes without building complicated and expensive solutions (giving you the "patchwork" application described above).

Many cloud providers, including AWS Aurora, do not support sharding, a method commonly used to yield scalability in both reads and writes. And, even when sharding is supported, it is difficult, costly to implement and fragile while in use. It can be problematic with workloads that require full data integrity, due to the difficulty of maintaining ACID compliance without making comprehensive changes to the application layer (once again leading to undesirable complexity and fragility). Ultimately, those who employ this method wind up exchanging one set of problems for another potentially more serious set.

Suffice it to say, most companies moving to the cloud do not anticipate having to resort to sharding, yet many will find themselves in that exact predicament due to ever-increasing transactional demands. These kinds of barriers are exactly the ones that companies aim to overcome when they set out with a cloud database migration project.

OLTP cloud database needs scale-out performance with ACID compliance
Many companies don't realize that their most common database hiccups often stem from their efforts to jerry-rig them to do things they weren't designed to do, not because the databases themselves are fundamentally inferior. MySQL wasn't designed to scale out (horizontally), and rather than performing unnatural feats in order to make it do so, organizations should instead look to solutions that are architected for this type of scaling.

The NewSQL era has made it possible to scale out by adding nodes, while maintaining linear performance. And, for companies with transactional applications - such as those in e-commerce, gaming, social, IoT and ad tech - they will be able to maintain ACID compliance the whole time.

There may be initial advantages to platforms like MySQL for small operations, but IT decision-makers should have their eyes on the exit route if their companies project any kind of serious growth. Playing catch-up with databases is nobody's idea of a good time, and is an untenable business practice when an organization's applications rely on OLTP. A database that can massively scale horizontally to increase or decrease capacity according to dramatic seasonal swings in traffic, or scale to very large total capacities, may not be deemed necessary by a fledgling service or company with fairly nominal requirements. However, if a company sees rapid success in the near future, such capabilities are likely to become a necessity - and what management team is worth their salt if they don't plan for success?

Many are in fact acknowledging that moving up from MySQL and its kin to the next tier of database is a necessary stage to prevent slowdowns and failures for businesses with high-growth services. This new reality is certainly evidenced in the popularity of Aurora. But again, companies must keep in mind that Aurora, despite its improvements over MySQL, is a single node with old school scale techniques solution, and thus presents limitations. The best way database companies can serve these kinds of organizations is to offer a drop-in replacement for MySQL that delivers the linear scalability that enables you to fully leverage the flexibility of the cloud.