The cloud is often viewed as the “white knight” of enterprise IT needs. Evolving database services in particular are marketed as a cure-all for the thorny problems surrounding scaling and uptime. In this interview, VP of Marketing for ScaleArc Michelle McLean shares her thoughts on how the cloud introduces some surprising challenges.
- Q. How does the cloud introduce shortcomings that can undermine performance and jeopardize uptime?
A. The cloud offers a promise of simplicity. It is appealing to organizations because it can eliminate infrastructure management and maintenance tasks. The more sophisticated services, such as database as a service, really simplify the running of IT services. But the reality falls a bit short of the marketing. The cloud introduces a number of specific challenges that can make it harder for applications.
The first challenge is getting the database workload into the cloud in the first place. On-prem apps tend to run on big database servers. In the cloud, you’re likely to run on smaller VMs. Really big servers either aren’t available or just cost too much in the cloud. So you have to have applications that are ready to talk to “chopped-up” infrastructure – for example, four smaller database servers vs. one big one. In a database world, this is called a scale-out versus a scale-up architecture. Most apps weren’t written for this – they only know how to talk to one big server.
The second challenge is that you no longer control where the infrastructure sits. You cannot decide which server your apps or databases are running on, which means you no longer control the distance between systems, also known as hops. Having more “hops” in your data path introduces more latency compared to an environment where you control everything.
The third challenge is the noisy neighbor effect. Since you can’t control what other customers are running on the same infrastructure as you, their systems can have a negative effect on how your services are running.
Finally, another challenge worth mentioning is maintenance windows. If the resource that is running your service has to be taken down for maintenance, the cloud provider moves your service to another device. That move will affect uptime for your application, since you don’t get to control where and when the servers come and go in response to maintenance windows–the cloud provider decides.
- Q. What are the main obstacles to achieving performance and availability with cloud database services?
A. The latency issue in particular can affect database workloads, and so can the noisy neighbor affect. But the first obstacle is simply getting your apps to run on multiple VMs – you’ve got to solve that for database workloads or you can’t even get into the cloud.
What we touched on earlier is this idea that as the cloud service becomes more sophisticated, there’s less and less you have to do. And database as a service is a great example of that. I’m thinking here of offerings like Amazon RDS or Microsoft Azure SQL DB, where you have even less to do.
With those DBaaS offerings, the cloud provider handles everything from database set up to ongoing maintenance and updates. So it could sound like DBaaS solves these cloud challenges. But the big issues of running on multiple VMs and handling failover remain a challenge on DBaaS.
Let’s look at SLAs as an example. The DBaaS provider may offer a higher SLA on DBaaS than on IaaS – they control the infrastructure, so they can meet a higher level of service. The challenge is that the SLA applies to the database service itself – but what happens at the application tier? If there’s an outage “under the covers” on DBaaS, and the provider is able to use automation to restore service nearly instantly, the problem is that your application still went down. Applications are tied directly to databases. When those database resources failover or move, your apps don’t know how to follow them and may not have the ability to talk to the new location where that service is now running.
You have to separate the reality of having the database service or infrastructure available vs. having applications that stay available, even as services come and go in the cloud.
- Q. What solution does an enterprise need to help ensure that the cloud database service performs as expected?
A. Enterprises can take a couple steps to ensure high application availability on the cloud. The first is to not assume that running in the cloud absolves you from architecting for performance and uptime. In some ways, you need to think about it even more than when you were running these resources on your own infrastructure. So you should be doing things like architecting for cross-region failover and understanding what you need to have enabled in the cloud infrastructure for your apps to leverage “moving” resources. You must be able to run in multiple regions, across different zones, so that you are not vulnerable to a problem that impacts an entire region or zone.
The second step is to plan for how the application can take advantage of the cloud infrastructure. One thing that can help is to have a separation between the application and the database. When the application is directly tied to the database, it’s more vulnerable to all of the changes at the database tier. If you can have an abstraction layer in between apps and databases, one that separates the two and provides a way for the application to connect to a layer of infrastructure that won’t be moving around when the database does, you can shield the app from database changes. That abstraction layer manages the connections down to the database services, so it protects the application tier from downtime and performance problems in a way that’s not possible when the application is directly tied to the database.
As Vice President of Marketing, Michelle is responsible for overseeing all of ScaleArc’s marketing strategy and initiatives. She has more than 20 years of networking and market positioning experience. Prior to ScaleArc, she held director of product marketing positions at Silver Spring Networks, ConSentry Networks, Peribit Networks, and Trapeze Networks, and prior to that, she was director of strategic marketing at Pluris. She previously served as program director at the research firm META Group, providing technology and strategy direction to global 2000 enterprise clients. Before that, she tracked technical developments, networking trends, and vendor strategies as a journalist for two leading networking publications, LAN Times and LAN Magazine. Michelle earned her BA in English from the University of California at Berkeley.
