devopsy.kinsta.cloud

Tag: culture

DevOps Chat: ‘Day 2 DevOps’ with IBM’s Eric Minick

Now that the concept of DevOps has been around for a few years and more organizations have embraced it, the natural question for many is, “What now?”—especially considering DevOps success is measured by different yardsticks. IBM’s Eric Minick is has been grappling with the concept of “Day 2 DevOps”—enterprisewide rollouts, multiple toolchains, etc.—and the best way to get organizations from point A to point B.

In this DevOps Chat, we discuss Day 2 DevOps and what IBM is doing in the tool space to help organizations move forward, as well as what other projects Eric and his group are working on.

As usual, the streaming audio is immediately below, followed by the transcript of our conversation.

Alan Shimel: Hey everyone, it’s Alan Shimel devopsy.kinsta.cloud and you’re listening to another DevOps chat. This episode of DevOps chat features a friend of devopsy.kinsta.cloud, frequent contributor, author, podcast guest – none other than Eric Minick of IBM and UrbanCode. Eric, welcome to DevOps chat.

Eric Minick: Hey, it’s good to be with you Alan as always.

Shimel: Fantastic. So, Eric, you’ve been with UrbanCode since like about 2008 but your role has changed a little bit. What exactly is kind of the title role these days?

Minick: Yeah, I’m looking after product management responsibility across the UrbanCode portfolio as well as rational testing. So have just a wonderful team and boy we’re doing some good things, so having fun.

Shimel: Very cool. So Eric we only have 15, 20 minutes here – I wanted to jump right into a couple of topics I want to talk. The first thing that I wanted to bring up was this concept of like a Day 2 DevOps as you call it or DevOps Day 2. Let’s explore that. First let’s tell our audience what do you mean by that?

Minick: I think, you know, we look at how things were a couple years ago and there were a lot of organizations running their DevOps pilots, trying to figure out, “Is this going to work for us?” and all that sort of stuff. But I think we know it works, don’t we, by this point?

Shimel: Well, I hope so but we’ll just keep publishing on it until everyone finally agrees, but yes, you’re right.

Minick: So I think people are looking at like, “All right, I’ve got little pockets of DevOps here, some DevOps teams over there. How am I going to roll this out across my enterprise? I think we’ve got good stuff here, how are we going to do it at scale?” So there’s some scalability challenges, there’s also, you know in organization that had some really good ground-up work – like you have a couple of different teams who built stuff ground up and then they look across the way and they’re using totally different toolchains.

And then you’ve got some poor guy who’s been dubbed the VP of DevOps and is being asking, “Well, how’s the DevOps going?” And so it kind of makes sense out of teams that are on different toolchains and try to pull data out of that, get new teams onto maybe one or both or some other toolchain. And so the scaling and trying to reconcile across all these different tools seems to be the challenge of the hour.

Shimel: Yeah, I do agree. You know Eric it’s funny you mentioned this whole thing like “Can we agree it works?” and what have you because you, like me, we probably live in a little bit of a DevOps bubble where we’re not really talking to companies who either haven’t already started their DevOps journey or are contemplating starting their DevOps journey. But there are people outside of our bubble, right?

Minick: There are. I think I saw one of the analysts who just said, “Yeah, but it’s,” – 40 percent are well on their way through their journey; 40 percent are seriously kicking it off now; and then there’s 20 percent– I spoke to a different analyst who said, “Yeah, I just think that 20 percent is just going to go out of business.” And you saw my article the other day: I agree.

So yeah, if you’re not at least getting ready to start the journey – well, I guess I should just say I’m really worried about you. I was going to say I’m not that worried about you but it’s go time.

Shimel: Yeah, it is, no doubt about it. So Eric for those folks who are sort of entering day 2 of DevOps – and I think this is a problem, so many people prepare for that D Day assault of day 1 and don’t really have the day 2 plan in place. What words of sage advice do we have for them? Where can they go to get information on this? What can they do?

Minick: So I think it’s really important not to disrupt what’s working. If you’ve got teams that are out on some weird toolchain that’s not the enterprise standard but it’s really, really working: let them run. I think that sort of data has come out – we saw in the Accelerate book by ______ it all that, yeah, you want to empower teams, you want to let them run with good tool chains that are working – the ones that are – hey, this is why I have a very active tools business – this is replacing tools that don’t work with tools that work really well or helping teams that don’t have good automation capabilities around continuous delivery or testing.

But then I think you’ve got to really look at, “How am I going to get a view across what’s going on? How do I normalize some data?” If we know that the key metrics for DevOps are things like lead time from code to production – all right, “How am I going to understand that across a number of tools and normalize that?”

So it’s an area we’ve been doing a lot of work on in the tool space – and some other folks are doing that as well – it’s pretty achievable these days.

Shimel: Agreed. So I guess when we start talking about issues around – and blueprints and plans for day 2 – the logical next step is, “What about day 3?”

Minick: Well, let’s see what breaks in day 2 first. I don’t know it yet. I guess my dream, right – if day 1 is you have a bunch of DevOps pilot projects and day 2 is you hire a VP of DevOps to spread these new ways of working across your enterprise – day 3 is you don’t need that VP anymore, right – that you’re dedicated – you know, we bring the DevOps group within your organization – isn’t needed because your transformation is complete, you’re an agile technology powerhouse within your business helping the business along – you don’t need that transformation team anymore; this is just the way that you work.

So I’m hoping that’s day 3 – that all these people do transformations and move onto the next big thing.

Shimel: Fair enough. You know I’m hoping so too Eric, though I hope that doesn’t put me out of a job. Anyway –

Minick: I think we’ve got a decade or two, man.

Shimel: Yeah, I think I’ve got enough runway. So Eric let’s turn from DevOps day 2 and DevOps day 3 to what’s going on specifically with UrbanCode. You’ve got some new releases out both community and enterprise or commercial editions, so what’s up?

Minick: Yeah. So UrbanCode Velocities are kind of a brand new star. So we shipped a community edition earlier this yar and then in the last little bit we came out with the full commercial edition. And I mentioned earlier there’s tools that pull together data from different tool chains – yep, that’s where we’re running with Velocity – you know, looking at things like a lot of our customers have anUrbanCode Deploy for a huge chunk of their workload and they’ve got some teams doing something else – oftentimes it’s simpler apps, they’re running it just on a Jenkins pipeline or something – and they want a view across that.

