The end of 2016 is approaching. As 2017 rolls around, we reflect on some of the developments in the DevOps world in 2016, the challenges to be addressed, and some of the trends that will transform the software delivery industry in the future.
To bid farewell to 2016 and usher in the New Year, we’re hosting a special ongoing discussion (# C9C9) featuring industry celebrities and experts looking back at the state of DevOps in 2016 and exploring the trends they think will be popular in 2017.
Our expert panel includes Robert Stroud, Principal Analyst at Forrester; Nicole Forsgren, DORA CEO and Chief Scientist; Chris Riley, Analyst, Fixate. IO; Alan Shimel, editor-in-chief of DevOps.com; Manuel Pais, author of Articles on InfoQ and Skelton Thatcher; And our own Sam Fell and Anders Wallgren. Here’s a look at some of the experts’ unique perspectives on what’s going to happen to DevOps in 2017, and some of their decisions for DevOps 2017.
Back in 2016
Pais looks back on 2016 as the year that DevOps went from a grassroots movement to a management-oriented transition: I think 2016 saw DevOps cross the gap from green to mature. I like to make a distinction because I think there are different trends that happen in different teams. For most early Adopters of DevOps — organizations that have been DevOps for a while — I often see them focusing on what is the best way to organize their teams. Their teams basically went from just a few people who understood the concepts of continuous delivery, DevOps, etc., to actually building a platform set that embedded all the services they wanted the development team to use, which was somewhat streamlined.
For late adopters of DevOps, we are now seeing many large organizations trying to adopt DevOps. It’s interesting, because I see a lot of clients where management thinks, “Ok, we need DevOps.” Prior to that, early adopters, such as the company that spoke at the DevOps Enterprise Summit, often started DevOps first with people at the bottom. When results come, management comes back to support them. But now, management introduces the idea of using DevOps, and people at the bottom are sometimes a little confused because there isn’t an explanation of what DevOps means to them. So this is the dominant trend that I see in terms of organizations.
Development teams were still the dominant DevOps adopters in 2016, rather than operations teams, Stroud explained: “In 2016, it was more: ‘How do I build a DevOps organization to keep up with development and change? ‘One of the statistics we collected was about DevOps adoption among development and operations teams. Isn’t that ironic? Because the names for DevOps are Dev and OPS. We’re still seeing far more DevOps adoption in development than in operations, but the good news is that the gap is closing, according to Forrester data. That’s what’s happening, but we’re seeing the impact of both containers and containerization on DevOps.”
Riley on the “sexiness” and container environment of DevOps in 2016: DevOps is no longer sexy. In 2016, we have a much more realistic sense of what DevOps really is. I think in 2016, we’re starting to see people who have either set out to build successful environments or have failed. I think it’s very similar to the adoption of agile models, and we’ll know very quickly if people are using Waterfall 2.0 or if they’re actually practicing DevOps. It’s not a technology.
For me personally, 2016 has been a year in which I feel more comfortable with Docker. I’m glad to see a lot of evolution that has come with Docker. I think Docker will have a big impact in 2017. Docker will not become a synonym for containers, and I think containerized environments are likely to be accepted.
For Forsgren, the number of organizations that don’t yet know exactly what DevOps are is alarming: in my opinion, 2016 saw people catching up. The people who knew what they were doing really caught on, and it seemed like the top performers really took off, and they loved DevOps. It’s amazing, we’ve heard some really interesting stories, and we can see it in the data. But you still hear that a lot of organizations haven’t heard of DevOps. They don’t quite know what it is. They believe DevOps is going to be great. That’s fine, and I shouldn’t have been surprised, but I was worried. We see more and more people being convinced that they should jump on the DevOps train or they’ll be left behind, but we also know companies that don’t care and just think, “We’ll be fine, we’ve been doing this for 20 years.”
Fell emphasized the importance of small, incremental changes because of the huge improvements they can make: this is very true: it’s an accelerated cycle of amazing value, productivity gains from small, incremental improvements in processes or tools, etc. Gene Kim says improvement in the quality of daily work is actually more important than the absolute quality of daily work. I believe it to be true. If you keep improving, you’ll end up better than someone who does well every day but never gets ahead.
Reflecting on 2016, Shimel developed his own theory on DevOps usage: I call my theory DevOps pockets. Think of A DevOps pocket as a bubble, like a child playing with a bubble. For organizations that are one step ahead of the rest of the organization, there are pockets of DevOps within the organization, small organizations, not very executive-led at the top, but middle management or from the bottom up, all the way to the middle. We’ve seen these people speak at Gene and Electric Cloud’s DevOps summit for the last three years. What we’re seeing in these early starters is that their DevOps pockets are now coalescing, so to speak, into a bigger bubble. We still have some organizations that only have one or two DevOps pockets — little bubbles. But some of these bubbles popped and we never heard of them again.
Wallgren discusses the rise of containers and microservices in 2016: Several things were discussed in depth in 2016. Containers are a big deal. Related to that, I think micro-services are too. What I think is going to happen, and what most people are starting to realize, some of them the hard way, is that it’s hard to get things done based on a crappy architecture, whether it’s a crappy architecture for pipelines or applications. Application architecture also plays an important role in your ability to perform DevOps. What do people do if they want to deal with a bunch of leftover software, and there are probably a lot of people who haven’t done DevOps yet? What do you do with a legacy application that takes 10 hours to build and three weeks to test? You’re better off building a new app from scratch, but I think what you do with the software that’s left over is the more interesting aspect of the future.
What’s next? Looking ahead to 2017
Stroud sees three major trends in 2017: First, I see some organizations looking to use the DevOps methodology to drive console development, not just console development, but also to accelerate the development to production process, moving an organization from one or two major releases a year to quarterly or even monthly releases that leverage DevOps practices, experiments, and technologies. The second thing I call BizDevOps. I’m really starting to see, with solutions like Low Code and No Code, business analysts being able to write their own business applications and use apis to connect the pieces and build new user interfaces on top of them. We are beginning to see a real experiment in what we call BizDevOps, but this experiment is based on the assumption that the pipeline across CI, CD, and release is automated. Containers start to drive us towards that milestone and transform the way we do things.
Shimel discusses the brutality and integration of DevOps tools: “In 2017, I want to focus on two things. One is what I call the breaking of the DevOps toolkit. Ironically, DevOps and the like wanted to break down the silos between Dev and Ops, Dev and QA, QA and security, but what we did was we built a new repository of DevOps tools. So we have a DevOps solution for configuration management. We have a CI/CD DevOps solution. We have the APN DevOps solution. ARA and “Alphabet Soup” DevOps solutions. They all exist in the warehouse. Now we have more warehouses, which is actually the opposite of the DevOps concept. Second, as a business analyst, I’m a little surprised we haven’t seen more consolidation in the DevOps space until now. As some large projects gather an end-to-end DevOps story, we will see a lot of DevOps integration, which will drive DevOps tools to work together.
Forsgren says strategic DevOps shifts will be key in 2017: I think we’ll start to see some companies become more strategic in their DevOps journey and technology transformation. In the past, this process has been poorly done. You can start anywhere and you’ll get better. But now, if you’re already transforming, you need to be serious and strategic about what you fix. If you haven’t already made the transition, you’re way behind, and you have to be strategic and serious from the start. I think this is going to be a very big trend: you’re going to take a serious and strategic assessment of where you are right now and set priorities and strategies to understand where your constraints and limitations are so that you can strategically develop capabilities and move forward.
Fell realized that there are still a lot of organizations that are not adopting agile models or DevOps, and in the coming year hopefully that will change: we live in this bubble, the happy bubble, that everyone is using DevOps and we are all using agile models. But I’ve been talking to people at Rust Belt and a lot of other people, and they’re saying, “Oh yeah, we’re doing nightly builds, and we’re looking forward to continuous integration.” Your jaw might drop and you’ll reply, “Oh yeah, that’s a good idea, you should do that!”
Riley discusses that 2017 will be a breakthrough year for DevOps: 2017 will be the year we stop defining DevOps, and we want to use the term a little less. We’ll get a real sense of what it is and how to do it. There will be less discussion and more practice. I love to hear about failures, because if we face them, we can not only learn from them, but we can stop the organization from doing things like, “We failed, we quit.”
One of my biggest fears is that we’ve just created a modern version of an old environment where people are stuck in the configuration of the environment. In three to five years, someone will look back and say, “Oh, this is an old thing now, we’re going to start from scratch.” But true DevOps means being prepared to adapt to the environment and grow with it. I also think the organizational structure will change dramatically. I think we’re going to see more shared service business units. We’re going to see DevOps titles, more engineers with DevOps titles, more cross-functional employees.
It’s going to be groundbreaking, and it’s going to be interesting to see how teams of engineers adapt and how people’s careers change with it. Finally, I hope to expand the tool market. I think we’re still going to see a lot of tools coming in the first quarter or first half of 2017. I mean, I come across a new tool every day, especially in the release automation space. What I believe will continue to grow are container-native tools, container-native security, and container-native publishing automation.
Pais comments that in 2017, we’ll see more collaborative approaches, more DevOps certifications: I don’t know exactly how it will take shape, but I think there’s room for introducing new ways for people to collaborate, for many different areas of expertise to work together, to deliver faster. To me, this is something that a lot of organizations don’t know how to solve.
The other thing that these organizations will introduce is that the traditional vendors — your CRM, YOUR ERP — will start to be pushed to do better, to be more transparent in their solutions, to be more malleable to fast delivery, because this is one of the major issues that these traditional organizations face. They don’t know how to improve delivery in these systems. I also want to mention one other thing, which is kind of like what happened to Srcum. I think we’re going to see more DevOps education and certification. For example, I know of an IEEE standard for DevOps that is being planned.
Wallgren says DevOps will play a bigger role in FinServ organizations: I think we’ll start hearing about failures in 2017, which is good because we can learn from them. But I think at the same time there are people who say, “I tried DevOps. No success. It’s all hype. It only works for the titans. It only works with new software. It just, it just, it just, it just.” Anything new will have that kind of thing, and I think it’s a matter of time.
And then, I hope we’re going to see interesting breakthroughs in financial technology, because I think financial institutions have always used technology as a key to their competitive advantage. The problem they have now is that their culture as a whole is terrible. So there could be a breakthrough in that area. More fintech, new online banking, new companies will be forced to collaborate. Someone has to do it.
New Year’s resolutions
Pais wants to do three things better in DevOps in 2017: First, deliver the team’s value stream mapping. Even if it’s just for a day or afternoon, get your team together and see how your delivery pipeline really works. It’s a huge benefit, a lot of organizations think they know what’s going on, but they don’t. Even if you don’t do anything after the discussion, at least you’ll see something new.
The other thing is, don’t optimize small things like development time or testing time when you have more important things to do. For example, if your infrastructure supplies are still taking days or even weeks, address that first. Many organizations focus on local optimization because there is so much that can be done. Finally, let everyone be exposed to the same stimulus. It doesn’t matter what form it takes, whether it’s KPIs, financial incentives or performance reviews, get everyone (development, operations, security, etc.) to share a goal of speed of delivery, average recovery time, stronger security — make sure it’s the same for everyone.
Wallgren recommends making sure you stay on track: I think all we need to do is focus on one goal. It involves the whole experiment and strategy and tactics, focusing on just one thought, “Why are we doing this?” We do this to bring more value to our customers, to our employees, to make things better. I think it’s important to remember that if what you do on any given day doesn’t get you closer to your goal, what’s the point? I think we need to focus more.
Riley suggests having a DevOps manager (rather than a boss) : I would say that facilitating management is very important. You don’t need one person to “own” DevOps, but someone should consciously manage DevOps throughout the environment. In some organizations, I’ve seen this done well, through the model of cloud services or shared service type business units. They are not the bosses of DevOps.
There are no bosses in DevOps. Instead, there is a DevOps manager who helps ensure that everyone has the tools and instructions to build DevOps across the group. My final resolution is to focus on tactics. I think strategy is very important. I think we’ve spent a little too much time talking about what to do, and I’d like to see more people step forward. Continuous integration is a relatively safe place to start.
Cultivate empathy among all people in the group: have empathy for your co-workers, have empathy for your peers, Shimel says. Don’t think that because you’re a developer, what you do is more important than what you do as an operator. When a qa colleague says, “Oh my God, I’m afraid I’ll lose my job because we automated the one I tested,” don’t say, “Oh my God, that’s too bad. Don’t worry, you’ll find another job.” Your co-worker is a person with children and a spouse. Empathize with their feelings. Commiserate with safe colleagues. Safe colleagues just say “no,” right? That’s what they know. Leave them alone. So in 2017, empathize with your colleagues and put yourself in their shoes. Trying to make everything work.
Stroud would like to see the culture of collaboration continue to evolve: strategy making without execution is a waste of time. We have to do it. We must be prepared to fail. We must be ready to come and share our experience. It’s all part of a good culture, and we need to put that culture into practice. Let’s put our bets on the ground and go for it. I also like the idea of collaboration. Based on what we learned at the DevOps Enterprise Summit, the culture in a DevOps environment is community, sharing, connecting with people. I’ve been in the business a long time, and I haven’t seen a lot of collaborative culture. I want to continue to encourage collaboration. As DevOps goes mainstream, we remove the term, it will become a training course, we will all become DevOps masters, and let’s not lose the collaborative culture we already have.
Forsgren says evaluation is key: getting better step by step – your experimentation, tactics to achieve your strategy, and your leadership to support your business goals. You won’t know how well you’re doing unless you have good metrics to tell you whether each small step is working. So that would be my goal, for all of us to think about how to evaluate intelligently, so that we can do small experiments that allow for failure, because big failures are terrible, but those are the ones that we can evaluate in a poor way. When you have a big failure, you know you have a big failure.
Check out the full special!