Skip to content

Instantly share code, notes, and snippets.

@rememberlenny
Forked from mitchellh/post.md
Created February 5, 2022 03:26
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save rememberlenny/9048bbe6e703f40861715facd1583eb5 to your computer and use it in GitHub Desktop.
Save rememberlenny/9048bbe6e703f40861715facd1583eb5 to your computer and use it in GitHub Desktop.
Originally posted on Tumblr on Feb 25, 2011.

THIS WAS ORIGINALLY POSTED ON MY TUMBLR ON FEB 25, 2011. I forgot I had a Tumblr account. I recently logged in (in light of the acquisition by Automattic), found some old posts, and I'm republishing them exactly as they were with zero modifications.


CloudFormation: The Big Picture

Amazon announced CloudFormation to the public yesterday, and while the general opinion I could glean from various sources shows that people are excited about this new technology, many are still unsure what it is and how it fits into their current cloud workflow. I feel as though I have a firm grasp on CloudFormation and will attempt to answer some questions here.

Note: I'm definitely not a representative of Amazon in any way, and anything here is simply my educated opinion on the matter.

[[MORE]]

What is it?

CloudFormation is best described as an infrastructure provisioning tool based on a declarative language (expressed in JSON, in this case). CloudFormation takes the declarative file (a "template") and uses it to orchestrate the creation of various cloud services and hook them up together (resulting in a "stack").

The difference between this and Chef or Puppet, is that Chef and Puppet are configuration management tools and work best with installing and configuring software on new nodes. Some people have used configuration management for launching virtual machines and servers and so on, but this is an exception, and not the norm.

Chef and Puppet are complementary tools to CloudFormation. CloudFormation starts the server orchestration act and configuration management tools complete it.

Where does it fit in my current workflow?

It doesn't, yet. CloudFormation is really great at describing the infrastructure of a single application, service, or cluster, and bringing up the entire infrastructure as one atomic operation. However, CloudFormation doesn't yet provide any way to incrementally improve and re-provision infrastructure, which is most of the battle when doing any Ops work. There are some hints from Amazon that they are thinking about this for the future.

However, if you're looking to bring up a new service or application, CloudFormation is far superior to writing manual launch scripts. This is very nice.

So, does CloudFormation matter at all?

Yes! Infrastructure provisioning is a space which is currently lacking a mainstream tool. CloudFormation is a good step in that direction, and therefore everyone should learn about it, but it is not the end-all-be-all. Certainly if you use AWS exclusively you should pay close attention, since I'm sure its innovation in the future will be important and useful.

However, we need an open source, cloud-agnostic solution to this problem. Libraries such as Fog, Boto, libcloud, etc. are not the answer. These libraries are just that... libraries to cloud APIs.

Ideally, we would have a declarative language to define infrastructure (incrementally, as well), and tools to consume this language and use the various libraries noted previously to spin up cloud infrastructure, perhaps even across different cloud providers.

CloudFormation is a brilliant move by AWS and is a technology worth watching, but at this stage its uses are limited, and it leaves space open for an open source alternative, which I hope will come about.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment