Every Cloud Has A Silver Lining and Every Cloud Has A Gotcha

Introduction

There are whole bunch of articles which speaks about the advantages of Cloud, what it provides and how it can transform your enterprise IT. However, there are few things you may want consider to consider. This post aims at providing those so called “gotchas”.

Common Gotchas

  • You may not attach any of the hardware tools or instruments to your cloud server. Perhaps you can connect to the tool to the local machine and then connect that machine to the cloud.
  • Outbound traffic (Egress) is being charged and this is little uncommon for hosted environment or shared environment.
  • You need a payment method like Credit Card tied to your cloud usage account. However there are alternative payment methods available too.
  • Running your existing application on 2 machines doesn’t mean you will achieve 2X performance.
  • Sometime you may need to re-code / re-develop the entire application to make it a cloud fitment. Don’t think System Integrators just deploy your application base. They know what to be changed, where to be changes and how to be changed. 
  • Evaluation of cloud-ability of your application is little tricky and critical as well. This is when you talk to a Cloud Solution Architect.
  • Cloud is cheap, yes ..!!!, but also check whether it is cheap enough for you as an individual / enterprise.
  • Think about the ephemeral storage and know about it before you move to the cloud. It is both powerful as well as very thin ice.
  • Putting your application doesn’t mean, you empower your entire application 100% up-time. Actually you plan to minimize the difference between the actually up-time percent from 100% in continuous process.
  • Each of the Cloud Components have different SLAs and each of it are near 100% and not 100% and this by extension; the combination of Cloud Components in your application make the overall uptime move away from individual SLA availability.
  • Sometimes, you don’t speak about SLA when you don’t play by their rules [example : running your web app in a single server, although the if recommendation is minimum 2].
  • Sometimes, the cloud provider can pull down your application and re-launch it in different machine / rack for several reasons like data center operations, fault tolerance. 
  • Scaling is doable, already done by several. But make sure you can do it for your app. Think about downsizing, or scaling-in the servers which are already serving the requests.
  • If the pricing for 1 Compute unit is X and this need not mean the price for 10 Compute units will be 10X. Always look at the pricing and pricing slabs. As my boss (Harish Ganesan) says “In Cloud always know about what is being charged and not how much is being charged“.
  • Know about Scale-Out vs Scale-Up. Sometimes Scale-Up would what you are look for instead of Scale-Out.
  • Keeping Cloud things together and having a good affinity is an easy way to start tuning at performance. Before doing that, check whether you have all the cloud components you require in the region or zone you want to put your application. It doesn’t makes sense unless you are crazy to have the web server in the US and Database Server in Singapore.
  • Putting your data on Cloud is safe and stop worrying about the Cloud provider looking at your data or selling the data. There are legal terms and certifications which Cloud providers tell when you just click the “I agree”. More important thing to worry about it to check with your local-legals or jurisdictions about whether you can move to Cloud; as sometimes critical data like Health Care or Financial Data shall not be put in a place outside your country’s geographical territory. If you belong to this ground, this is where you can start thinking about Hybrid Cloud, Direct Connect or Private Cloud (if you are filthy rich).
  • Every single cloud component is tied to costs directly or indirectly. The only thing which you get for free is the Bills for Infra Consumption. Sometimes the API for accessing the consumption data is also being charged under overall bill.
  • Outage is not just Cloud Provider’s problem it partly yours too. You need to think about this and plan for HA (High Availability) over inter-geography data centers. It makes sense to look about what to do when there is an outage instead of taking the SLAs and Cloud Providers to Court. Remember you have your customers although your also a Cloud provider’s customer. 
  • Cloud Providers have support, know when to contact their support or your support. Always investigate from where the problem comes not where it shows up. Your application’s flaw can bubble up to give your an illusion of the problem of the Cloud provider.
  • Understand STATELESSNESS your application must qualify that test before moving to cloud.
  • Most of the costing is payment per hour and also know about stopping in a mid of an hour and check out the cost for partial hours calculation.
  • You may not exactly know how long will it take to spawn up an infrastructure, or terminate an infrastructure. 
  • Stopping an Instance is different from Terminating an Instance. Check whether your application’s behavior during the process.
  • SaaS, PaaS, IaaS more oriented toward what you need or how deep you need the control and not what they provide.
  • Not all Cloud Components would carry an SLA although they could carry a price tag. This could be due to the reason of the Preview / Beta status of the Cloud Component. I learnt this from my cloud guru (Raghuraman Balachandran)
  • Know the limitation of the “FREE-TIER” or “FREE-USAGE”. This is more like a post paid phone bill and chances are that, you can exhaust the free tier in just few hours.
  • Developing a missing component or tool for the Cloud Provider would just be amazing but behold, the same Cloud Provider may release it in the next iteration, possibly for free and tightly integrated as well.  My first lesson learnt from my Manager (Jithendra Balakrishnan). This doesn’t discourage you to developing one. Think though the needs of the devops.

Motivation Behind Writing this Article

The points listed above doesn’t mean these are flaws of cloud. No…!!! It is not so. It means that these are considerations you need to evaluate before you jump or fly in the Cloud. The disadvantage of an the automobile cannot be as it requires fuel to run. The above is such so. 
In Cloud you always plan for the failure and look for possibilities of failures and fix them. You don’t get failure free infra, rather you get a whole infra galaxy to fix your failures.

Always Remember “Cloud not a Revolution but an Evolution“.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s