Application Cloud Readiness Checklist

September 30, 2014 Thomas Orozco

Cloud readiness assessment checklist

“Is this app ready to be deployed to cloud?”

If your organization is planning a migration to cloud (and today, who isn’t?), this is a question you’re going to ask a lot. But how do you tell? Look no further: here’s a checklist of what you’ll need to validate before you can label an app “cloud-ready!"



1. Is the deployment of your app automated?

If you’re considering migrating an app to cloud, chances are that you’re doing so because you want to actually take advantage of what cloud has to offer: you may want to make your application available to customers (internal and external) under a self-service model (i.e. automated), or take advantage of autoscaling.

But to do so, you just can’t afford to have “page a sysadmin” be a part of your deployment process:

  • It’s not really self-service if you have to file a ticket with IT to get a sysadmin to deploy the app.

  • It’s not really autoscaling if there is a manual (and often slower) deployment step.

So, instead, your application must be deployed in a fully unattended manner.



There are of course many, many ways to go about automating the deployment of your application. In a cloud environment, it’s common to use a configuration management system (like Chef or Salt).

More recently, Docker has been gaining significant momentum for that purpose too (look out for an upcoming blog post on this topic here!).


2. Is the lifecycle management of your app automated?

In a cloud environment, you can’t rely on the underlying hardware or virtualization layer to keep your application running in spite of hardware failures (and this creates new opportunities in terms of app architecture!). If the underlying hardware crashes, so will your app.

There are of course a few exceptions (e.g. in case of failure, AWS may attempt to migrate and reboot EBS-backed instances on another node), but the general rule remains that apps designed for the cloud must account for the possibility of unexpected failure.



Application lifecycle management is of course unique to every application, but two things must be ensured at a minimum.

First, application data should be stored in a persistent location e.g. a database, an object store or block storage. Second, you should be able to automatically replace application servers if (or when?) they crash; a Cloud Management Platform like Scalr can help you with this, or if you don't mind the lock-in, cloud specific features like AWS AutoScaling Groups also exist.  


3. Is the coordination of your app with its environment automated?

Apps rarely live in isolation. They need to be configured, and coordinated with other applications. For example, the backend for a mobile app will probably need access to a database to store and access user data.

But, like we mentioned in #2, if your database itself is running in a cloud, then the servers it runs on may occasionally crash (if only partially — databases like Cassandra are very-well equipped to deal with this kind of failures).

When that happens, your app needs to gracefully handle the situation. Unfortunately, there is usually a minimum degree of coordination that’s necessary (if your database master is being failed over, your app needs to update its configuration).



Here again, there’s a vibrant ecosystem of tools to help you. The most common tool is of course to use DNS and rely on DNS timeouts for your app to update its records.

DNS does introduce latency, though, and DNS caching implementations may sometimes get in your way (e.g. the JVM default configuration may cache DNS lookups forever!). An alternate solution is to use cluster discovery software (like ZooKeeper, Consul, or Etcd).

Ultimately, the key to make an app cloud-ready is automation. If you’ve thoroughly automated your app, and there is no manual step involved in deploying and operating it, then it’s probably cloud-ready!

If your app isn’t there just yet, we encourage you to explore the solutions exposed above (you can also review this earlier blog post for more inspiration), or get in touch. 


Previous Article
Security Announcement: Scalr Discontinues Support for SSLv3

On October 14th, a team of security researchers from Google announced a new attack on SSLv3: POODLE (CVE­ 2...

Next Article
Upgrade Bash and Address CVE-2014-6271 ("Shellshock") now with Scalr

Earlier today, it was discovered that bash (the “Bourne-again shell”) was susceptible to remote code execut...


Get the latest news and updates with the Scalr Newsletter!

Thank you!
Error - something went wrong!