Very often they need to coordinate a delivery across the two where, “Hey, I need to kick this thing to Jenkins and that thing and maybe they could deploy at the same time.” So we want to make sure that you’ve got a common view of what’s in your test environment even if different pieces and parts of your application are being delivered by different tools, and that you’re able to understand things like lead time, cycle time, deployment success rates – kind of the heartbeat pulse/health of your continuous delivery flow.

So really excited about Velocity. It’s in this brand new market space. Some people are calling it Value Stream Management, others are calling it DevOps Tool Chain Orchestration – but it gets into this idea that lots of people are using lots of different tools to get value out the door as part of your organization, and having a view across that and a way to kind of orchestrate across that is really powerful.

So yeah, people are checking it out, they’re loving it – it’s a ton of fun – the funnest time in a product manager’s life is launching that new product, so good times.

Shimel: Absolutely. So in a way though this kind of goes back to Urbancode’s roots, right, with UrbanCode’s roots in open source and free software, commercial editions and all that – nostalgia Eric in that or lessons learned doing it better?

Minick: Yeah. I think a little better. We did start out with good old Ant Hill as an open source product – you know, to have a community edition and just say, “Yeah, here’s what you get for free,” which is really a lot of reporting right now for UrbanCode Deploy, “And here’s what you get when you step up,” that feels good and a lot cleaner than the press but – you know, we had tried 15 years ago and we tried to build an open source business.

Shimel: No doubt about it. Eric, then you have another version of UrbanCode out – was it 7 or something?

Minick: Yeah, we shipped 7.0 for UrbanCode Deploy – and that’s a big deal for us. You know UrbanCode Deploy started at like 4 so 7 is not – you know, we do big, chunky versions for this – 6 came out a few years ago.

So what got us over to a 7 is some re-architecture under the hood – that’s getting us up from being able to manage in the neighborhood of 10,000 machines on a master cluster of UrbanCode Deploy to being able to deploy to something closer to 100,000. So often 10X is a pretty good improvement.

Shimel: Not too shabby.

Minick: Not too shabby. And you know that’s where we’re ______ of the day 2, right? You know, when we were shipping this thing five years ago we asked clients, “Well, what’s the most you’d anticipate ever deploying to?” and they’d say, “I don’t know, a couple thousand machines might be appropriate for this.” But now you walk into a bank and they’ve got 100,000 VMs under management and they want to get to all of it – they want to scale.

And so I guess the two sides of the coin here – so UrbanCode Deploy saying, “Hey, if you’ve got something that works in UrbanCode Deploy and you want it everywhere in your organization we’re going to make sure there aren’t barriers to that,” right? Big emphasis on that.

All right, if you’ve got a little of everything and you want to make sense of that we don’t want to tell you you’ve got to throw it all out and adopt UrbanCode Deploy: we want to bring in something like Velocity and say, “All right. You’ve got a mess. You’ve got 97 instances of Jenkins with 50,000 jobs across them. Let’s bring some order to that chaos. Let’s give you a view across that. Let’s help you orchestrate across that.”

So that’s kind of the two sides to the day 2 coin from our perspective. A bunch of good stuff in Deploy 7 so it’s not just the scalability we redid the UI to make it a little easier to work with, a little cleaner – I think it’s really beautiful.

You know, we made it easier to kind of manage your processes – your automation processes that could easily be shared across a bunch of different applications. It lets you kind of change them in a little sandbox and code review them and then publish them out to all of those applications that share them – we’re calling that a safe edit capability – we’ve added a graphical designer for Terraformdocuments – so you want to describe how you’re going to publish out your workload we’ll do that nicely with Terraform.

So just a ton of great stuff in there. Big emphasis on helping our customers scale really cleanly and then making sure we pick up all those new tech stocks like Terraform.

Shimel: Got it. Cool stuff. So Eric we continue to see IBM moving forward with UrbanCode and obviously you’ve spoken a lot about a lot of the big developments there within the context of the continuing maturation of DevOps. But you mentioned that you’re also doing or helping to manage some of the testing and – I’m drawing a blank now –

Minick: Yeah. So testing and service virtualization – so rational test workbench, rational –

Shimel: Rational. Excuse me. That’s what I was thinking of. I apologize.

Minick: Yeah.

Shimel: You know, we only have a minute or two but give us a little update on that.

Minick: We’ve been doing a lot of good stuff, expanding some integrations for mobile testing. The service virtualization is always really nice particularly – you know, we’ve got a lot of customers trying to modernize their apps – they say, “Okay, I’ve got some big workload. I like to bring it over to Kubernetes, containerize it,” and then you’ve got like the one thing that doesn’t fit in a container – some crummy appliance from a vendor or – maybe it’s your mainframe that’s part of the app – and so service virtualization is really having a good day to say, “Okay, we’re going to stub out, we’re going to virtualize out,” you know this thing that’s holding you back from being able to really leverage cloud or dynamic infrastructure, and then you’re going to – you’ll be able to leverage it into all these lower test environments – we’ll bring that component back in for late testing – and obviously it’s there in production.

So yeah, the test area is really dynamic. A lot of fun. I’m surrounded by a bunch of great people in that area too. So, yeah, it’s a lot of fun.

And I’d say how I look at it is the build/deploy automation you have in something like UrbanCode that’s the skeleton for your continuous delivery – that’s not the path. All the work you do is testing, right? You’re doing performance testing and security testing and functional testing and API testing and unit testing – we could go on for hours – and so these things come together to really be the heartbeat of your continuous delivery.

Shimel: Cool. Well, Eric it seems like you know you’re certainly busy enough, huh?

Minick: Not bored.

Shimel: Absolutely, man. Hey, we’re about out of time here but I wanted to thank you for joining us today and we’ll have you back on soon – we’ll probably be ramping up for IBM Think in San Francisco in a couple months so maybe before then we can catch up.

Minick: Absolutely. I’m going through session proposals now. I’m super excited.

Shimel: Cool beans. Eric Minick always a pleasure to have you here on DevOps chat. Thanks for the updates and keep doing what you do, man, it’s great.

Minick: Cheers Alan.

Shimel: All right. That was Eric Minick, UrbanCode and IBM Rational. And this is Alan Shimel of devopsy.kinsta.cloud. You just listened to another DevOps chat. Have a great day everyone.

— Alan Shimel

September 18, 2018
Revisiting My Bet on DevOps
On Dec. 29, 2015, I bought some stock. It was a bet on DevOps that my wife kindly tolerated. Since then, the S&P 500 has risen 31 percent and my DevOps portfolio is up 113 percent. This blog is a retrospective on a bet that worked out.

