Anyone who wants to use a public IaaS provider like Amazon Web Services needs to use machine images. Let's delve into the confusion about how to best use those images.
Several months ago, I said that Netflix's push to drive the adoption of its open-source cloud-management toolkit, NetflixOSS, had the potential to "ruin cloud computing."
Part of my argument revolved around the Netflix Aminator tool, which facilitates the creation of Amazon Machine Images (AMIs). While Aminator may be a good choice for Netflix, I argued that it encourages exactly the wrong habits for the majority of companies trying to deploy applications in the cloud. After many long discussions about that initial article, I believe there is still significant confusion about how one should best use AMIs (or the equivalent from other public cloud providers), and so I am dedicating this column to what I call "the baking debate."
Let's start with some background: Anyone who wants to use a public infrastructure-as-a-service (IaaS) provider like Amazon Web Services (AWS) needs to use machine images. These machine images are what they sound like -- an image of a virtual server that you can launch, and once it is active (within minutes), it's your server to use as you wish. The machine image has, at a minimum, an operating system on it, but it can have as much other stuff as you want to cram in. Most IaaS providers make it easy to launch one machine image, make changes to the image (like installing and configuring software), and then "save" the resulting machine as a new image. The "baking debate" revolves around how you should use machine images. Essentially, wrong choices will bite you down the road.
There are three positions in this debate: the "bootstrappers," who focus on being able to orchestrate the creation and management of servers throughout their lifecycles; the "bakers," who focus on building machine images for speed and consistency; and the "babes in the woods," usually developers who've found that building machine images is a quick-and-dirty way to construct backups of servers that can then be cloned and replicated.
Bootstrappers like to use a small number of machine images -- core, base operating system images that are fairly easy to establish across multiple IaaS providers. Then, after launching the base image, they run configuration management/orchestration software (like Puppet or Chef) to instantiate the full server environment -- installing and configuring software, setting up connections to other servers, even restoring data from a backup and setting up replication between database servers.
Then, the same orchestration software can be used to modify already-running instances; for example, by rolling out software updates (take a server out of the load balancer, update code/software/configuration, run the test suite and, if it passes, add it back to the load balancer).
In the view of the Bootstrapper, every instance is flexible and dynamic, and machine images are often taken directly from experts (read: the IaaS provider).
Bakers like to make their own machine images so they don't have to deal with installs or configuration after launch. Configuration management is part of the image-baking process. Running instances are perfect copies of machine images; whenever bakers need to make changes to those instances, they make new machine images, launch new instances and kill off the instances running the old image.
Babes in the woods are on a different planet entirely. They don't read much documentation, preferring to jump headfirst into the cloud without understanding exactly what configuration management is or how it works. They pick a machine image at random, start manually installing and configuring software and loading data onto it, and discover that baking images seems like a good way to back up their servers. This works well -- until they need to install a brand new version of a core piece of software or the underlying operating system, or relaunch an entire deployment with data spread across multiple resources ... you get the idea. At that point, the poor babes find themselves having to reinvent the wheel, usually without the luxury of having saved any documentation. They may find some solace in thinking themselves bakers. They're wrong.
So, accepting that, the question is this: Is it better for most cloud deployments to be bootstrapped or baked?
Multicloud Infrastructure & Application ManagementEnterprise cloud adoption has evolved to the point where hybrid public/private cloud designs and use of multiple providers is common. Who among us has mastered provisioning resources in different clouds; allocating the right resources to each application; assigning applications to the "best" cloud provider based on performance or reliability requirements.