We’re counting the days until the end of 2016. As 2017 comes into focus, we find ourselves reflecting on the advancements made in the world of DevOps during this past year, the challenges still to overcome, and some of the trends that will shape the software delivery industry in the year(s) to come.
To give a proper farewell to 2016 and welcome in the new year, we hosted a special episode of Continuous Discussions (#c9d9) featuring industry luminaries and experts looking back on the state of DevOps in 2016 and asked what emerging trends they see prevailing in 2017.
Our expert panel included Robert Stroud, principal analyst at Forrester; Nicole Forsgren, CEO and chief scientist at DORA; Chris Riley, analyst at fixate.io; Alan Shimel, Editor-in-Chief at DevOps.com; Manuel Pais, author on InfoQ and Skelton Thatcher; and our very own Sam Fell and Anders Wallgren. Continue reading for their exclusive insights into what’s in store for DevOps in 2017, plus some of their own DevOps New Year’s resolutions.
Looking Back at 2016
Pais looks back on 2016 as the year DevOps moved from a grassroots movement to a management-led transformation: “I think 2016 was really the year where we saw DevOps crossing the chasm from early maturity to later maturity. I like to make that distinction because I think there are different trends going on in those different groups. For the majority of early-adopters – organizations that have already been doing DevOps for a while – what I’ve seen a lot is that they’re now focusing on what’s the best way to organize the teams. Moving, often, from having just specific people who know about Continuous Delivery, DevOps, and so on, to actually getting platform teams that kind of embed all the services that they want the development teams to use, so kind of streamlining in a way.
For the late-adopters, we now see a lot of large organizations trying to get on board with DevOps. It’s interesting because I see clients where top management brings in the idea of, ‘Okay, we need to go do DevOps.’ Before, early adopters, like the companies speaking at the DevOps Enterprise Summit, typically started from the ground up. Then when the results came in, management gave them support to roll it out. But now, it’s management bringing in the idea and the people on the ground are sometimes a bit confused because there’s not a clear explanation of what DevOps means for them. So that’s what I would say are the large trends I’ve seen, in organizational terms.”
Development teams are still by and large the ones adopting DevOps in 2016 versus operations teams, explains Stroud: “In 2016, it’s increasingly been about ‘how do I set up a DevOps organization to keep up with development’s rate and pace of change?’ One of the data stats we pulled has to do with DevOps adoption in development versus operations. Isn’t that ironic? Because the name DevOps is dev and ops. We still seesignificantly more DevOps adoption in development than operations, but the good news is the gap is closing, based on the Forrester data. So that’s one of those things that’s happening, but what we’re also seeing is the advent of containers and containerization and what that’s doing to DevOps.”
Riley on DevOps’ sex appeal and container environments in 2016: “The sexiness of DevOps has gone away. In 2016, we’ve been a lot more real about what it is. I think that this was the year where we started to see people who have either started to build environments that are successful or turn out to be failures. I think it’s going be very similar to Agile adoption, and we’re going to know very quickly whether people are building Waterfall 2.0, or they’re actually living the practices of DevOps. It’s not a technology.
For me, personally, 2016 was also the year that I became less of a curmudgeon on Docker. I was very happy to see some of the evolution that’s come with that. I think that’s going to impact 2017 in a huge way. Instead of Docker becoming synonymous with containers, I think containerized environments are really going to be the thing.”
The number of organizations who don’t even know what DevOps is has been worrisome to Forsgren: “It really seemed to me like 2016 was the year that people really caught their stride. So the people who kind of know what they’re doing really caught their stride, and it seemed like the high performers just absolutely took off, and they were killing it. It was amazing, and we heard some fantastic stories, and we saw it in the data. But you still hear so many organizations have not heard of DevOps. They don’t really know what it is. They’re convinced it’s going to be fine. They’re totally fine. It shouldn’t surprise me, but it still it worries me just a little bit. We’re getting more and more people sort of being convinced that they need to jump on this train, or it’s going to leave them behind, but we still have a handful that are still ignoring this, thinking ‘It’ll be fine. I’ve been doing this for 20 years.’”
Fell, emphasizes the importance of small, incremental changes that lead to great improvements: “It’s never been truer than in this accelerated cycle that we’re seeing with productivity and all this awesome value being created from relatively minor, incremental improvements in process, in tooling, and all the stuff that we do, and the feedback that we’re getting. Gene Kim says the improvement of the quality of the daily work is actually more important than the absolute quality of the daily work. I believe that to be true. If you’re constantly improving things, you’re going to end up being better than the person who is really good today but never moves forward.”
Reflecting on 2016, Shimel has created his own theory on DevOps adoption: “I call my theory Pockets of DevOps. Think of pockets of DevOps as bubbles, like little kids play with bubbles. So at some organizations who started a little earlier than others, you have multiple pockets of DevOps within the organization, small teams, not really high executive-led, but mid-management or bottom-up, mid-out. We saw these people talking at Gene’s and Electric Cloud’s DevOps Enterprise Summit the last three years. What we’re seeing is, in these organizations that started earlier, these pockets of DevOps are now joining together to form bigger bubbles, if you will. Then we still have organizations that only have one or two pockets of DevOps – little bubbles. But some of those bubbles are popping, and we’re not hearing about them.”
Wallgren discusses the rise of containers and microservices in 2016: “There are a couple of things that have been big in 2016. Containers are huge. I think, related to that, microservices as well. I think what’s starting to happen and most people are starting to realize (some people the hard way) is that you’re going to have a really hard time doing this well with a crappy architecture, whether that be a crappy architecture for your pipeline or crappy architecture for your application. Application architecture matters in your ability to do DevOps well. If you have a bunch of legacy software that you’re dealing with, and that’s probably a big chunk of the people who aren’t yet doing it, how are they going to do it? With a legacy app that takes 10 hours to build, takes three weeks to test, what are they going to do? Everything is fine and rosy if you’re starting with a greenfield app, but I think the legacy stuff will be where it gets really interesting in the future.”
What’s Next? Looking Ahead to 2017
There are three main trends Stroud sees taking hold in 2017: “First, I’m seeing organizations look to drive mainframe R&D in a DevOps methodology, not just mainframe development, but also supporting velocity in rolling it out to production, with organizations moving from one or two major releases a year, to now experimenting with both quarterly and monthly releases using DevOps practices and experimentation and techniques. Second thing is what I now call BizDevOps. I’m really starting to see, with the advent of solutions like low code and no code, business analysts can actually write business applications and use APIs to join pieces together and put new user interfaces on top. We’re starting to see true experimentation with what’s called BizDevOps, but that predicates the release pipeline being automated across CI, CD, and to release. Containers are really starting to fuel that momentum, transforming the way we do things.”
Shimel on DevOps tools’ silos and consolidation: “I want to focus on two things for 2017. Number one is what I call the breakdown of DevOps tools’ silos. It’s really ironic that in something like DevOps, where the idea was to break down silos between dev and ops, dev and QA, and QA and security, but what we’ve done is we’ve built new silos of DevOps tools. So we have configuration management DevOps solutions. We have CI/CD DevOps solutions. We have APN DevOps solutions. ARA and “alphabet soup” DevOps solutions. They all exist in silos. Now we have more silos, which is the anti-DevOps. Secondly, as a business analyst, I was a little surprised that we haven’t seen more consolidation in the DevOps space, up until very recently. We’re going to see a lot of DevOps consolidation, and that will also foster DevOps tools working together as well, as some of these maybe bigger plays try to amass an end-to-end DevOps story.”
Strategic DevOps transformations will be the key in 2017, says Forsgren: “I think we’re going to start to see companies being a little bit more strategic about tackling their DevOps journey and their technology transformation. In the past, it was – with love and respect – such a shit show. You could start anywhere, and you were going to get better. But now, if you’re already on your way, you need to be careful and strategic about what you’re fixing. If you’re nowhere on your way, you are so far behind. that you have to be strategic and careful about where you start.’ I think it’s going to be a huge trend moving forward to do really careful and strategic assessments about where you are, intentional prioritization and strategy about understanding what your constraints are, so that you can do strategic capabilities development moving forward.”
Fell realizes that there are still a lot of organizations not doing Agile or DevOps, which hopefully changes in the coming year: “We are living in this bubble, happy bubble, of everybody gets DevOps and we’re all Agile. But we talk with folks in the Rust Belt, or we got a lot of people that we talk to who are just like, ‘Wow. Yeah, we do nightly builds, and we’re really looking forward to doing continuous integration.’ Your jaw drops, like, ‘Wow. Yeah, that’s a good idea. You should do that.’”
2017 will be a disruptive year for DevOps as we know it, Riley discusses: “In 2017, we’re going tostop defining DevOps, and we’re going to hopefully use the word a lot less. We’re going to be real about what it is and getting it done. It’s going to be a lot less talk and more doing. I would like to hear more about the failures, because until we start surfacing those, not only are we going to learn from them, but also be able to prevent organizations from doing the whole, ‘We failed, we give up,’ thing.
One of my biggest fears is that we’re only creating a modern version of old environments, where people get locked into their setups. In three, five years, they’re looking back and saying, ‘Oh, now this is an old thing, and we need to start over.’ Whereas true DevOps means you’re ready to adapt, and you can grow with the environment. I also think organizational structures are going to change in a big way. I think we’re going to see a lot more shared services business units. We’re going to see DevOps titles, a lot more engineering in titles, a lot more cross-functional stuff.
It’s going to be disruptive, but also very interesting to see how engineering groups adapt and people’s careers change. Then, finally, I’d like to expand on the tooling market. I think in the first quarter or the first half of 2017, we’re still going to see this influx of tools coming in. I mean, there’s a new one I encounter every day, especially in the release automation area. Where I believe there will continue to be growth is container-native tooling, container-native security and container-native release automation.”
We will start to see different ways to collaborate and an increase in DevOps certifications in 2017, per Pais: “I don’t know exactly how this is going to shape up, but I feel like there is space for new ways of thinking about getting people to collaborate and getting a lot of different specialties in the organization to work together for faster delivery. To me, it’s a problem that’s not clear how to solve in many organizations.
The other thing that these organizations are bringing in is traditional vendors – your CRMs, ERPs – they’re going to start to be pushed, more and more, to up their game and make their solutions more transparent, more malleable to rapid delivery, because that’s one of the main problems that these more traditional organizations face. They don’t know how to go about improving delivery in these kind of systems. And I wanted to mention another thing, which is a bit like what happened with Scrum. I think we’re seeing more and more DevOps education and certifications. I know, for example, there’s an IEEE standard for DevOps being worked on.”
DevOps will play a larger role in FinServ organizations, according to Wallgren: “I think 2017 will be when we start to hear about some of the failures, which is good because we learn from that. But, I think there’s also going to be quite a few people who say, ‘Yeah, we tried DevOps. It doesn’t work. It’s all hype. It only works for the unicorns. It only works for new software. It only, it only, it only, it only.’ That will happen with any sort of new thing, but I think it’s about that time.
Then I think we will see some, hopefully, interesting disruption in the financial technology area, because I think the financial institutions have always treated tehcnology as a key differentiator.’ Now, the problem they have is that their culture, by and large, sucks. So there may be disruption there, where new financial technology, new online banks, new companies will be forced to play nice with one another. Somebody’s got to.”
New Year Resolutions
There are three things Pais would like to see done better in DevOps in 2017: “One, value stream mapping for your delivery teams. Even if it’s one day or one afternoon, get people together and see how your delivery pipeline actually works when you get everyone in the room. The benefits are immense, and a lot of organizations think they know what’s going on, but they don’t. Even if you don’t do anything afterward, at least you will see something new.
The other thing is, don’t optimize small things, like build times or testing times, when you have problems that are much bigger. Like if your infrastructure provisioning still takes days or weeks, then work on that first. A lot of organizations are focused on local optimizations when there’s a lot more to look at. Lastly, get everyone under the same umbrella in terms of incentives. It doesn’t matter in which format. If it’s KPIs or financial incentives or appraisals, whatever you have, just get everyone (developers, operations, security, etc.) to share the same objectives, in terms of speed of delivery, mean time to recovery, better security – make sure it’s the same for everyone.
Wallgren advises to make sure you are staying on track with your goals: “I think what we all need to do is keep our eyes on the ball. This goes into the whole experimentation and strategy tactics and just the whole idea, ‘Why are we doing this?’ We’re doing this to bring more value to our customers, to our employees, to make things better. I think that’s something to keep in mind because if what you’re doing on any given day isn’t moving that ball forward, what was the point? I think we need to focus a little more on that.”
Make sure you have a DevOps steward (not a boss) on your team, advises Riley: “I’d say that fostering stewardship is important. You don’t have to have somebody who owns DevOps, but you should have somebody who’s consciously stewarding DevOps across the entire environment. In some organizations, where I’ve seen this done really well, it’s through cloud services or a shared services type business unit. They’re not the bosses of DevOps.
There is no boss. There is a steward of DevOps that helps make sure everybody has the tools and the know-how to build it across the organization. My final resolution would be focus on tactics. I think strategy is important. I do think that we spend a little bit too much time talking about what we’re going to do, and I’d like to see more people bite down on small steps of something. Continuous integration is a relatively safe area to begin.”
Practice empathy for everyone on your team, says Shimel: “Have empathy for your fellow workers, empathy for your fellow humans. Don’t think because you’re the dev, that what you’re doing is more important than what the ops guy is doing. When the QA guy is saying, ‘Geez, I’m afraid I’m going to lose my job because we’re automating the crap out of my testing,’ don’t say, ‘Geez, that’s too bad. Don’t worry. You’ll find another job.’ The guy is a person, has children and spouses. Empathize what they’re feeling. Empathize with the security guy, who doesn’t know any better. He just knows how to say, ‘No,’ right? That’s what he knows. Give him a break. So for 2017, empathize for the person you’re dealing with. Put yourself in their shoes. Try to make the whole thing work.”
Stroud hopes to see the culture of collaboration continue: “Strategy without execution is wasted time. We have to execute. We have to be prepared to fail. We have to be prepared to come and share our experiences. That’s all part of that blameless culture and we have to put that culture into practice. Let’s put our stake in the ground and go with it. I also like the idea of collaborating. As we learned at the DevOps Enterprise Summit, the culture in that environment is of community and sharing and talking to people. I’ve been involved in this industry a long time, and I haven’t seen a lot of that. I want to keep encouraging it. As DevOps becomes more mainstream, and we take the term away, and it turns into education classes, and we all become masters of DevOps, let’s not lose what we’ve got.”
It’s all about measurement, according to Forsgren: “Take small steps along the way to get better – your experiments, your tactics in support of your strategy, your leadership having a vision to support business goals. You don’t know if any of these things are working unless you have really good assessments and measures to tell you if these really, really small steps you’re taking are working. So that’s going to be my goal, is having all of us think about measuring in smart ways so that we can actually do these experiments that are small, that allow us to fail, because big massive failures are scary, but those are the ones that are easy to measure with crap measurements. Because when you fail big, you know you failed big.”
Watch the full episode here!