I was inspired by Nicole Forsgren’s talks and the “State of DevOps Report,” whose data showed better profitability, market share and stock price performance among companies claiming to do DevOps well. DevOps, after all, exists to help the business win, and as digital transformation sweeps industry after industry, technologists increasingly are in a position to make that difference.

My process has been very, very simple: Companies whose talks at DevOps conferences convincingly convey a passion for DevOps are ones that I would consider buying. Would I do deep research on each one? Nah—whatever I could research aside from DevOps would already be priced in by people who understood that content better than me.

At the one-year mark, I summarized the results. The crazy project was up 12 percent against an S&P that was up 8 percent—a nice little win. The first six months of 2018 have been tremendous, though: The S&P is up almost 2 percent and the portfolio is up 42 percent.

A key disclaimer is that I am trying to read corporate culture from the outside. For insiders, I am sure I will have some of this comically wrong.

Remixing the Strategy (and Portfolio)

Over the past year and half, I’ve made a handful of trades based mostly on two triggers.

The first trigger is a signal that a company is losing its commitment to DevOps. I did this with Nordstrom: Its DevOps leaders all moved on to different companies. For example, Courtney Kissler went to Starbucks and Suzanne Conniff was off to T-Mobile. About the same time at a meetup, a Nordstrom employee told me that DevOps had fizzled. I was out. In the last year, Nordstrom is up 7.5 percent while retailers I kept are up: Target 46 percent and Amazon 74 percent. That said, Target is a bit of a difficult case.

The second trigger is silos. I worry about an either IT-centric view of DevOps or DevOps in just a small slice of the business. Before I invest in a new stock, I want to know the transformation is taking root enterprise-wide.

Barclays for Bank of America is an example of chasing the all-in company that didn’t work out: negative 8 percent growth versus 25 percent at BoA. Overall though, shifting toward all-in and unicorns has been solid.

Who’s in Today
- Amazon: 121 percent
- Barclays: -15 percent
- Capital One: 26 percent
- Cisco Systems: 52 percent
- Etsy: 340 percent
- Live Nation: 93 percent
- Netflix: 235 percent
- Nike: 20 percent (since December 2017)
- Target: 0 percent
Amazon: Amazon’s net gain at 121 percent looks a lot like the portfolio as a whole (113 percent). The shares I purchased in 2015 are up 150 percent. The company is a natural fit, given that its CEO wrote the “two pizza rule” and demands microservices. It is also a hedge, as the company directly competes with much of this list including Target, Netflix and Etsy. With cloud and DevOps often joined at the hip, Amazon’s cloud revenue is also a rough proxy for DevOps growing overall.

Barclays: Did I invest in a British bank shortly after the Brexit vote? Yeah. It was a bit of a test of the “Everything except DevOps is already priced in” rule. This one hasn’t panned out, but from the outside Barclays is among the banks doing best at DevOps.

Capital One: Has performed about average among banks that I looked at this morning. I adore its start-up attitude and how the company goes about getting talent and contributing to the community.

Cisco Systems: Cisco has had some great talks and is undergoing a digital transformation of sorts of its own. The company is doing fine.

Etsy: Holy cow, Etsy. Etsy is an interesting case in that it has been a DevOps darling for many years. With the stock flagging a bit, the CEO and the CTO (our DevOps hero, John Allspaw) were shown the door and the perception was the grown-up business types were taking over. I increased my bet based on the thought that technical foundations pointed ruthlessly at business problems might work out. When the stock price doubled, I cashed out my original investment.

I’d be better off had I not sold any, but with as volatile as Etsy is, I was happy to route some of the winnings over to a bet on Nike.

Live Nation: I saw a great talk from a Live Nation guy at DevOpsDays Rockies, and the company’s stock has paid off nicely since, nearly doubling. Live Nation gets it, and shows a passion for satisfying customers. Being Ticketmaster, it has had a risk of digital disruption knocking it down for years and has built up a strong innovation capacity—exactly what incumbents need to do.

Netflix: DevOps skills? Check. Good at using data to delight customers? Check. Worth twice what I bought them for? Check. I wrote most of this analysis in early July. Since then, Netflix has had a bad earnings call. It’s still a massive winner so far.

Nike: I loved Nike’s talk at DOES 2017. But what really struck me was DOES London. In the morning the company spoke about a one-team culture and engaging digitally—good stuff. In the evening a colleague complained his kid was spending $200 on sneakers. A week later, Nike’s stock spiked 10 percent. Yup.

Target: Oh, Target. Target has done some great DevOps work, but word on the street is that too much of what it did at first lacked a connection back to the business. However, since the security fiasco with stolen credit cards, that has turned around. While its stock is right around where I bought it 2.5 years ago, the last year has shown strong momentum: Target is up 45 percent in the last 12 months.

2018 Has Been Great

Over the project’s first two years, I had a nagging worry: I was beating the market, but was I just picking riskier stocks and being rewarded in a bull market? So far the market has been flat in 2018, showing modest 1.7 percent growth through June 30. The DevOps Portfolio, however, is up 42.2 percent.

Only the banks are trailing the S&P.

So What Have We Learned?
- It’s about customers and the business: There appears to be a moment of DevOps backlash when alignment to business outcomes isn’t quite strong enough. When the DevOps culture is strong but redirected back to catering to the business, things can go better. That’s one way to read Target and Etsy’s recent performance. When the transformation fizzles … see you, Nordstrom.
- Banks may be different: This system really hasn’t worked out terribly well for me in the banking space. I suspect that is because most banks are undergoing similar transformations and may not be as able to differentiate as retailers do. At DOES London we heard similar stories from RBS and Barclays while Lloyd’s is winning DevOps awards at other conferences. I also lacked representation from the digital disruptors—PayPal would have been a good balance to CapOne or Barclays.
- DORA should be a hedge fund: I hope they have a secret one.
I’m thankful my that my wife was on board with this little project and I’m very happy that we can take our winnings here as we plot our second honeymoon.

Of course, professionally I’ve been betting on DevOps a long time, working on UrbanCode continuous delivery tools the last 15 years. That worked out with an acquisition by IBM as it beefed up its DevOps solutions portfolio.

— Eric Minick
August 9, 2018
9 Ways DevOps Success or Failure Is Like Baseball

The baseball season is in full swing. There are 30 major league teams competing for a playoff spot, but, as I write this, only five of them—or 16.67 percent—qualify as elite performers with a winning percentage over .600.

The number is strikingly similar in DevOps, where, according to one survey, just 17 percent of organizations say they have fully embraced it. Most of the rest have only scattershot teams immersed in DevOps or only recently began adopting it company wide. Fifteen percent are saying, “Wait ’til next year” and have yet to undertake this agile methodology.

In baseball, teams struggle because of weak hitting, lousy pitching, poor defense, inept managing or all of the above. But why do some DevOps initiatives fail, who is at fault and what can be done to right the ship?

Baseball and DevOps: More Similarities Than Differences

Let’s dissect the differences between a DevOps program that hits the ball out of the park with a truly collaborative effort to build, test and release software faster and more reliably, and one that swings and misses.

Is It Understood There’s No “I” in Team?

Most DevOps initiatives fail because they are undertaken by a single practitioner within a single team. This is a strong personality who bulldozes the team to DevOps success, either out of career growth ambitions or genuine belief in DevOps tenets, only to have the team revert to their old ways when the practitioner leaves.

Ironically, many if not most successful DevOps initiatives also begin with a practitioner on a single team. The difference in the latter case is that the leader doesn’t operate in a vacuum but shares lessons and best practices across the organization. They understand that if you are going to do something transformational, you cannot do it in the shadows or within a silo. They consider the long term. They lead by example and demonstrate the way forward to others.

Are the Top Leaders Onboard?

Just as the best baseball teams tend to have smart, supportive, quality-minded owners, the most successful and sustainable DevOps initiatives have top-down leadership support or mandates.

Clear, consistent direction from the C-suite is necessary to motivate and incentivize people across the company and move DevOps initiatives from a patchwork of projects to an organizationwide philosophy.

“Without executive support,” a Forrester report warns, “agile transformation is limited to grassroots initiatives—a very slow and difficult road.”

Are the Danger Signs Recognized?

There are two telltale signs that a companywide program is floundering. One, success is occurring only in a single team. Two, no one outside the team knows much or anything about that success. DevOps can’t grow within an organization if it’s an isolated black box.

Starting DevOps is kind of like an entrepreneurial act. Startups become something bigger when the entrepreneur is successfully able to extend their vision. DevOps is the same: You need to infect other teams with your success. Winning begets winning.

Another indicator of failure is if a company claims to be adopting DevOps but clings to traditionally organized and siloed teams. You can’t have it both ways. DevOps personnel need to be aligned by product, outcome or value stream—not by specialized work function.

Is Success Measured?

How does a baseball team know it’s winning the game if no one is keeping score? Same in DevOps. If you can’t objectively measure success, you don’t know if your program is meeting its goal of accelerating the software life cycle.

Figure out how to measure the value of what is being done and delivered now so you can demonstrate its impact objectively. Examples could be application deployment frequency and time, error rates and mean time to detection.

Is Seeking Outside Help a No-No?

The DevOps community isn’t especially fond of vendors and consultants, but outside experts can bring fresh perspectives. No one tries to cure an infection or solve marriage issues by themselves, and solving DevOps challenges should be no different. Don’t be afraid to ask for help and if you have the budget pay of it.

Can the DevOps Advocates Speak Business Language?

DevOps folks often stumble when pitching for leadership support because they are unable to articulate their proposals in the dollars and cents language that business leaders understand. But if they can talk that way, practitioners may find leaders are much more willing to play ball than they realize.

Is the Blame Game in Fashion?

The biggest mistake organizations can make is bearing the classic IT coat of arms: arms crossed and fingers pointing. Don’t fall into the blaming trap. DevOps, after all, espouses the concept of learning from failure. So instead of pointing fingers, evaluate, consider, learn and move on with the lessons learned.

As legendary New York Yankess manager Casey Stengall said, “All blame is a waste of time. No matter how much fault you find with another, and regardless of how much you blame him, it will not change you.”

Does Failure Breed Success?

Not to sound harsh, but if you start an initiative and it fails, it is your fault. Sure, many company cultures aren’t ready for DevOps, but others are succeeding where you have failed. If your team lost the World Series, another team won it. Why? There is always something that can be done differently. Determine what went wrong, accept responsibility and learn from it.

Do People Bounce Back?

If your initiative wasn’t successful, don’t be discouraged. Pick yourself up and try again. Being a DevOps leader requires courage and persistence. You’ll get ‘em next time.

“Every day is a new opportunity,” Hall of Fame pitcher Bob Feller said. “You can build on yesterday’s success or put its failures behind and start over again.”

— Scott Willson

July 27, 2018
Successfully Integrating DevOps while Deploying Cloud Applications

Transforming to a high-performance DevOps environment can provide competitive advantages, but it requires change—and that doesn’t come easily to most organizations. DevOps requires cultural changes that are inherent to automating previously manual tasks: They are perhaps intimidating to those involved and they require flexibility and enterprisewide buy-in to get right. Furthering these people-side transformational complications are cloud application deployments, creating a need for enterprises to deliver innovative technologies and services with greater speed and quality—without hits to reliability and security.

DevOps Blended with AWS Proficiency

One approach to this problem is blending DevOps knowledge and Amazon Web Services (AWS) proficiency to guide development teams to better align the people, processes and technology needed to facilitate successful cloud initiatives.

In transitioning to a more modern, DevOps-driven approach, companies often encounter a number of challenges, on both a technological and cultural level. The most successfully integrated DevOps occurs as a function of value analysis and process overview, addressing the individual needs of an enterprise rather than fitting them into a preset mold.

Implemented correctly, DevOps blended with AWS proficiency allows organizations to maintain quality and configuration of their infrastructure environments, allowing application development teams to retain control over their processes and toolsets. AWS also allows the enterprise to maintain security: Rather than protocols that are standalone, they’re built into IT processes from the beginning, allowing customization with ease.

AWS understands what is important to its partners when building tools, successfully addressing needs while staying ahead of the demand and, in turn, saving time. They accelerate the ability to deliver and allow an enterprise to focus on what’s most important during their journey to the cloud: value analysis.

Fundamentally Designed to Refine Business Processes

It is very important to approach projects first from a top-level view: Where does this piece of work fit into my broader organization?

DevOps at its core is fundamentally about incorporating different disciplines of a business to create better practices than what are already in place. When an enterprise chooses to implement automation, it typically gains a better view of its business as a whole, incrementally increasing awareness at a birds-eye level. When complex business functions and operations are laid out in more mathematical terms and formulas, it suddenly becomes clear where applying automation can reduce waste.

Getting these changes implemented quickly and with as little effort as possible naturally leads to successful automation. Enterprises remove such tasks that traditionally required an excess in resources by asking, “What value doe this process add? Is there a more efficient alternative?” With automation, these useless business practices are eliminated, freeing resources for more important initiatives.

