This evening I attended a dev ops meetup in Manchester. Why? Well interesting story, but primarily because:
- I was in Manchester anyway
- Tom was presenting his Nasa stuff
- I’m working on a project with heavy dev ops requirements, so I dragged some of the geeks down with me!
So how did it work? Well they are lucky, they seem to have some great sponsors, and the venue was brilliant.
First up was Tom, showing off what they get up to catching organised criminals at NASA. (UK Police interested in the memex programme) Not just that but there’s a huge genomics project too. They are trying to improve overall standards, and for them it’s vital they can test and deploy in different envs around the world seamlessly.
(He sadly pointed out that not being a US citizen means he’s not allowed near any cool space tech!)
There’s this I/O based monster with 3k cores called wrangler too – and they have very little privileges, so it’s all ansible based here.
Good points about pro/cons of containers… (Issues with patching etc). And of course, a quick mandatory demo of juju. One key thing about juju that I hadn’t appreciated was you can save your “project” as a bundle and then do a one line install of that bundle. How cool is that!
Next up was Matt Skelton – Slides here. This was all about designing teams for software development, with a view on how devops fits in.
He talked about business agility – and how quite a lot of people have never experienced working in a high performant team. I agree with this – once you’ve experienced it, it’s quite a thing, and you don’t want to go back!
There are some fundmental rules, teams work best in 6-9 people, and a lot of this stuff is only applicable in a large enterprise environment. Most importantly is that the team must be stable (albeit slowly changing) and no gathered, and thrown away for every project (which is a model i’ve seen previously).
Anyway another key point is this:
- Organisation architecture always wins out
What does this mean? It’s been shown that the software architecture always ends up mirroring the organisation setup. Thats crazy! But when you think about it, we’ve all seen it right? so fix the TEAM FIRST before doing your software architecture.
Finally he finished with a point that generated much discussion about cognitive load. Essentially you need to ensure the team is not overloaded. This can be best achieved by simply asking them if they’re confident to manage the running of their current project(s). (e.g. think, do they have sufficient knowledge and time to deal with a P1 incident?) . This is all because stress impacts the ability for a team to be performant. It seems to me this is very close to “velocity”. Discussion ongoing there!
Other comments – well I think the comment about google being way above everyone else on the tech front was a bit misleading, it’s not all roses over there..
Finally, there was some talk of “the cost of collaboration”.
Many thanks to the organisers who did a great job, and the sponsors of course! A genuinely interesting group with a good vibe going on (barring the mandatory dissing of London – Qudos to the guy brave enough to mention that they also host meetups there!)
Codeks Blog 