We joined this conference last week at the Tower Bridge Hilton, London. It was excellent.
For us, the talks from Jonny Woolridge (@jmwpro, pictured), once of M&S and currently at The Cambridge Satchel Company, and Jonathan Fletcher (@fletcherjofanon), of Hiscox, caught the eye. Panel appearances from Grant Smith (@grjsmith), author of Next Gen Ops: Creating the DevOps organisation and Bert Logan (@2p3rf3ct), of QMetric, were excellent too.
For us, DevOps is a way of looking at the process of code development and integrating that thought with the infrastructure that will underpin the code, when that code is in production. It has been called a movement (for us, it just isn’t that) and it’s been called a philosophy (that it is, in our view). Either way, DevOps is about pulling together the process and people involved in development, with the people and infrastructure responsible for maintaining the systems that the software runs on.
We get DevOps. The efficiencies in delivering code teased out from that way of thinking are unambiguous. One of the speakers talked about bringing a release schedule down from 1 per fortnight to 150 per week. Serious improvement, by any KPI. We’ve seen our own clients make properly superb gains from bringing DevOps thinking to their own delivery.
In fact, a DevOps approach is possibly the only realistic option available to some businesses and their development teams. In some markets, the speed-to-release of features is worth dollops of market share at a time. So DevOps is often critical competitive advantage.
Even where DevOps philosophy is an option rather a must, it’s influence on developing and releasing code is such that the days of writing a bunch of code and then throwing it over to an Ops to team to make it work are gone.
From our vantage point, we see something of a paradox. Of course, everyone is a winner in the move towards DevOps. But it strikes us that 'if one side of the house is to be a winner’', it is the dev side of the house. They can now do lots of what Ops teams did once upon a time. For example - app performance, system monitoring, system environment architecting, messaging and logging analysis etc etc. When looked at in purely legacy terms, in the world of DevOps progress, Devs don't need Ops as much as they once did.
But yet we’re struck by how often the thought towards Devops is actually being led by Ops people, who often have most ’to lose’ from the closing of the middle ground that DevOps seeks to close. Perhaps oddly we’ve seen more cases than expected where the Dev teams on the client side just don’t seem to want to grab the middle ground that DevOps is all about closing. Even where the door is ‘wide open’ for them to do so, so to speak.
Is that a lifestyle thing? Is it a cultural thing? Is it an awareness that the Ops bit of DevOps isn’t necessarily something that developers actually want? Or is it that Ops guys can more keenly see the benefits in what the DevOps philosophy can mean in the production environment? Perhaps Ops guys can more quickly see the benefits of DevOps philosophy as that clichéd ‘uninterrupted nights sleep’. That explanation seems too simple to us. But whatever the explanation for it, it’s a trend we see in the industry.
It is often said that compliance and auditability is where the idea of DevOps can fall down, particularly in the Enterprise. Justin Arbuckle from Chef made an impassioned and persuasive plea to the contrary at the DevOps summit. But yet the separation of roles and reviews is a key part of compliance and audit. We don’t feel that DevOps has fully tackled that question. Or maybe we haven’t yet understood how it has been tackled. But if we’re asking, then others are too.
We think DevOps is only really getting going. ‘Younger’ businesses in gaming and apps for example practice DevOps from the day they are founded. The tech lead likely sets up an environment in AWS or Azure or with a niche cloud provider like Tibus. The idea of separating out roles for monitoring and for system architecting probably won’t even occur to those guys. As those businesses grow, the roles might get more specialised, but the philosophy underpinning their workflows probably wont change. DevOps will be a part of what they do, possibly without ever really knowing what DevOps was in the first place.
From a business perspective, the DevOps philosophy gains will become increasingly un-ignorable. The challenges in audit and compliance will be addressed.
From a hosters perspective, we’ll need to change. If Puppet or Chef or Jenkins or whatever is both the starting point and the journey, the end point (live Internet facing servers) must accommodate that. We can see resistance to that from some hosting teams out there: the maddening old cliched response “the servers are fine, tell them to fix their code”. We are involuntarily digging nails into palms of hands, just typing that kind of phrase on to a screen. That kind of rubbish needs to be treated with total disdain. Those days are now over.
Hosters will need to make sure the movement of code from ‘left to right’ (sandbox->dev->UAT->staging->live) is a living process and that we can fully and intuitively support that. That kind of rich support only comes from proper understanding of 'the stuff to the left'. It might be uncomfortable to some, but we as hosters need to embrace that - body mind and soul.
From our own perspective, we will make sure that we’re much closer and much more valuable to the guys that practice DevOps. A bona fide extension of their team, to use that horrible naff phrase. That will mean more customised environments. More hooks and APIs. More availability of metrics and data from the production server frontline. More involvement with DevOps teams.
The days of being ‘just a host’ are gone.