Increase Employee Awareness, Increase Productivity

One of the most important parts of the entire DevOps integration process is ensuring that everyone understands each other and their role. Properly embraced, a DevOps culture will be characterized by increased collaboration, shared responsibility and autonomous teams—leading to improved quality, valued feedback and the end goal of increased automation.

People are naturally resistant to change. Members need to be aware of the business and how they—and will continue to—fit in.

Ultimately, DevOps is not something that can simply be bought. Success during implementation requires the application of technologies, tools and products that are actually a fit between new processes and existing systems.

— Ashley Stovall

July 19, 2018
7 Signs You’re Mastering Continuous Integration
A majority of organizations think they are doing continuous integration (CI), yet when asked if they are following key practices of CI such as running tests to validate every build, many of them aren’t. Ask yourself the following: “Are we building our application with every change, or at least multiple times a day? Do we avoid long running feature branches? Do we prioritize fixing broken builds over committing new changes?” If your answer to any of these questions is “No,” then guess what? You are not truly doing CI—and you’re not alone.

Continuous delivery (CD), a foundation of DevOps, is built on the practices of continuous integration. Accordingly, you have to implement CI properly before you can truly achieve success with CD and DevOps. In other words, you have to crawl before you walk.

Steps to Mastering Continuous Integration

To reach business goals, here are the seven practices organizations must do to master CI:

Automate the Build—the Entire Build—on a Central Server

This seems like an obvious one—and it is. Sure, prior to implementing continuous integration, organizations either build locally on a developer’s desktop, have a build engineer manually integrate code or have to work through a series of fragile, manual steps that are prone to error. But, surprisingly, many organizations that claim to practice CI still get this one wrong.

Simply put, your continuous integration build should run a central shared server, be able to run completely unattended and be automated such that the same input will produce the same, same output every time.

Build as Frequently as Possible

Teams practicing CI build multiple times per day, ideally triggering the build per change on a pull request, merge or commit. Building per commit enables errors to be found as soon as they are introduced and are more easily fixed.

The word “continuous” in continuous integration should be taken as literally as possible. Often times when I ask organizations how frequently they build, the answer is one of the following:
1. We do “push-button” builds, X times per-week
2. We build both every night, and once per week
3. We build once per-day at X time
As you have likely deduced, these are not “continuous” builds. They may be central builds, automated builds or scheduled builds. But those don’t provide the benefit of continuous integration. If a build breaks and you have two days of 30 commits by 10 different developers, you may have to sort through all of that work to figure out and correct the cause of the build. Productivity killed.

Commit or Merge to Mainline Frequently

Teams doing CI are likely committing/merging to trunk or main with every change or at least once a day. If you are maintaining long-running feature branches, for instance, you are not getting the benefit of validating integrated changes frequently. If you branch for a long period, when it is merged, the integration has been delayed and you may be left with conflicts or bugs to fix.

Build Quickly

If you are practicing continuous integration, your build likely completes within 5-10 minutes. If builds take longer (some organizations have five-hour-plus CI builds), not only are you delaying integration and, therefore, valuable feedback, but developers are less likely to commit changes because of the cost to their productivity—or, even worse, they continue to commit against broken code.

Take time to optimize your build and validation time. This may require you to decompose your CI build process to align with components or teams and then validate the entire integrated application as a separate step in the overall development process.

Validate the Build

CI includes validating the changes and resulting built. This kind of testing should be a part of the overall build process. If your only validation is based solely on confirming the software compiles and links, then you are not truly practicing CI. Most teams practicing CI include code scans and unit tests in the CI build.

Validate in a Production-like Environment

Mature CI practitioners ensure consistency between the dev, test and pre-production environments. The most mature are using VMs or containers, service virtualization and other techniques to ensure they are performing validation in a production-like environment and reducing the risk of discovering errors downstream in pre-production or production, well after changes were integrated.

Fix Broken Builds Immediately

As mentioned, it’s critical that teams find and fix issues quickly so that they don’t move downstream. With CI, processes are set up where builds are validated and committed continuously, so if something is problematic, it’s easier to fix. If broken builds are ignored, the issue will be more difficult to find and fix, but worse is the culture it encourages. CI is based on a quality-first approach. If the build breaks,“Stop the line” and fix the build. Everybody will be better for it in the long run.

Don’t Forget About Culture

If an organization can look at these seven signs and say it does all of these things, then it is really doing CI. These may seem simple, but when these principles are combined, the outcome is remarkable.

Organizations that can’t say they follow each of these principles likely will have problems delivering functional builds regularly. The initiative will fail and team members will become frustrated and revert back to their old ways. Not only will there be a process issue, but also a cultural issue—and this is where many organizations get stuck.

Teams must change how they work together and they must also make sure they are aligned in their mindset. CI has many benefits for organizations, but don’t forget that it’s actually designed to embrace failure, not eliminate it. Continuous integration creates a system where developers can fail fast, so they can find and fix errors early and quickly.

Continuous integration is one of the foundational elements to a real DevOps transformation, which everyone knows is a top priority for many businesses today. Getting it right—truly getting it right—is essential to keeping up with modern business needs.

— Brian Dawson
July 18, 2018
Living in a DevOps World, Part 2

Part one of this article focused on some of the more behind-the-scenes benefits of an Agile DevOps approach. In part two the focus turns to some of the other traditional problems that a well-executed DevOps approach can address, and how doing so can benefit an organization in more ways than just a technical perspective.

By way of quick review, DevOps was born out of the Lean and Agile software development methodologies when it became clear that, while those methodologies did indeed speed up the development process, a bottleneck still occurred when push came to shove and new code had to be moved to quality assurance and production environments.

DevOps was created to more seamlessly connect the development and operations processes, making code migration, testing and promotion to production a more efficient process. To accomplish this, the DevOps approach had to find solutions for some of the issues that caused operational delays, and create new ways to organize, implement and continuously optimize the operations process.

Overproduction/Overprocessing

For those who have been in development and/or operations for any length of time, it quickly becomes clear that there is a multitude of operational safety checks that serve to protect a production environment. While that is vitally important, it was also clear that there had grown an “over” problem around many operational procedures, and in many cases that manifested itself in the development process. That includes overproduction, when making or requesting more than was needed from requirements and/or operations perspective to clear arbitrary operations process hurdles.

Alternatively, overprocessing, when development and operations resources do more work (as opposed to just enough, as Lean and Agile would suggest) than required to smooth the transition of code and functions from development to operations. This created waste regarding time, resources and budgets that were not proportional to the benefits derived from following the operations process.

