Snowflakes in July?

Posted on 5 mins read

Unless you live in a very specific part of the world - the chance that you will see snow (I mean the real fluffy stuff - not the artificial muck that people make) is really, really slim. But many of deal with snowflakes each and every single day - and we do not even know it.

So where are all these snowflakes? (in July??)

They don’t see each other. They only see what they want to see. They don’t know they’re dead snowflakes. How often do you see them? All the time. They’re everywhere. (I love this quote)

So before I start I suggest that you read this excellent post by @Martinfowler - SnowflakeServer …

… Great!! You are back.

Our datacenter is full of snowflakes. These snowflakes are our own doing. At least this was the case a few year a go when there were manual build processes. Enterprises realized quite soon that this was not a healthy situation and looked for a way to standardize builds.

snowflake

First we started with Norton Ghost images. Then came kickstart scripts for the Linux Servers, and RIS (and thereafter Windows Deployment Services) for the Windows boxes.

There was fiddling with drivers each time a new hardware model came out, a new NIC was introduced, a new HBA etc. etc.. it was a challenge none the less but a pretty automated process.

But for most (I can definitely speak for myself) once the OS was delivered - the application was usually not part of the build. Patches were installed up to a certain point - but then again, there was an build process for IBM hardware one for HP and another for Vendor X/Y/Z.

So yes we have a multitude of servers which are - yes you guessed it - snowflakes. It will be difficult to say that your servers are the same, they are built the same and they will never stay the same. I am not saying that they all should be - but it slowly but surely becomes a nightmare.

But hey… Wait !!! Virtualization solved this for me didn’t it? I mean that was the whole idea of having templates wasn’t it? A golden image that was the central point of deployment, had to be updated only in one location and from there on in - all VM’s would be deployed exactly the same. Well yes - in a way this is true. This changed the snowflakes to some kind of a rubber stamp - exact copies, standardization and hardly any variation.

A couple of months back I was as DevopsCon in Israel and there I was enlightened to the fact that people used Puppet / Chef / Tool X/Y/Z for automated builds - a large part of them was for Continuous Integration or Continuous Development. And there something struck me.

Using an automated build system gave you the exact same OS each and every time.

But.. (and it is a big BUT) - this was only valid for your own environment.

Picture the following scenario. You need to deploy a system that is comprised of:

  1. Bare metal OS (heaven forbid)
  2. VMware VM’s - on your environment
  3. vCloud VM’s - either on your private cloud - or a Public one
  4. AWS VM’s.

This is not a crazy scenario - complicated yes but quite viable.

Now let’s examine how you would get the same OS down on to each of the above:

  1. Automated build - using Puppet / Chef / …
  2. Deploy from template - which could possibly have been built with one of the above tools - but I doubt it.
  3. Could be the same template that you have used in-house - but still deployed from a template.
  4. Deployed from a AWS image - or also perhaps also a template that was imported - again I find that not really to be the case.

Here we have at least 3 - and perhaps 4 different ways of getting the same OS down to the different locations and platforms

Now we want to customize the OS’s just say Hostname and IP address:

  1. Customize with Orchestration tools (Puppet/Chef)
  2. Use VMware Guest customization
  3. Use vCloud Guest Customization
  4. Customize with your Orchestration tools.

If you are lucky - you can use two methods. If not perhaps 4. If you plan very well - and use the same method for all 4 - then you are in really good shape - but I assume that most of us are nowhere near that stage today.

snowflakes - a lot of them

Snowflakes… for OS deployment, Snowflakes for configuration, Snowflakes.. Snowflakes.

Enough of what we do not have, and now it’s time to talk about how I would like things to be in the future (and I think you should too).

All your Operating systems should be deployed exactly the same way, configured exactly the same way and managed (yep)… exactly the same way.

  • does not matter if they are physical or virtual
  • does not matter if they are VM’s on your vSphere environment or on a vCloud environment
  • does not matter if they are on a VMware public or private cloud, AWS or an Openstack based cloud.

I do not want to have to manage 4 different kinds of deployments one for each environment. I would like to to have one build process that should be able to produce the exact same Operating system (and yes I know there will be differences depending on the hardware or underlying virtual hardware) but the process will be the same. Having four different kinds of snowflake families is better than having hundreds of snowflakes - but still not ideal.

The same Puppet module. The same Chef Recipe. The same automated build..

Are we there yet, no. Will we ever get there - I do not know - perhaps never.

One thing that immediately comes to mind. Since Puppet is now partnered with VMware and are developing a number of projects specifically catered to VMware’s needs (or so I hear) - one thing that VMware could do, is allow for the deployment and customization of VMware VM’s with Puppet instead of using the guest customization API’s. All of course integrated into vSphere.

Just a thought.

Please feel free to share your thoughts and comments below.