Friday, 13 May 2011

London VMUG Session

Wow, can't believe there is some new content up here? Neither can I :). In all seriousness though, I've been working something I think is pretty cool (and has nothing to do with virtualisation) which has been chewing up a lot of my time. Although it has nothing to do with virtualisation, I'm hoping it will be something a lot of you will find useful. More on that in the near future ;).

Yesterday the London VMUG team put on a full day event, with labs, different content tracks in the afternoon and even food! It was a great day, even without the usual motley crew of regulars like Alan Renouf, Mike Laverick, Tom Howarth, Stevie Chambers, Dan Eason and Simon Long. I hope everyone who attended (more than double the regular number of attendees I would guess) had a good day too.

I was lucky enough to have a spot in the afternoon, right before the great Massimo Referre. The room was pretty full, I'm guessing people wanted to get in early to see Mass as our sessions were in the same room :D. But seriously, thanks to everyone who came along - I was stoked at the turnout and hopefully I didn't fuck up the message I wanted to deliver too much.

You're always your own worst critic, and I couldn't shake the feeling after my presentation that i didn't do a good job of getting the points across that i wanted to. Or rather, they all kind of ran together and weren't as coherent as what I would've liked. So now that I've had a while to distill my thoughts, here is what I was trying to say in summary:

1) I don't care what you call it, if you're trying to build something that delivers IT in way that better meets the requirements of your business, that's awesome.

2) It's OK to be different. Build something with the least set of features to deliver business value, and iterate. Be wary of requests for things like cloning, resizing, hourly billing etc etc. My guess is when you dig deeper, 90% of the appplications you use today aren't built to really take advantage of those kind of features. If the application data and code is so tightly coupled to the OS that cloning is required... if there is no automation at the application layer to modify OS / base library / application configuration parameters like heap, cache, garbage collection, thread pools, min/max threads etc... if the application can't handle failure gracefully and can't scale out horizontally... chances are a lot of the buzzowrd-y IaaS features aren't actually relevant. I guess in a nutshell, understand the problem. And even if your apps can do this, can your backend infrastructure services and processes deal with it? You may find a new way to spell clusterfuck, in 4 letters - I T I L. And Stevie, this image is for you:

3) While not wanting to contradict points 1 and 2, not every application problem is best addressed at the infrastructure layer. Things like long distance vmotion, cloud bursting etc etc are not things you should focus on in isolation of decoupling the application layer from the rest of the stack. Yes there are many applications deployed in the Enterprise today where it's not really possible to provide clean separation, but is it worth adding such expense and complexity to the infrastructure layer to give a minor increase in functionality to such apps? IMHO, no. Reward the applications who can operate in a more cloud like fashion with more options and functionality. Leave the ones who can't in the state they are today (ie just plain ol' virtualised).

4) Finally, there are things infrastructure people can learn from the application world, and I strongly believe than these new skills will be critical for anyone performing an infrastructure function in the future. The DevOps movement pretty much encompasses this new way of thinking about and managing infrastructure.

Here are some of the resources that I think you'll find useful in starting the journey. If you think it's all rubbish, that's fine - but I really encourage you to at least have an awareness of what else is out there if you don't already. If nothing else, it will put you in a much better position to argue with someone like me about why you think it's all rubbish :)

1. The ChangeLog Show - Episode 0.3.8 - DevOps and Chef with Corey Donohoe from GitHub and Seth Chisamore from Opscode

2. Facebook Engineering - Doing it live: operations and extreme scaling tech talk

3. Qcon London 2011 - Agile Operations – Optimizing the Business One Shell Script at a Time

4. Check out some of the people on Twitter who regularly use the #devops hashtag, and follow them - if you don't find value in what they have to say, just unfollow!

5. Read up on tools like git, chef, puppet, cfengine, and any other tools out there in the infrastructure configuration management / automation space.

6. Most of these tools have a Linux focus and use languages that may not be common on Windows based platforms. The concepts are more important than the tools and languages, so don't get too hung up on that if *nix isn't your thing.

If you're reading this and have any suggestions of your own, please leave them in the comments or ping me on twitter. Oh and here's my slide deck from the session, although it's probably not too useful on it's own. I'll probably do a few posts in the future explaining things a little better, and I'm also making an appearance on an upcoming podcast where we'll probably talk about it too.

No comments: