Top Links You Must Click On
From the Blogosphere
Migrating Your Database to the Cloud? | @CloudExpo #API #Cloud
Companies are migrating infrastructure to the cloud in order to achieve advantages & agility they need to remain competitive
By: Mike Azevedo
Feb. 15, 2017 02:00 PM
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"
Scaling comes in many flavors, and some taste pretty bad
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:
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
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
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.
Reader Feedback: Page 1 of 1
Enterprise Open Source Magazine Latest Stories . . .
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week