Readsource

In my first proper post here I talked about how despite the plethora of DevOps-oriented tools out there, the sysadmin in a pure Microsoft shop was more than likely at a serious disadvantage when it came to either using those tools or trying to find similar tools that specifically targeted the Microsoft platform.

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.