Cloud – From Freedom to Jail, then back to Freedom

Cloud – From Freedom to Jail, then back to Freedom

Freedom and flexibility are the main reasons people move to cloud, especially when there are tools like AWS RDBMS. They allow you to move to cloud and freed from your current on-premise vendor.

With a BONUS!

They also provide the tool that can help you to convert your database from one platform to another, FREEDOM!!!

But without realizing it, we are merely switching from one vendor, to another. Meaning from an on-premise vendor to AWS or other cloud service provider.

So what? It save costs!

Switching to cloud provider will also switch your steady and paid-off budget to an unpredictable one. The calculator tools do provide us an forecast on the cost, but its not a real final costing.

Especially on the storage tier and data transferred, the design was meant for scalability, but it requires trades off with the visibility of cost, unless you have planned it well ahead.

And as an IT infra guy, its our job to imagine for the worst case scenario.

What if, there’s a day we need to move out from the current cloud service provider?

Can we do it? Is the data and app portability there?

Cloud service providers has brought us tons of convenience, at least for developers:

  • DynamoDB – hosted database service, no more yum or apt-get install
  • S3 – unlimited storage for files, easily accessible and code-able with API
  • Elastic Load Balancer – forget about haproxy configuration

From configurations to architecture designs, we can easily do everything by referring to the API doc of cloud providers. Unless there’s no service to do it, we will spawn our VM for it. And by doing this, we jail ourselves, by the goodness of APIs,

It’s very difficult, if not impossible to move out. For example, in the case of AWS, I will have my DB in DynamoDB, cache is coded for Elasctic Cache, coded in Lambda, all media stored in S3.

Dropbox, the infamous cloud storage has moved out by giving in enormous engineering effort: https://www.wired.com/2016/03/epic-story-dropboxs-exodus-amazon-cloud-empire/

Just like disaster recovery plans, and security contingency plans, its an cloud engineer job to make sure cloud infra is not tied down to single point of vendor, back to FREEDOM:

  • Avoid using ‘as a service’ as much as possible
  • Follow industry standard of software instead of provider locked down software
  • Deploy infra across multiple cloud provider
  • Move the system to your own datacenter, when the cost of doing so has gone lower than a huge public cloud infra