Lessons from Amazon RDS on Bringing Existing Apps to the Cloud

Its a common believe that Cloud is good for green field apps. There are many reasons for this, in particular the fact that the cloud forces a different kind of thinking on how to run apps. Native cloud apps were designed to scale elastically, they were designed with complete automation in mind, and so forth. Most of the existing apps (a.k.a brown field apps) were written in a pre-cloud world and therefore don't support these attributes. Adding support for these attributes could carry a significant investment. In some cases, this investment could be so big that it would make more sense to go through a complete re-write. 

In this post I want to challenge this common belief. Over the past few years I have found that many stateful applications running on the cloud don't support all those attributes, elasticity in particular. One of the better-known examples of this is MySQL and its Amazon cloud offering, RDS, which I'll use throughout this post to illustrate my point. 

Amazon RDS as an example for migrating a brown-field applications

MySQL was written in a pre-cloud world and therefore fits into the definition of a brown-field app. As with many brown-field apps, it wasn't  designed to be elastic or to scale out, and yet it is one of the more common and popular services on the cloud. To me, this means that there are probably other attributes that matter even more when we consider our choice of application in the cloud. Amazon RDS is the cloud-enabled version of MySQL. It can serve as a good example to find what those other attributes could be.

The Amazon RDS Approach for Cloud Enablement of MySQL

Amazon's approach for cloud enablement of MySQL includes the followings elements:

1. Pre-tuned MySQL -- A pre-configured version of MySQL that was tuned to run well on the AWS instances.
2. Automation -- Automate the installation, deployment of MySQL database.
3. Automate a scale-up/process.
4. Automate the high availability configuration

What Can We Learn from the RDS Experience?

There are couple of lessons that we can learn from this Amazon RDS experience:

1. There is value in migrating existing applications to the cloud. Or in other words, the cloud shouldn't be considered only for green field applications.
2. Automation of the installation and deployment processes is the "low hanging fruit" for migrating application to the cloud.  
3. Elasticity -- quite often when we think of elasticity we think of scaling out, i.e. -- adding more capacity by launching more machines. As MySQL wasn't designed for this model, the RDS approach to elasticity was to automate the move from small to a bigger machine. Apparently this model had proven to be useful even if it involves downtime and is limited to scale-up.
4. Baby steps approach: When Amazon first released RDS it only included basic automation and it was only somewhere down the road htat it kept enhancing the service with more automation. This baby steps approach was a key to speed up the migration process of MySQL.

RDS vs SimpleDB

When AWS was first introduced it started with SimpleDB as its cloud database service. SimpleDB fits into the "green field" application approach to cloud. The approach with SimpleDB was to trade features and functionality for simplicity, elasticity and scalability. The popularity of RDS over SimpleDB is another interesting lesson -- trading features for scalability is definitely a simpler approach to get things running on the cloud. However, there is a considerable number of users and applications that would prefer to trade some degree of scalability for features. This also teaches us that the "green field" approach isn't necessarily the right approach. Migrating existing services has lots of value, especially if they are already in wide use.

Applying These Lessons to Existing Applications

The main take away for migrating your existing app to the cloud can be summed up as follows:

1. Use the baby steps approach
2. Start with simple automation and monitoring of the installation and deployment process
3. Add automation of post-deployment processes such as fail-over and scaling as a secondary step
4. Use a pragmatic approach to elasticity. There are areas of your app where the simplest way to apply elasticity would be simple automation of the move from a small to a bigger machine, often the stateful part of your application. There are other areas of your application, such as the web-tier, where using full elasticity can be done by spawning new instances and automating the discovery and configuration for how these instances group together, as in the case of a web tier.

DevOps & PaaS Can Be a Great Tool to Implement These Steps

There are many ways we could implement the baby steps approach, especially if we look at it as a one-time operation. If we need to move more than one application, we can easily find ourselves repeating the same effort over and over again for each application. DevOps tools such as Chef provide a good generic tool for scripting your installation and configuration processes. New open PaaS  platforms, such as CloudFoundry, Cloudify, and OpenShift address the entire application deployment life cycle, including the automation of scaling, fail-over and monitoring. An integration between DevOps and PaaS, such as the integration between Cloudify and Chef,is even better-suited tothis challenge, as it gives you the best of both worlds. 

Final Words

According to a recent HP Survey with 940 IT responders, a majority of businesses are planning to move their mission-critical apps to the cloud over the next two to five years. A recent survey by Cisco of 1300 responders shows that today only 5 percent of the responders are able to migrate meaningful parts of their application to the cloud. According to this survey, what makes migration to the cloud even more difficult is the lack of information about the process.

Many new cloud users are lost in a sea of hype-driven desire to move to cloud computing, without many proven best practices and metrics.

I believe that the lessons from Amazon RDS could serve as a good reference on what that process could be. If you are considering moving more than one application into the cloud, you should consider the use of DevOps & PaaS as the means to deliver those steps.

References:

• Cloud On-Boarding: The True Story
• Companies nearing mission critical apps in the cloud
• Cisco Global Cloud Networking Survey
• This just in: Cloud computing is hard and takes a long time
• Cloudify and Chef integration