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 recent post – Cloud Deployment: The True Story – I started sketching best practices for performing the cloud on-boarding task 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, such as Cassandra NoSQL DB from my previous blog, and that existing legacy application stacks cannot use the same pattern. For example, how different would the cloud on-boarding process be if I modify the PetClinic example application from my previous post to use a MySQL relational database instead of the modern Cassandra NoSQL clustered database? In this blog post I intend to demonstrate that cloud on-boarding of brownfield applications doesn’t have to be a huge monolithic migration project…
We are issuing a challenge to the Open Source community. The challenge is called the “Recipe of the Month Challenge”.
Documentation on what application(s) the recipe deploys and how to use it. This also includes what is the purpose of the application(s). (Documentation should be easy to follow and straight-forward. This will help with the judging and testing of the recipe)
Any scripting language/configuration management software can be used. Some examples are as follows:
The following categories will be used for judging [scale from 1 (lowest) to 10 (highest):
Complexity (the more simple and elegant, the better)
Failure resiliency (how quickly can the solution return to a healthy operational state after an outage)
Available swag awards:
Eucalyptus Hoodie (color available – dark grey)
Eucalyptus Electric Cloud Shirt (colors available – black or white)
Eucalyptus Contributor’s Coffee Mug
Various Eucalyptus stickers
The winning recipe will be made available on the Eucalyptus Recipes Github repository. Submissions will be accepted at the beginning of each month. All submissions must be made to the Recipes mailing list. The last day allowed for submissions will be the 25th of the month (this allows us time to test out each recipe and grade accordingly). Feel free to use the Eucalyptus Community Cloud as a testbed for your cloud recipe. Results announcing the winner will be posted to the Recipes, Images, and Eucalyptus Open Community mailing lists (for more information concerning the mailing lists, please visit the Eucalyptus Mailing Lists page).
Look forward to seeing the recipes. Remember, its all about creativity, deployment speed, and failure resiliency. Please send all questions, suggestions, additional ideas to the Recipes Mailing list.
Late binding is a programming term that I’ve commandeered for Crowbar’s DevOps design objectives.
We believe that late binding is a best practice for CloudOps.
Understanding this concept is turning out to be an important but confusing differentiation for Crowbar. We’ve effectively inverted the typical deploy pattern of building up a cloud from bare metal; instead, Crowbar allows you to build a cloud from the top down. The difference is critical – we delay hardware decisions until we have the information needed to do the correct configuration.
If Late Binding is still confusing, the concept is really very simple: “we hold off all work until you’ve decided how you want to setup your cloud.”
Late binding arose from our design objectives. We started the project with a few critical operational design objectives:
Treat the nodes and application layers as an interconnected system
Chef is a tool used for configuration management of bare metal and virtual systems. Chef has a client/server model as well as a standalone tool that is very similar to the tools from Puppet Labs. (Want to automate a puppet agent installation? Check out my earlier blog post
When using the cloud and launching multiple instances with the same job, configuration management is a huge time saver. Configuration management systems will allow you to build the configuration once and use it to create exact replicas on as many instances as you need. Having the exact same configuration for every system doing the same job keeps errors and possible issues down to a minimum. Also, if your production systems are easily replicated, you can spin up smaller test environments to check your systems before pushing out the newer code to production (possibly even using Amazon for production and Eucalyptus internally…