Cloudamatic is a full spectrum deployment tool, covering provisioning, configuration, orchestration and management, well suited as the Swiss Army Knife of deployment automation. Sometimes, however, a customer is focused on an automation tool they already have in-house or a lightweight deployment solution that works independent of Cloudamatic services.
In response, we are happy to announce immediate availability for generating Amazon Web Services (AWS) CloudFormation scripts from Cloudamatic’s baskets of kittens (BOK). This new capability allows you to use Cloudamatic as an in-house tool to generate and maintain CloudFormation scripts for your projects without the need to deal with the details of CloudFormation’s complex syntax and steep learning curve.
CloudFormation is AWS’s provisioning tool. It offers a very rich way of scripting the creation of AWS resources, however, it’s not particularly well focused on configuration, orchestration, and management tasks–it mostly brings AWS resources into being. Many people find CloudFormation very challenging to work with, particularly in complex configurations, and a recent graphics front end doesn’t seem to have helped.
We recently completed an engagement with a customer to migrate a complex series of applications from Rackspace to the AWS environment. They had standardized their approach to using CloudFormation on AWS, and wanted to receive both a completed migration and a set of CloudFormation templates for their future deployments. After some analysis and consideration around Cloudamatic’s cloud-neutral plugin architecture, we decided that it made more sense to create a CloudFormation plugin to Cloudamatic than to create native CloudFormation templates by hand.
As a result, we were able to create descriptive, human readable and maintainable Cloudamatic deploy descriptors, and use them to generate the desired CloudFormation templates rapidly. We subsequently used the CloudFormation templates to deploy the application, and delivered the templates to the customer along with the completed migration. The entire effort of creating the plugin and delivering the templates cost less in time and effort than writing CloudFormation by hand.
In adding this capability, CloudFormation has become a sort of “Rosetta Stone” for deployment automation. By crafting an appropriate plugin, it’s possible to generate scripting in any other language that offers a subset of Cloudamatic’s capabilities.
You’ll find the new Cloudamatic generation capability in the mu-deploy tool of Cloudamatic. Simply:
- Craft your Cloudamatic deployment descriptor in the usual way, using Cloudamatic’s powerful but human readable deployment description capabilities
- Run the mu-deploy tool using the new CloudFormation options
The new “-c” option will run your deployment descriptor and generate a CloudFormation script for you.
The new “-l” option will allow you to specify where the CloudFormation script is written instead of the default “/tmp” location. You can also save the script to an S3 location/.
Here’s an example using our Cloudamatic WordPress demo:
- Create your Deployment Descriptor/Basket of Kittens (BOK). As noted, we’ll use the BOK from the Cloudamatic WordPress demo
- Run your mu-deploy operation using the CloudFormation “-c” option as shown below
# mu-deploy /opt/mu/lib/demo/wordpress.yaml -c -l /home/yourdirectory/wordpress.cf.json
- –c drives the CloudFormation creation option
- –l directs the CloudFormation output to a directory and file of your choice … substitute a directory of your liking
Let’s compare complexity using file length as a surrogate:
Note the difference between the original Cloudamatic deployment descriptor (4.4K) and the generated CloudFormation (82K). That’s right … the CloudFormation is 20 times longer than the deployment descriptor used to generate it. Assuming – and I believe it to be true – that we’re not introducing complexity in the generated script, that represents a dramatic savings in the time required to generate CloudFormation scripting
Next Blog – Automated Cost Calculation
Every CloudFormation generation run ends in a cost estimation phase, which invokes and configures the AWS Cost Calculator to estimate the cost of the architecture. This process eliminates much of the human error in using the cost calculator and gives a good estimate for estimating consumption-based pricing.
In our next post, we’ll talk more about the “estimated monthly cost” URL you see at the end of a deployment, creating a direct link between architecture diagrams, the BOK that implements the diagram, and a baseline cost to estimate and compare alternatives.
This “translation pattern” can be applied to generate scripts in other deployment languages, so long as the desired characteristics are in Cloudamatic’s deployment language, which they are likely to be. Use the Cloudamatic plugin as a guide to your own implementation, or watch for future implementations as they are required by our customers.