When we talk about the future of DevOps and the direction technology in general is moving, we tend to focus on the bleeding edge. New technologies, management techniques or deployment strategies that seem to spring from nowhere. But often these ideas don’t gain traction or are superseded by the next big idea, swamped just before they can make a real impact. In the DevOps space it is particularly difficult to see where things are heading. The world of infrastructure as code is rapidly being devoured by serverless, which is moving to fill the workspace currently filled by container technologies.
Some technical leaders look for signs that an idea is building momentum, trying to get a head start to position themselves and their organisations to take advantage of the up and coming technical landscape. In this instance though, I’ve flipped this approach and have looked back at my own DevOps journey and key signposts I’ve seen, and some that I later realised I’d missed, to gain insight into the direction we are travelling in the future of DevOps and the landscape.
Best DevOps practices for 2019
I’ve always been a proponent of the “DevOps as a culture not a role” argument, despite having DevOps somewhere in my job title for many years. What I’ve seen on a number of client sites is that the DevOps journey is really a continuation from role to culture. On one end of the spectrum we have a DevOps engineer working as part of a development team. On the other, a self-contained development team able to fully support themselves through the development lifecycle, with DevOps culture ingrained in the way they work.
DevOps is more than a name change for System Administrators with a few extra tools thrown in
Organisations seem to consistently start with DevOps as a job role. DevOps engineers working within or next to development teams. Over time, and often triggered by a step change in technology such as a migration to Virtual Machines or Containers, DevOps as a job role shifts as developers are able to take greater control. Meaning DevOps as a culture comes to the fore.
When DevOps arrives at an organisation it can quickly take on much of the operational responsibility, from building infrastructure, monitoring, automation, which until then is part of the Operations world. Over time, and with a combination of cloud and container technologies, we’ve seen the traditional operational responsibilities open up to both DevOps and developers. We also see the rise of operations tasks such as monitoring or logging becoming available as SaaS solutions with DevOps engineers empowering development teams to take yet more of these functions upon themselves.
Demand for DevOps skills soars as organisations’ spending on digital transformation projects increase, says Akamai
Professionals with DevOps skills can earn on average 24% more than those with similar expertise
One of the first phases in this shift of operational responsibilities is for DevOps to operate more like development teams. Back in 2013 I attended a DevOpsDays in London when I overheard the following comment:
“There is no place for a DevOps who can’t code”
– Overheard at DevOpsDays London 2013
Okay, a bit a harsh, but it is hard to deny the simple truth of it. DevOps is more than a name change for System Administrators with a few extra tools thrown in. If DevOps was going to progress and scale it needed to work in the same fundamental way as development teams. This included bringing test-driven development (TDD) into our infrastructure code, and a greater focus on Everything as Code.
Organisations that are further along their DevOps journey have been able to bake this into their DevOps teams. Giving teams greater flexibility and predictability in the way they work, so we now see more mature organisations talking about immutable infrastructure.
It cannot be denied that AWS provides a rock-solid platform
The next signpost in my personal DevOps journey was a step change for DevOps and IT as a whole. And at the time it was missed by almost everyone (including myself). By this point we no longer needed hands-on access to the hardware, replaced by virtual machines and EC2 instances. We could spin up and down our carefully crafted immutable virtual machines in minutes and they would automatically configure themselves to a required role. Then along came Docker and opened the way for developers to step up and take a more active role in managing their applications beyond just writing the application code. This was quickly followed by kubernetes release in 2014. DevOps embraced container technology as quickly as the development teams. At first as part of the testing and build process, but it quickly moved into production environments as well. Today you cannot argue with the significant impact they have had and will continue to have on the development process. Yet DevOps as a role is still as active as ever, often managing the kubernetes platform itself, and there are still deployment pipelines, monitoring and much more to be done by specialist DevOps engineers.
The next signpost and possibly the most used quote at the latest ‘Amazon Web Services, AWS re:Invent’.
“No Server is Easier to Manage Than No Server”
Werner Vogels, CTO Amazon.com 2015
AWS continues to smooth out every bump and bend on the DevOps super highway with the introduction of serverless technologies like Lambda. And it cannot be denied that AWS provides a rock-solid platform.
The argument to remain cloud agnostic is also wearing thin. Organisations that insist on remaining cloud agnostic often introduce more complexity by doing so, nor are they able to fully take advantage of all the features the major cloud providers offer.
Where does this leave the future of DevOps?
So where does this leave the future of DevOps? On the surface it looks like DevOps as a role is in a squeeze alongside Operations teams. Whilst DevOps culture will be integrated into development teams. For those of us with DevOps in our job title, I see the role evolving into a cloud speciality with a focus on optimising the usage of cloud technologies, working as specialist centralised development teams creating tools to augment and aid the development process, providing guidance and best practice across an organisation’s rapidly changing cloud estate. Key to all of this is that DevOps should still be considered a journey and not all organisations need to be in a rush to implement the culture of DevOps in one fell swoop. There are large gains for any organisation to move to a DevOps model at any point in the spectrum. Indeed by moving slightly behind the curve, we can often leapfrog steps and technologies, taking shortcuts from what the bleeding edge have already learned.
