Jonathan Noble is a PowerShell Microsoft MVP with additional interests in Windows Phone Consumer, Office365 and Forefront Identity Manager. Jonathan has been a full-time IT Pro for over a dozen years and since 1999 he's been working in the IT department at Newcastle University. On the 12th of November, join Jonathan who will be speaking on the topic of 'Building a Desired State Configuration Infrastructure' at Future Decoded which is a free event which will see keynotes from Brian Cox, Sir Nigel Shadbolt, Or Arbel and Michael Taylor, followed by eight individual speaker tracks that discuss different topics. Be sure to register before the day is sold out, and we hope to see you there!
I'm very happy to be presenting at the Future Decoded Tech Day on 12th November at the ExCeL in London. The thing that I find most exciting about it is that my session on "Building a Desired State Configuration Infrastructure" is part of the DevOps track, and that's because I believe the DevOps approach is really important for all of us to embrace going forward. It's unfair of me to make that claim without a bit of explanation, so let me try to quickly start down the track towards convincing you…
In most IT organisations, whether they're the whole company or just a department within a bigger organisation, there tends to be a situation where IT operations and development teams are not totally aligning to work on common goals, even if they aren't completely at odds with each other (which is sometimes the case). Among other things, this leads to the situations where sys admins are thinking that the developers are writing bad code, and the devs are thinking that their code works fine on their machine and the IT operations people are hopeless for not being able to get it running in production. They have silos where systems (whether that's applications or infrastructure) are developed in isolation from each other and then have to be integrated down the line, when it might be harder to change things.
The DevOps approach includes the whole product/service lifecycle, with greater collaboration between those previously isolated teams. This drives enhancements in efficiency, and enables faster release cycles because features can be added and tested more reliably. You don't have to be aiming for 10 releases a day like some organisations - that doesn't suit all situations, but I doubt many people would think the option of greater agility would be a bad thing. All this requires something of a culture change, which does need a degree of buy-in across the IT organisation, but it also hinges on automation. There's no chance of doing continuous delivery without consistency, and your chance of maintaining consistency is very limited without embracing automation; especially if you need to scale rapidly.
While you may or may not be great at scripting at this point, using sets of imperative commands to put your infrastructure into the required state may only work for a snapshot in time. You run your configuration scripts and everything works fine for some minutes/hours/days/months, but the fact that you put a system in a particular state once upon a time is not going to help you if something or someone comes along and changes that. That is why it is so important to use a declarative system to configure your infrastructure, so that it's self-repairing across all the dev/QA/production layers.
For Windows Server and a whole lot of other components, PowerShell Desired State Configuration is a great approach to declarative configuration management, whether you like to keep your infrastructure in-house, or if you're moving part way, or all the way, into the Azure cloud. You're going to use it to tell the systems not just the way you want them to be, but the way you want them to stay (until you tell them otherwise). You don't need to be a PowerShell guru to get started, as my presentation will highlight (although you should keep working towards that PowerShell guru badge because it's going to pay off in spades!).
Using DSC, you can make use of push or pull deployment methods to get your configurations to the nodes you want to manage. There are pro's and con's to either approach, but I expect most people will want to aim for setting up a pull server and having the nodes poll it for updated configs. Given that the pull server is going to be a key part of your infrastructure, you want to make sure that it's properly configured, so what's the best way to do that? With DSC, of course! The DSC Resource Kit offers resources to configure this and a load of other things that aren't offered in the box, including some unexpected options like installing Chrome.
You don't have to be going all the way DevOps to gain advantages from managing your infrastructure with DSC, but if you've already implemented a DSC infrastructure, when the rest of your organisation catches up with the need to adopt DevOps practices, you'll already be ahead of the game.
Will you be attending the Future Decoded Tech Day? Who are you most looking forward to seeing? Let us know in the comments section below or via @TechNetUK.