Motion and Transportation

Similarly, DevOps also sought to solve the operational problems of both motion and transportation. That is, the amount of excess work required to deliver new code to meet the operational requirements for code migration. The friction caused by such requirements slowed the motion and momentum of the development process. The same is true of transportation, or the difficulty in moving code between environments such as testing, quality assurance and production.

In both cases, development and project momentum was sacrificed for what often turned out to be a series of artificial hurdles that had long since become less effective or even obsolete parts of the operations process.

Correction and Inventory

In most instances, all of the above resulted in the final maladies of the pre-DevOps development and operational ways. The first was the number of in-flight corrections required when timelines were squeezed, and the rush was on to get to production. Unfortunately, this went hand in hand with the ultimate problem of good code being sacrificed for expedient delivery, often resulting in inadequate functionality, system outages and, in the end, lost market opportunity and revenue.

3 Keys to DevOps Success

Any successful DevOps implementation must address three critical factors in this order: culture, organization and tools.

Culture

It’s critically important to connect an organization’s values to the DevOps process. Valuing quality, timeliness and organizational alignment of goals and objectives is the first step toward DevOps success. Such cultural values translate directly into a DevOps organization.

Providing empowerment and accountability to DevOps team members helps to build ownership among the team, and trust from their customers in the rest of the organization. It also helps to provide a physical environment that fosters collaboration, teamwork and continued learning. Co-working spaces and collaboration tools such as Slack are a good start. Attending external conferences to broaden perspectives and to bring new ideas back to the team is often beneficial. From there, brown bag lunch sessions where ideas and experiences can be shared, frequent post-mortems on implementations to hone best practices, and even internal mini-conferences where several departments come together for a day to discuss DevOps practices are all effective ways to build a strong DevOps culture.

Organization

Any good DevOps organization is two-sided; that is it has to work from the top down and from the bottom up at the same time.

The top-down part is in the ability to “see the system” from a macro level, allowing for process understanding and insights from a business workflow perspective. This helps to identify the pain points and bottlenecks in the current process that can be optimized through the DevOps process.

Once that’s accomplished, the bottom-up work begins. Identifying things such as inconsistencies in code deployment environments that cause delivery issues, elimination of manual and custom built deployment processes and quarantining inefficient and poorly written code until it can be redone or eliminated are all part of optimizing the time, quality, resources and success factors for deploying production systems on schedule. It’s also important here to continually audit the current processes with an eye toward eliminating the processes that are no longer required or useful but have been kept in place out of the fear of “breaking something we don’t understand.” If nobody understands it, then it shouldn’t be in production software.

Automation Tools

The final factor for DevOps success is to have the right toolset.

Communication: Any DevOps team requires the ability to quickly and directly communicate with other team members sans meetings. For this purpose, tools such Slack (real-time chat), Skype (video chat), and Confluence (for storing persistent information) are pretty good options.

Planning, Monitoring & Consistency: For the team’s planning needs, a tool such as Trello that can provide Kanban board functionality is worth a look. For issue tracking and monitoring of any system’s overall health, tools such as Jira and NewRelic respectively provide some good functionality. Likewise, consistency is vital in a DevOps world, and using automation to ensure that all systems are configured as desired across different environments is a crucial best practice. For this, a tool such as Ansible is worth a review.

Integration & Deployment: For continuous integration of systems in development and as a way to tighten the feedback loop for developers to determine if the central build used for deployment to production is working as intended, the Jenkins toolset might be a good fit. And finally, when it comes making any deployment process as painless as possible, a tool such as Docker that can handle created containers for an application that includes all dependencies, reducing the complexity of deployment to multiple environments, is a solid way to go.

The point of all of this is to create an environment—culturally, technically and physically—where DevOps can succeed, grow and thrive. Organizations that can create an effective and efficient DevOps environment have also created a competitive advantage for themselves.

— Dave Farinelli

July 3, 2018
DevOps Adoption: The Driving Force of the Industry
DevOps has transformed from a mere idea on paper to the way processes function in the face of an immediate requirement. Development and Operations together make for one of the most successful collaborations today.

As per a research report, people have now begun to understand what DevOps is. When asked how familiar they were with DevOps, 84 percent of respondents said that they well-versed with the concept, in comparison with 60 percent who agreed to the same the previous year.

DevOps is writing the success stories of the world’s business giants. Facebook, Google, Twitter and Amazon are all working the “DevOps way.” All falls in place when these companies develop, test and successfully deploy code in a matter of one to 23,000 minutes per day. We agree that’s insane!

How Have We Benefited from DevOps Adoption?

To sum up the benefits of DevOps adoption in a nutshell, users see:
- Drastic reduction in lead times—With the pressure to deliver software faster and meet the challenges of the growing market, there is always a need to look at progressive ways of getting the job done, DevOps became the solution. As per statistics, practitioners believe this to be the top benefit of DevOps in 2018. Sixty-nine percent of respondents agreed to this benefit, as compared to 39 percent in 2017.
- Increased ability to release new features with improved reliability stability and security—The need to improve the user experience and keep the customer equipped with the necessary tools to meet the challenges of a growing business made IT personnel realize that it is always essential to introduce new features into the deployment process. DevOps made it easy. Figures tell us that the implementation of DevOps led to 73 percent of people believing in its benefit of enhanced user experience, this year.
- Enhanced IT and Organizational Productivity, Higher Profitability, Revenue and Market Shares—Now with the best process having so much to offer, all businesses have gained a lot in terms of savings and earnings. DevOps drives revenue: 26 percent of people reported an increase in revenue in the year 2018 as compared with 20 percent in 2017.
Why No DevOps?

Although we’ve seen a major shift in trend from being skeptical about DevOps and its implementation to becoming “pro-DevOps,” over the years, not all of us are up for this big business move. The reasons being many.

