Cloud Deployment: It’s All About Cloud Automation

Many organizations are facing the challenge of migrating their IT to the cloud. But not many know how to actually approach this undertaking. In my previous post I took a hands-on example of SpringSource’s PetClinic reference application with a Tomcat web server front-end and a Cassandra NoSQL database backend and showed how to onboard it to the cloud in a manageable fashion. But many think this methodology is only good for modern applications that were built with some dynamic/cloud orientation in mind. For example, how different would the cloud on-boarding process be if I modify my PetClinic example to use a MySQL relational database instead of the modern Cassandra NoSQL clustered database? In this blog post I intend to show that cloud on-boarding of brownfield applications doesn’t have to be a huge monolithic migration project with high risk. Cloud on-boarding can take the pragmatic approach and can be performed in a gradual process that both mitigates the risk and enables you to enjoy the immediate benefits of automation and easier management of your application’s operational lifecycle even before moving to the cloud.

Let’s follow the above example of MySQL: MySQL is a pre-cloud relational DB, so it has no built-in features to support cloud on-boarding, or even built-in automation. Nonetheless, Amazon built its very popular Relational Database Service (RDS) by adapting MySQL to its AWS cloud. MySQL DB was not built or designed for cloud environment, and yet it proved highly popular, and even the new SimpleDB service that Amazon built from scratch with cloud orientation in mind was unable to overthrow the RDS reign. Nati Shalom, GigaSpaces CTO, explains in his blog that the adaptation of MySQL to AWS was achieved using some pre-tuning of MySQL to the Amazon environment and extensive automation of the installation and management of the DB instances.

Automation is a key for cloud on-boarding. Experts say automated application deployment tools are a requirement when hosting an application in the cloud. Once automation is in place, and given a PaaS layer that abstracts the underlying IaaS, your application can easily be migrated to any common cloud provider with minimal effort.

Furthermore, automation has a value in its own right. The emerging agile movements such as Agile ALM (Application Lifecycle Management) and DevOp sendorse automation as a means to support the Continuous Deployment methodology and ever-increasing frequency of releases to multiple environments. Some even go beyond DevOps and as far as NoOps. Forrester analyst Mike Gualtieri states that “NoOps is the peak of DevOps”, where “DevOps Is About Collaboration; NoOps Is About Automation“.

This value of automation in providing a more robust and agile management of your application is a no-brainer and will prove useful even before migrating to the cloud. It is also much easier to test and verify the automation when staying in the well-familiar environment in which the system has been working until now. This baby-step approach will make the cloud on-boarding process more manageable and pragmatic. Once deciding to migrate to the cloud, automation will make the process much simpler and smoother.

Even within the Automation phase I advocate taking a baby-step approach and divide into steps:

1. first automate the installation and deployment
2. in next phases (could be sub-divided into a few sub-steps) to automate the post-deployment lifecycle phases (application fail-over, tear-down, admin operations, etc.)
3. and then handle application availability and performance monitoring

On my latest blog post I demonstrate this flow in practice by taking the above challenge of on-boarding the MySQL database to the cloud and following it step by step with code snippets to show how it’s done in practice. The full code is available as open source on GitHub as well so you're most welcome to have a look, play with it, and even fork the repo and contribute.

Comments

[David Mytton]

For most properly deployed servies, #1 and #3 are already achieved - the only real difference with cloud environments is the lifecycle management (point #2) which may include sudden failure and recovery or a lot faster decommissioning e.g. rebuilding an instance for upgrades rather than running the upgrades on the instance itself. In many cases these should really already been handled, it's just the potential frequency that changes.

[Dotan Horovits]

David, you are correct that properly deployed services SHOULD satisfy #1 and #3. However, many legacy applications (which are the subject of this post) are not well automated. This is in fact the driving force behind the DevOps/NoOps trend and of DevOps tools that actually come to the aid in automating application that do not offer that OOTB, such as Chef and Puppet CCM tools for deployment automation (#1), and Nagios and Hyperic for application monitoring (#3).
As I showed in my post, the DevOps automation is in fact a task on its own, with its own benefits even before moving to the cloud. I have customers whose challenge is exactly that - supporting short cycles of releases, test env automation, etc.