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.
The Case For Bakers
Bakers have two main advantages over bootstrappers: launch speed and consistency. If you bake your fully configured servers into machine images, as soon as the image is launched your server is operational. On the other hand, if you have to run configuration management on a basic/core operating system and you have to install and configure software and load data on every server launch, server launches will take longer.
Second, when your configuration is baked, if the server successfully launches it will be exactly the server you want. If you're using configuration management on boot, each individual server has to execute a number of steps to reach an operational state, and those steps often involve having to download files from remote servers that may not be responding. So baking images makes sense when you're launching a ton of the same type of instance; in other words, exactly what Netflix does.
The Case For Bootstrappers
Bootstrappers have three main advantages over bakers: Significantly less complexity, an easier path to multicloud deployments and better cloud architectures, and more "orchestrate-able" servers.
However, managing images is not a trivial task. NetflixOSS tools make it easier, but adding a layer of infrastructure that has to be maintained and validated means adding complexity. What happens if your images don't get baked properly? What happens if they get deleted? Every time you need to run your test suite, you need to bake images and launch and test instances for every image you bake. And if you're image-reliant, then multicloud is going to be an even bigger pain than it already is; you now need to bake images for every cloud (and what happens if you can't get an image to bake for a particular cloud?)
Perhaps the biggest advantage bootstrappers have over bakers is that bootstrappers don't have to treat instances as disposable. The baker philosophy is that it's easier to have an army of replicas than to worry about the fact that instances could be different, but that makes sense only when one actually has an army of replicas.
In my experience, most cloud deployments have a variety of different types of instances as opposed to many replicas of one type -- and the most common operation that is done on these servers is not bursting to many additional instances, but rather updating code/software/configuration on a number of different servers. And in these cases, the bootstrappers have the upper hand, because making updates to servers in a properly bootstrapped deployment means running an update scenario across servers (which is often just a single click) as opposed to having to bake new images for each server type, kill off all of your old servers, and launch new ones.
One of the reasons I see NetflixOSS as inappropriate for most cloud users is because it is fundamentally a toolkit for bakers, not bootstrappers. NetflixOSS has the machine image at its core, and ultimately requires bootstrappers to become bakers if they want to use it properly.
For Netflix, it makes zero sense to bootstrap; the advantages of baking are critical to Netflix's success on the cloud. And the babes too often see themselves as being bakers, when they're really just doing things wrong. I think we'll see better cloud architectures if we default to bootstrapping -- and avoid NetflixOSS unless we have a compelling use case for it.
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.
. We've got a management crisis right now, and we've also got an engagement crisis. Could the two be linked? Tune in for the next installment of IT Life Radio, Wednesday May 20th at 3PM ET to find out.