Listed below are the most commonly given reasons by industrialists around the world:
- Other technology and business priorities—With newer technologies being developed every few weeks, companies are confused over which technology will give their business the required leverage. This leaves them to either becoming very choosy or just ignoring the prospects of adopting a technology at all. Some business owners think about fund allocations. They want to invest their hard-earned money into something they see as more viable or something that convinces them about profits. When it comes to innovative ideas such as DevOps, they think these things may not bring them immediate results or they’re not as important as the “conceived” business priorities. As per a study conducted in February 2018, as much as 38 percent of the sample population opted out of DevOps for the above reason.
- Lack of resources—Most organizations lack the required resources in terms of personnel, tools and persons with expertise. This discourages organizations from taking up such practices. While it is great to have a workforce with work experience for the dev and ops teams individually, it is crucial to have employees with DevOps experience on board. Similarly, lacking the right tools can have your organizations whimpering in the wake of a growing market despite having an able workforce. Statistics show that 34 percent of people hesitate to adopt DevOps for the given reason.
- Lack of cooperation between development and operations—Whenever there is a mention of DevOps, there is also a mention of the cultural indifference of Dev and Ops teams. Each team has their unique work culture and when they come together on common ground, they cannot help but fall apart. Most organizations do not encourage the DevOps practice on account of this cultural disparity.A significant 22 percent of the industries under this research shun the idea of DevOps owing to this disparity.
- ‘We don’t see the value’—It is likely for some business to say this. It is difficult to assess the value of the process from an outsider point of view. If someone has heard about DevOps but don’t how it will profit their businesses, then it is difficult for them to adopt it. As per statistics as small as 6 percent of the sample population did not adopt DevOps for this reason.
On an End Note

Organizations have been opting for DevOps after seeing its contributions to the industry. This year has most businesses functioning with major dependence on the skill and agility of the DevOps processes, and this has been proven through the success of their business. We hope the remaining number of entrepreneurs come to realize the importance of DevOps for their business and implement its benefits to build their success and keep up with the challenges of the fast-growing market.

— Veritis
July 2, 2018
Integrating Blockchain and DevOps

Blockchain is one of today’s hottest technology buzzwords. And at the same time, the concept of DevOps has achieved acceptance and is gaining momentum. Blockchain and DevOps already offer a number of benefits individually. Together, they can provide significant tactical and strategic advantages. However, some challenges must be overcome simply to adopt blockchain, as well as to successfully merge blockchain and DevOps.

What is Blockchain?

Let’s start with an overview of blockchain. Many people mistakenly conflate cryptocurrency and blockchain, because many of the key features of cryptocurrency are a function of blockchain. But blockchain is a separate and unique concept that has applications and benefits far beyond cryptocurrency.

Blockchain is a distributed account ledger, the use of which enables data to be processed and stored securely. Blockchain relies on three core concepts—peer-to-peer networks, public-key cryptography and distributed consensus that is based on the resolution of a random mathematical challenge. Reliance on these three concepts allows blockchain transactions to be secure and relatively anonymous. Every transaction is recorded in the ledger as a data block that is appended to the end of the chain of previous transactions. No group or individual owns or controls the ledger, and all parties can view the chain of transactions, ensuring transparency and integrity.

A number of key features make blockchain attractive. Data is validated across all participating nodes, which eliminates the need to reconcile transactions. The use of distributed consensus provides a high degree of confidence, but transactions in the chain also can be verified easily. Blockchains are immutable—new data can be appended, but blocks of data already in the chain cannot be modified or removed. Finally, blockchain reduces costs and improves the efficiency of processing transactions and storing data due to its decentralized architecture.

The challenge facing organizations wanting to adopt blockchain, however, is how to incorporate it seamlessly with DevOps development processes and culture.

DevOps for Blockchain Development

Organizations need to address challenges in three major areas to take advantage of blockchain: culture, process and tools.

On the culture front, the success of blockchain depends on support at the executive level as well as adequate budget and resources for proper implementation. If you can’t find champions within the organization to drive the blockchain cause, your project is doomed before it starts.

Whether you’re building a blockchain within a single company or a blockchain network that includes nodes outside your organization, obtaining widespread agreement on the technology and blockchain processes can be an issue. The absence of widespread industry adoption or any sort of standardized tools or processes adds complexity.

Finding the right talent can also be a problem—and once you find it, you may have to pay a premium to obtain it. According to a recent article in TechCrunch, “Blockchain-related jobs are the second-fastest growing in today’s labor market; there are now 14 job openings for every one blockchain developer.”

From a process perspective, blockchain is an emerging concept that lacks mature management principles or design standards. The process framework, and the different roles involved, are still unclear. Most organizations lack expertise concerning the blockchain application stack and environment; in addition, the metrics that should be monitored to measure efficiency and performance are not yet well-defined.

The absence of development tools is another major hurdle for blockchain. The developer tools currently available for the blockchain ecosystem are unreliable. The blockchain ecosystem still needs an integrated development environment with good linters and plug-ins, a build tool and compiler, a deployment tool, documentation, testing frameworks, debugging tools, logging tools, security auditing and analytics. While some versions of these tools exist, they are not yet adequate to meet the needs of blockchain developers.

It is also important to understand that, although many blockchain implementations are based on open source technology, blockchain isn’t free. Keeping track of transactions requires hardware, networking bandwidth, electricity and processing power. Because a blockchain ledger is distributed, transactions aren’t just processed once—they are processed on every node in the blockchain network. As a trusted network grows, the associated costs skyrocket. These expenses can be a barrier that prevents smaller organizations from experimenting with the technology.

Integrating Security into DevOps

If you are thinking about implementing blockchain, some of the core principles of DevOps—specifically DevSecOps—come in handy. DevOps is built on the concept of breaking down silos within an organization and enabling each team and individual to take responsibility for the project as a whole, rather than separating tasks by role.

To implement blockchain successfully, you need a system that rewards innovation and supports teams of individuals who work together to address any issues. Integrating DevOps and security fosters stronger application security throughout the software development life cycle and helps with blockchain development efforts as well.

The shift-left philosophy and the push for automation are DevOps principles that also will serve you well with blockchain. Integrating security earlier in the life cycle—shifting left—and incorporating automated security testing and security bug tracking are essential. The blockchain network needs to be tested for performance and latency, which will vary depending on the size of the network, the expected transaction size, the consensus protocol used and the associated required latencies. It is also important to determine whether the integrity of the network and the shared blockchain ledger is maintained while testing throughput.

To maximize efficiency and productivity, put processes in place that allow you to consistently monitor and adjust, based on feedback. Track individual and overall security vulnerabilities, the amount of time it takes to detect them, the amount of time it takes to remediate them, and other factors relevant to application security. These metrics should be visible to every individual so that each can understand and take ownership of the appropriate elements.

Blockchain and DevOps

Blockchain technology is poised to change the way business is conducted today due to its promises such as of secure, immutable, peer-to-peer decentralized trust networks with distributed consensus, shared account ledgers and smart contracts.

These same advantages, however, introduce a host of additional considerations to blockchain-based applications and make for greater testing challenges. Not only is the change in technology significant, significant changes are also necessary from a business process standpoint. While blockchain applications will have to go through standard testing and validation, including functional testing, integration testing, security testing and performance testing, they also will require additional specialized testing for smart contracts and peer/node testing.

