The cloud has turned traditional data management on its head and there’s no doubt we’ve seen a renaissance of the database – particularly good-old SQL databases – because of it. When it comes to the cloud, people think they will be able to command endless resources while still being able to deploy, run and consume a distributed data solution anywhere, anytime. In this slideshow, Razi Sharir, CEO of Xeround, dives into the challenges that come along once your database is in the cloud.
Click through for nine database challenges found in the cloud, as identified by Razi Sharir, CEO of Xeround.
The cloud environment is not predictable and needs to be closely monitored and managed. Besides the large-scale cloud outages we’ve all heard of (such as the Amazon-EC2 US-East meltdown last year), we have to face the facts: server crashes, hardware malfunctions and other blips in the “cloudy” skies are all part of the territory.
There are hardly any SLAs for databases in the cloud. To prepare and run effectively on the dynamic cloud environment, every database, regardless of its size, must run in a replicable setup, which is typically more complex and expensive.
In the cloud, high availability isn’t just about hardware resiliency anymore. Being removed from the actual physical resources, you can’t just plug in an extra power supply or network card, or swap hard drives, etc. Maintaining high availability in the cloud depends on the availability of ‘more of the same’ resources and the ability to dynamically provision them on the fly once a failure is identified.
While scaling an application is pretty straightforward, scaling the database tier is more difficult – particularly when scaling out by adding nodes. Cloud applications are often characterized with fluctuating demand (that can spike at any moment). Your DB needs to be able to instantly and automatically scale both in throughput and size to accommodate any demand from the application.
The cloud is all about flexibility in resources – allowing you to add/remove resources to match your needs, with no need for over-provisioning or over-paying to prepare for any future peaks. Elasticity isn’t just about increasing resources when you need to – by scaling up or out – but also shrinking those back down when your database is underutilized, to save on costs. Elasticity needs to be supported to accommodate very granular increases in resources – so that to gain +0.X more power doesn’t mean you need to commit any pay for a much larger (+XXX) machine.
Cloud IT operations are tedious, complex and often more cumbersome. Maintaining high availability requires continuously monitoring the cloud environment for any failures, configuring auto-failover mechanisms and keeping multiple copies of the DB tier always synchronized and ready to spring into action. Ensuring elasticity means you need to monitor and re-configure and deploy your servers (and sometimes change your app) to add additional resources or to remove them if they go underutilized.
Developers flock to the cloud – and with good reason. The flip side is that once the application gains momentum, running it effectively – and the DB in particular – requires a skill set not readily available for most developers. To allow developers to focus on their code rather than on the IT, the cloud ecosystem provides a myriad of off-the-shelf development platforms and cloud services to integrate with to streamline development and time-to-production.
For high-availability setups, scalability requirements, multiple regions or other considerations, many applications rely on distributed databases architectures. Because of the ‘stateful’ nature of the database (unlike the application, which is ‘stateless’), maintaining multiple active/master copies in several locations or even clouds requires building logic to handle conflicts, network problems, latency, etc. to ensure data consistency and availability.
For cloud providers, PaaS, SaaS and other large customers that need to run thousands of databases simultaneously, multi-tenancy enables a cost-effective and operationally efficient framework. Yet, achieving real multi-tenancy isn’t the same as simply installing multiple database copies on the same virtual machine. You want to ensure consistent performance, minimal “noise” between applications/users, and be able to support high availability for each instance, as well as scale with it as it grows. And you want to minimize the management overhead of keeping it all running.
