Readsource

I wrote about my discovery of the DevOps movement in a previous blogging life and in the intervening time I’ve been trying to keep up with some of the excellent material being produced by the Community and at the same time becoming slightly frustrated.

The bulk of my work revolves around the Microsoft platform and to put it bluntly it is very much a second class citizen in terms of the available tooling.

Now I’ve fanned the flames, let me put some context around that. I don’t mean that as a criticism, in fact I view the status quo as an entirely natural result given where the movement grew out of and, to be frank, the mindset of the typical Microsoft IT shop.  In a Microsoft environment there tends to be far greater reliance on big vendor products, whereas in the Linux/BSD world it is far more common to integrate a series of discrete tools into a complete tool chain that meets the needs for a given scenario.

The problem with the reliance on big vendor products is that it becomes almost a state of mind, where if preferred vendor’s product A doesn’t do Y then it just isn’t possible – or more insidious still, the underlying requirements become largely defined based on the capabilities of product A; rather than, say, the actual requirements!

You can draw a reasonable parallel using the Java and .NET development platforms as an example.  Java, the more mature platform, had tools and frameworks that simply didn’t exist in .NET (e.g. Maven, Hibernate, JUnit, CruiseControl, MVC web frameworks to name but a few).  Over time this inspired similar tools to be created by the .NET community, and then a vocal minority was spawned to champion the use of them (e.g. the Alt .NET movement) until eventually Microsoft starting shipping some of these things as part of the core .NET development environment.

For the remainder of this post I want to consider Configuration Management (CM) tooling in particular.

I first came across Chef about the same time as DevOps and was smitten by it, not because it was packed full with innovative concepts per se, but because here was a product that was aiming to do everything that a self-respecting infrastructure professional knows should be done.  Up until then we’d been stringing together our own partial systems on a per-case basis, or perhaps having to put up with one of the alleged CM ‘beast’ products from a big vendor if the customer was willing to stump-up the cash – above all Chef struck me as a shining example of codifying best practise.  In that regard, whilst there is clearly a lot of innovation in Chef the core principles it applies are not, they simply reflect what has become a common understanding of what works amongst those in the space.

So back to my frustration….

I have lost count of the number clients that were crying out for a Chef-like solution (even if they didn’t know it).  However, for a Microsoft-only IT shop there are barriers to entry for Chef adoption – although with OpsCode broadening their commercial offerings they are whittling them down.

Whilst Chef has a cross-platform client, the server itself must run on a Linux platform which can present significant problems for pure Microsoft shops, both in terms of approval red tape as well as longer-term technical supportability.  Of course OpsCode’s Hosted and Private offerings are designed to address those concerns and certainly, for some, they do.

However, the second barrier is more a philosophical one than technical.  Even if an organisation is willing and able to adopt or at least trial, there is still this impedance mismatch that a Windows person experiences when having to work with a tool that originated in the Linux world.

I don’t really want to get into the rights and wrongs of an organisation not being willing to step outside the Microsoft walled garden, IT teams shying away from broadening their skills or companies not willing to invest in suitable training for their IT teams.  The fact is it does happen, whether we like it or not.

That being the case should we just shrug our shoulders and say “bad luck, we told you Windoze sucks” and continue down this path where an entire subclass develops? Ironically, I would suggest that the likely members of that subclass would be precisely those who could most benefit from having access to such tools – small to medium businesses with small budgets and small IT teams whose professional lives primarily consist of fire-fighting.

I want to see the values espoused by DevOps spread far and wide, including the quietest backwaters of corporate IT, where Windows, Office and IE 6 reign supreme. To that end, the Microsoft infrastructure community needs to take a similar approach as the .NET community did and start bringing some of the goodness that we see in the Linux world to the Microsoft platform in a way that facilitates adoption for all and actually takes advantage of the platform’s innate richness and strengths.

>jd