The secret of DevOps success? It's not about the technology
When we look back at the history of the past decade or so of IT, we're going to be able to point at two things as the drivers of most industry change.
Tech Pro Research
The first, and most visible, is the shift to mobile. And the second, hidden behind the scenes, is the rise of agile development methodologies and the impact they've had on developers, operations, and the whole of the IT team.
It's agile development that's one of the drivers of the DevOps movement, breaking down the boundaries between developers and operations, while changing monolithic apps into clusters of microservices.
If we're to have more flexible businesses that take advantage of IT, it's essential to move to a model that understands APIs, services, and is able to respond quickly to business needs — and at the same time support ad hoc development.
There's a lot of DevOps tooling out there, and it's easy enough to build a mix of open and proprietary technologies that will fit into even the most regimented development model and the most controlled infrastructure. You can take your pick of configuration automation tools, of source control, of IDEs, of social networks — all you need are the tools that work for your team and for your project.
It's clear that the secret of a successful DevOps deployment isn't the technology. Instead, it's about building an appropriate culture. Without that culture, no matter how impressive the technology you've put in place, you're going to be left with failure.
Like any social project inside an organisation a big bang approach to delivery doesn't work.
So how do you build a DevOps culture? The answer, at least according to the panellists at a RackSpace event I was at last week, is "start small", with strong leadership.
Like any social project inside an organisation, a big bang approach to delivery doesn't work. If you force everyone to collaborate, there's a contrarian streak in many people that puts up walls, encouraging a jobsworthy approach to things.
However, if you deliver a successful project in one area, there's an opportunity for other groups to adopt the same approaches — especially if tied into a forum where all the DevOps groups in an organisation can share the lessons they've learned.
Tying DevOps into a microservices transition makes a lot of sense. It's a proven approach, mirroring the way large-scale web and cloud services operate.
If you look at the home page for a site like Amazon, it looks like a monolithic application. However, it's actually an assemblage of microservices, 10 (or even 20, depending on the user context) services being used to deliver the information that makes up the page.
Amazon is very much a DevOps pioneer, with each of those microservices run by an integrated DevOps team — and at a point where it's deploying every 12 seconds or so. That's not going to be the case for an organisation bringing DevOps into an existing development process, especially one built around older development methodologies — and using tools such as the waterfall process. DevOps culture is an agile culture, and you're going to need to identify an agile project as a place to start implementing DevOps.
That's why choosing an agile project as the foundation of a new culture makes a lot of sense. You're already developing a culture that avoids the "throw it over the wall, learn when we're done" flaws of waterfall development. Bringing the operations and infrastructure team to the party isn't as long a reach as it might be under other circumstances.
Adding agile culture to the operations team isn't hard, especially if you can dedicate a small team as part of an initial project, and needs to be linked to automating much of the operations workload.
By offloading tasks like server maintenance and deployment to tools such as Puppet and Chef, operations teams can concentrate on delivering the infrastructure services that act as the foundation for any applications. Defined server images and standardised platforms let developers deploy new servers quickly, and also mean that operations teams can concentrate on providing new services proactively.
Once tooling is in place, it's possible to start rolling out aspects of the new operations platform to other services and applications, letting the entire team take advantage of new tooling — and giving operations the techniques and culture it needs to support the rest of the business' transition to a more agile way of working. Think of it as "operations as a service", an approach that fits well with microservice and cloud models.
DevOps culture goes to more places than developers and ops. The one aspect that's often missed is the role of the user. User feedback is key to identifying issues and setting priorities. Users need to part of any DevOps team, whether as representatives or through reporting software and user testing.
It's interesting to note that Microsoft has provided tools for linking the UserVoice service into its Visual Studio development suite — closing another part of the feedback loop.
Building a DevOps culture isn't easy. Like any cultural change it needs to be approached sensitively, taking a step-by-step approach and encouraging participation. You won't be able to build it overnight, but you will be able to bring it to new projects and services as you modernise your applications to respond to business demands.
With a DevOps culture you'll be able to innovate and iterate, getting results more quickly — and that's most definitely a good thing.