Being “Cloud Agnostic” Could be Costly by Kevin Epstein

Kevin Epstein is a cloud computing expert, currently working as the Cloud Computing Manager at CorpInfo. He shares insight into the costs associated with being “cloud agnostic”, including the technological complexities that are involved.

Fun Fact: Over $150 billion is expected to be spent on cloud computing in 2014.

Being “Cloud Agnostic” Could be Costly, by Kevin Epstein

“We’d like to be cloud agnostic.” That’s a phrase I’m starting to hear more and more often. At face value, it sounds like it would give you the freedom to move between cloud platforms with little or no trouble. Being cloud agnostic may in fact be a good strategy, but that depends heavily on your use case. Too often this strategy means you will leave too much on the table.

All IaaS providers offer virtual machines as a basic service, but those providers also offer other PaaS and SaaS services that complement their basic VM offering. One example is AWS’s Elastic Load Balancer (ELB), which is a fully managed, scalable, and highly available load balancing service. Other cloud providers have offerings similar in function but different in implementation and capability. The difference in implementation and capabilities from one provider to another is what we often refer to as “vendor lock-in.”

Let’s continue with the load balancer example. If you’re in the AWS cloud, the service offered is ELB. If you choose not to use ELB, you need to “roll your own” by spinning up EC2 instances, configuring the base OS, and configuring your load balancer software of choice.

The diagram on the left is a typical representation of how ELB is depicted in architectural diagrams. We see the load balancer and the multiple instances (in this case, web servers) associated with the load balancer. The diagram is a little deceiving, because what’s happening is that AWS maintains an EC2 instance running their own “secret sauce” load balancing software in each availability zone (AZ) in which you have worker instances, as shown in the diagram on the right. The diagram also starts to reveal some of the inner complexity that AWS is managing.

To replicate the ELB implementation in a cloud agnostic manner, you must deploy your own load balancing solution on EC2 instances. If you later choose to move to a different cloud provider, you simply redeploy your load balancing software onto VMs in the new provider’s cloud. In this case, let’s assume HAProxy is the load balancing software of choice. Architecturally the deployment is very similar to ELB, but all the complexity of managing the relationship between the HAProxy instances and the web server instances now falls to you. In other words, it is up to you to manage scaling in and out as your load changes by reconfiguring all the HAProxy instances. If the load becomes so great that you need additional HAProxy instances, you must manage DNS updates to route traffic between all of the HAProxy instances. This complexity has an associated cost above the cost of resources consumed.

The cost of a single ELB is $18.30 per month (as of the date of this article). This does not include traffic handled by the ELB, because there are data transfer costs regardless of whether you use ELB or your own solution. In the HAProxy solution shown in the above diagram, three m1.small instances were deployed. Currently the cost of a single on-demand m1.small instance is $32.21, so the cost to replicate the ELB service is $96.63. That’s roughly five times more expensive than deploying ELB, excluding the costs associated with developing automation and orchestration to dynamically update HAProxy as your environment changes.

Similar comparisons could be drawn for other SaaS offerings, such as implementing DynamoDB compared with deploying and managing MongoDB, or selecting to use Simple Queueing Service (SQS) over deploying and managing RabbitMQ.

Another aspect to consider is that your data has to live somewhere. If you’re going to be truly cloud agnostic, then you’ll have to store your data on your provider’s block storage offering. As before, this will preclude you from being able to leverage SaaS offerings from your cloud provider, and when it comes to moving to another cloud, you still have the task of data migration, which at scale will pose challenges of its own.

As mentioned at the beginning of this article, there may be scenarios where choosing not to use the services offered by your cloud provider may make sense. For example, if you’re a software vendor that has no control over the environment or platform that your customers will deploy your software on, being cloud agnostic is the way to go. Otherwise, as illustrated in this article, being cloud agnostic is almost certainly a more costly and complicated endeavor.

In conclusion, being cloud agnostic could be extremely costly. I recommend you do your due diligence to evaluate whether the benefits of taking the cloud agnostic approach outweighs the costs. My personal experience has been that embracing all the services your cloud provider offers is a far better alternative.

Kevin Epstein can be reached at www.linkedin.com/in/kevinepstein