After posting this I got a tweet from the DevOps Jedi himself, effectively laying down the challenge to go make it happen – time has ticked by and a follow-up post is overdue, so here goes…

Configuration Management, whilst a large space to tackle out-of-the-gate so to speak, seems like a sensible place to start – it is arguably the single biggest building block you can have to underpin the running of your infrastructure. It is also perhaps the area that folks in a Microsoft-only environment most view with envy as they see the options available to their *nix brethren (at least those who are aware of what’s happening in that world, but that’s another issue!), and all without a ‘big vendor’ anywhere to be seen.

Granted there are commercial configuration management tools out there, not least from Microsoft themselves but from what I’ve seen none of them take the approach of tools like Chef and Puppet (though feel free to correct me on that, I’m no expert on them all) and of course of there is the cost factor. The cost is less of an issue for large corporates, they will far more readily loosen the purse strings to fund an enterprise rollout of XYZ, not forgetting another chunk of cash for the associated consulting required to plan, implement and train.

Don’t get me wrong, I’m a consultant so I can hardly sit here and ridicule company’s that spend out on consulting – it’s what keeps a roof over my family’s head – the point I’m making is that this approach does not work for smaller companies, and therefore is not going to make the broader world of Microsoft DevOps a better place. That’s not to say that an alternative shouldn’t necessarily be a commercial offering, just that any pricing model needs to reflect the target audience and that it shouldn’t require a huge engineering effort just to implement.

Here’s what I propose….

A toolset built on the .NET Framework that combines the configuration management principles of Chef/Puppet with the virtualised provisioning of Vagrant (perhaps with less emphasis on the distribution-related features).

I realise I risk the wrath of those communities with charges of ‘Not Invented Here’, but once you accept that there is a swathe of IT practitioners for whom the existing products in this space are simply not viable solutions (whether you agree with their reasoning for the unviability is irrelevant really), it seems clear to me that this is the only way to really tackle this ‘poverty gap’.

The more I thought about it, the more I realised that developing such a solution for a Windows audience and only a Windows audience, makes the size of the problem several orders of magnitude smaller than the Chef and Puppet projects have to deal with:

1. Fewer abstraction layers are required because all systems share the same underlying platform
2. Being able to rely on features built-in to the Windows/.NET Framework platform means that we can get some serious heavy-lifting with very little effort.

Here’s an archetypal ‘big box’ diagram to try and illustrate what I mean.

The aim here is that working with the tool should feel immediately familiar as it is using technologies that you are likely already using. If not, the benefits you will reap from getting familiar with say MSBuild will far outstrip simply understanding this tool – you will now be familiar with a fundamental tool used by your .NET developer colleagues, which can’t hurt.

• MSBuild gives us a declarative orchestration engine that will manage resolving our dependency tree of required actions on a given client, for free.
• Heavy use of PowerShell is, of course, a no brainer not only can we perform deep system administration natively but we also get the excellent remoting facility – in fact this gives us the option of not necessarily needing a client footprint (at least for some scenarios).
• Windows Workflow Foundation ought to be good enough to orchestrate multi-server runs, ensuring that dependencies between servers can be resolved allowing them to be built in the correct order. For example, let’s not try to configure a SharePoint server before the SQL Server has finished – or perhaps, let’s just not try to build a SharePoint server!

Obviously there is a lot of detail and hard work behind those boxes (and more boxes besides) even when utilising so much of the underlying platform, but this is my initial premise and I have started work on a prototype in what passes for my spare time.

I would really love to hear your thoughts on whether you believe the Microsoft eco-system needs this and your thoughts on how I’m going about it.

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

Whilst I straighten things out here, you can read past posts on my previous blog:

http://consultingblogs.emc.com/jamesdawson

Thanks for stopping by.

>jd