JAXenter: DevOps celebrated its 10th anniversary last year. It all began in 2008 when Andrew Shafer and Patrick Debois presented their “Agile Infrastructure” talk. Could you perhaps make a quick analysis of how DevOps developed over the past 10 years?
Steve Poole: Adoption of DevOps has pretty much followed the same line as other tech ideas. We had the usual ‘that doesn’t apply to us’ and the perennial ‘we’re already doing DevOps’ responses both of which were incorrect. Then we saw more of the ‘DevOps is too complicated’, ‘DevOps is too disruptive’ and ‘we’re not Netflix’ when organizations began to seriously consider adoption but thought it was all about tools. Then, when people began to report back that they were getting real value out of using the DevOps approach, the penny dropped and people began to see that DevOps really is an evolution of agile and that it’s about people *and* tools. From a technology point of view, the rise of cloud, containers, and microservice architectures have really driven home how we all need a DevOps approach to create, deploy, and manage modern applications.
Michiel Rook: I’m not entirely sure when I first became aware of the term “DevOps”. I know that I’ve been applying the principles since well before 2008. I’ve always had a focus on (quickly) delivering value, and I believe that focus is fundamentally incompatible with the traditional way of doing things: erecting walls between people, teams and departments.
Julia Wester: DevOps has changed from merely focusing on the last mile – from code commit to deployment – to a more holistic focus on delivering value from end to end. We’re hearing more about shifting left to include more of the value stream. We are focusing more on the people aspect than we used to. Now, we hear about it as much as – if not more so than – the tools aspect. Though much of the literature still focuses on that last mile. What we’re talking about in the field does not.
JAXenter: How would you describe the current state of DevOps? Where is it headed?
Steve Poole: I really hope that the current complexity of cloud deployment is going to flatten out and even reduce. We spend a lot of time using DevOps tooling to deal with a level of deployment complexity that is, in my mind, unsustainable. Looking back we’ve come from a world where we used DevOps to simply deploy existing applications faster to a world where today everyone – dev or ops – has to know a great deal about intricacies of clusters, containers, networks, multi-stage deployment strategies, security, and application cloud architectures. We are working on ways to make some of this easier and less visible but I am concerned that we’ve accepted a level of complexity into our lives and it’s become the new norm.
Michiel Rook: Some people in the community have expressed their concern that DevOps is turning into a cargo cult. That danger definitely exists, especially with vendors selling “DevOps tools”. This could lead to the false belief that buying the tool will add DevOps to your organization. On the positive side, I do see more and more (larger) organizations embracing the principles of DevOps. A lot of them are struggling (and it definitely isn’t easy, given where some of these organizations are coming from), but at least they’re trying.
Julia Wester: I was asked what the future of DevOps looked like a few years ago after a talk at DevOps Enterprise Summit. I have the same opinion now. The future of DevOps is systems thinking. DevOps was always a focus on an interaction between the development function and the operation function. Now that we are making progress with that handoff, optimizing it, we’re moving to include much more of the value stream… more of the interactions. You can tell as we hear terms like DevSecOps, BizDevOps, etc. We have realized there are more problems and we’re trying to tackle those as well so we can make it a more optimized whole. This is systems thinking – working on the interactions in a system.
JAXenter: Developers are facing more and more tasks formerly handled by operators and vice-versa. Are the classic roles of developers and operators still going to be used in the future as well or are they blending?
Steve Poole: The simple answer is that there will always be a separation between the two roles. I have looked at DevOps as being a movement to redefine the relationship between the two roles and redefine who does what. Just like the beginnings of agile – where we brought the developer and the tester together and redefined their relationship – I hope that when we’re finished we’ll have a new balance between dev and ops. I’d expect developers to be thinking much more about the deployment topologies and resilience and security of their application and I would expect the ops teams to understand that they have to provide the relevant tooling and configurations so that developers can test their solutions.
Michiel Rook: There will always be personal preferences, aptitudes, and interests. And that’s totally fine. However, I do think the days of the hardcore specialist are mostly gone. In my opinion, if you want a high performing team it should be composed of a set of mature, diverse, cross-functional people. that embrace change, love learning new things, can support each other and develop great software.
Julia Wester: I think the classic roles will remain but that each will be expected to understand more about the areas in which they overlap…
JAXenter: DevOps is not only about the cultural aspects, but also about the tools. Which tools do you recommend for a successful transition to DevOps?
Steve Poole: Well, success comes from having the correct mindset rather than a particular set of tools. However, from a tooling point of view, the list is pretty straightforward. You need a robust CI system like Jenkins, an SCM like git, a container system like Docker, a container orchestration system like Kubernetes. You also need a solid monitoring solution, and an automatic configuration management system like Ansible. Phew. It’s a long list. Then you need to wire these tools together and make sure they are robust and secure and that everything is under change management. Finally, you need to be able to show that your developers can create and test container-based solutions easily and with no or minimal differences in environment between test and production. That’s why I said that you need the correct mindset to see this through. You can start to be successful though by concentrating on the basics of having good configuration management and a shared container solution that allows testing with parity across environments.
Michiel Rook: I believe that tools don’t make DevOps. Or rather, introducing DevOps in an organization does not imply using specific tools. Of course, automation is a key component of DevOps, so any tool that helps with that is potentially useful. In any case, the way public cloud services, Docker and especially Kubernetes have transformed the infrastructure and application deployment landscape has been nothing short of staggering.
Julia Wester: I won’t recommend specific tools but you need source control systems and build systems – ideally connected to processes that will deploy artifacts to environments and install them for you so they’re done consistently every time. You need work tracking tools to help see how smoothly (or not) workflows through your value stream and how long it takes to do so.
JAXenter: Do you have any best practices that every team or company should embrace when moving to DevOps?
Steve Poole: The best practice is to start small and develop a single solution with dev and ops in it from the beginning and working side by side. Have a third party facilitator there who can help mediate the disputes and tease out the reasons behind such things. From a team point of view, you need to get the dev and ops teams closer together and talk. You need to figure out how to get that to happen. The primary education in need is for developers to understand more about the ops side. The list of responsibilities that the ops team have is significantly larger than that of the developer and the developer is generally unaware of this. I’ve seen some interesting results with design thinking used to get developers and ops teams more aware of each others’ motivations and challenges.
Julia Wester: Best practices are only applicable when there’s one best way of doing things. Most things we talk about are in the space of good practices, or even emerging practices. Good practices I recommend are:
- Get input from all team members when defining existing challenges. Don’t assume you can see the whole picture from a management position.
- Make creating a psychologically safe environment a top priority. If you don’t, the problems you need to address will be hidden from you.
- Treat improvement as a continual stream of work – carve out time, give it the priority.
- Visualize as much as possible: work (aka value being delivered, including improvements), the process that it goes through, any problems it encounters, etc.
JAXenter: What do you think are the biggest obstacles in implementing DevOps successfully?
Steve Poole: Complexity of the solution infrastructure, unwillingness of the dev and ops teams to actually want to work together (which is mostly driven by mutual incomprehension) and support from the business to actually re-invent the team dynamics and infrastructure. The risks are high if people go into trying a DevOps approach without understanding that it can be a fundamental cultural change for those involved.
Michiel Rook: I’d say culture and leadership. An organization that does not trust and empower its teams to deliver great products, with sufficient autonomy, will continue to add processes, walls, silos, and bureaucracy. An organization that does not embrace bottom-up decision making, the agile mindset and a modern way of working will ultimately fail in applying DevOps successfully.
Julia Wester: Thinking DevOps is a role or a team and expecting those people to do the “DevOps” is certainly a challenge. Other challenges are:
- Thinking a new toolset will fix the problems addressed by the DevOps movement. Tools will help, but they are a means to an end. Not the solution in and of themselves. The harder problems are the people and mindset problems.
- The name DevOps doesn’t help executives realize that it’s something that they need be part of as opposed to something they can delegate down to teams/departments. We need to help executives understand their role in a “DevOps transformation.”
Our Experts
Steve Poole is Developer Advocate, DevOps practitioner (whatever that means). longtime IBM Java developer, leader, and evangelist. I’ve been working on IBM Java SDKs and JVMs since Java was less than 1. Also had time to work on other things including representing IBM on various JSRs, being a committer on various open source projects including ones at Apache, Eclipse, and OpenJDK. Also a member of the Adopt OpenJDK group championing community involvement in OpenJDK. A seasoned speaker and a regular presenter at JavaOne and other conferences on technical and software engineering topics.
Julia Wester is the co-founder and Principal Consultant at Lagom Solutions (https://lagom.solutions), a Lean/Agile consulting and training company that leverages her 17 years of experience working in and managing teams at Turner Broadcasting, F5 Networks, and LeanKit. Julia is passionate about teaching others how to tame the chaos of everyday work by embracing transparency, continuous improvement, and a Lagom mindset, as well as talking about how management doesn’t have to be a dirty word. Julia blogs at everydaykanban.com and tweets at @everydaykanban.
Michiel Rook is an experienced freelance consultant, developer, trainer & speaker from the Netherlands. He loves helping teams and companies to develop better software and improve the delivery process. When he’s not thinking about continuous deployment, DevOps, or event sourcing, he enjoys music, cars, sports, and movies.