DevOps practices can provide great value to organizations under pressure to become more customer-centric and innovation-focused. The efficiency, quality and consistency that adopting DevOps provides is exactly what is required for traditional organizations looking to embrace the leading-edge technology known as blockchain.

— Tej Aulakh

June 25, 2018
How to Cultivate a Loyal Developer Community

With the number of developer focused companies and products growing, building communities among engineers has become a key strategy to stay competitive. Augmenting and often surpassing traditional marketing techniques, this approach—although challenging—can be an incredibly effective way to engage users and get engineers excited about a product.

Since our inception over six years ago, DigitalOcean has worked to establish a robust developer community around our product through a variety of channels. This includes our public open-source focused Community, which attracts more than 3 million monthly visitors.

It Takes a Village to Make a Community

Beyond creating a product developers love (that always comes first), here are some best practices and lessons we’ve learned for cultivating a great developer community.

Develop Personal Relationships

A community implies connection, so first, look for ways to form connections directly and show people you care. In its early days, Twilio did a great job at getting out of the office and doing meetups to speak to devs directly, and I would argue this was essential to it becoming as successful as it is today.

This also involves finding ways to shine light on individuals in your community. When we found out one of our community members recently had a baby, we sent them a onesie for their newborn. Chances are, you also have community members who are doing amazing things, and would love the recognition for it—either on social media or your blog.

Taking the time to meet users where they are and working to establish closer relationships with them creates a virtuous cycle: these users help the community grow with their contributions, suggestions and feedback, and therefore feel more empowered to continue to invest in the community. Everyone benefits in this scenario and, equally important, your communication out to the community is genuine because you gain a deeper understanding of exactly who you are talking to and building for.

To that end, it’s important to have someone or a team (for example: developer advocates or community managers) ready to engage directly with your community and bring the lessons back to the company. You’ll want individuals who are capable of responding, both offline and online, in an authentic way.

Create Avenues for Them to do Meaningful Work

While many developers enjoy their work, they often have far-reaching interests beyond code. Companies that find ways to help their communities meld code with what’s important to them personally will see much more stickiness and retention.

For example, developer analyst firm RedMonk has done a good job of creating conferences (MonkiGras and Monktoberfest) that go beyond technical presentations and instead create discussions around issues such as the intersection of society, culture and technology. This provides a forum for the developer community to connect over shared interests and experiences—not just code or languages.

We created a program called Write for DOnations that not only pays contributors for writing technical articles, but also matches this payout with a contribution from us to the author’s choice of tech-focused nonprofits. This not only incentivizes our community to remain active, but makes them feel they’re making a difference. Because we take time to build a relationship with each of our authors, they know that they can help make a regular investment in those organizations.

Make Product Development Decisions a Two-Way Street

If you’re creating products for developers, their needs should be top of mind. Using a product feedback forum allows developers to ask questions and make product requests while giving them a faster feedback loop for their product development. We launched our object storage solution “Spaces” last fall in large part because of the flood of requests we received via our User Voice voting system. We’re not alone by any means in creating two-way streets: GitHub has an extensive forum forum for users to talk about different elements on GitHub and get advice. Stripe allows its community to chat directly with its own devs on Freenode as a way of further fostering their own community.

Providing visibility into your own product road map is also critical — by sharing in advance what you’re planning with your users, you can help them make much smarter long-term decisions.

Meet Them Where They’re At

Connecting with developers in person is incredibly powerful, and meetups are a great avenue for this. However, if geographic barriers arise, broadcasting these meetups live is a nice way to engage people dispersed across multiple locations and ensure they too get value from your meetup programming.

On the more tactical side, sharing swag helps keep your product visible even after the meetup or event has completed. A nice shirt or cute sticker allows your community to feel connected and effectively act as brand ambassadors. We’ve seen this to great effect with our Hacktoberfest effort: After sending t-shirts to individuals helping out with open source projects, we often meet people later at conferences still sporting their well-earned tee.

Building a community takes effort. When beginning to forge one, it is invaluable to consider how your specific audience enjoys connecting and how the company can serve them best. There is no one formula for creating a vibrant, engaged community, but with some experimentation and a lot of listening, you can create something truly special around your product.

— Etel Sverdlov

June 21, 2018
What Comes after DevOps? Two Possibilities

People have been talking about the “post-DevOps” world since at least 2014. But have we actually arrived in the post-DevOps era? If so, what comes after DevOps? Let’s explore those questions.

The DevOps concept is more than a decade old. DevOps has seen widespread adoption across companies large and small. “DevOps engineer” is now a common job title for tech folks.

At a minimum, these developments mean that DevOps is now very mature and mainstream. They may even signal the end of DevOps, depending on your point of view.

Even though DevOps remains a useful concept, the fact that DevOps is now so mature means it is no longer as novel and dynamic as it once was.

That begs the question: What comes after DevOps? I think there are two distinct possibilities.

A Reaction Against DevOps

One possibility is that we’ll see a backlash against DevOps, and an attempt to replace DevOps processes with alternatives that are designed to do the opposite.

Indeed, there has already been a fair amount of outspoken criticism of DevOps for years. It has mostly remained under the surface.

But in an era when almost everyone is doing DevOps, it seems reasonable to expect that some organizations will find it doesn’t solve their problems after all. Those organizations most likely will return to earlier ways of doing things.

In this scenario, DevOps is unlikely to disappear entirely. But we probably would end up in a hybrid world where software delivery teams mix DevOps principles, tools and practices with those from earlier eras.

DevOps-ifying the Whole Organization

The other main possibility for the post-DevOps world is that we’ll see DevOps extended into more and more parts of the business that are not directly related to the two core areas of DevOps practice, development and operations.

This trend has already been playing out to a certain extent for years. Concepts such as DevSecOps (which extends DevOps into the security realm) and DevQAOps (which integrates Quality Assurance with continuous delivery) have been around for at least several years.

Still, there is room for DevOps concepts to establish deeper roots in areas outside of dev and ops. Most organizations could benefit from doing more DevSecOps, for example. And as I’ve written in the past, even PR, legal and other departments could be integrated more tightly into the software delivery process.

To date, few organizations have sought total DevOps-ification by applying DevOps principles to all business units. But this could be the great innovation of the post-DevOps world. If this scenario plays out, DevOps won’t go away; rather, organizations will double- or triple-down on their investment in DevOps.

— Chris Tozzi

June 21, 2018