staging-devopsy.kinsta.cloud

Author: Eric Minick

The Coding Assistant Bottleneck: Applying the 3-Ways
AI coding assistants are the talk of the town, and for good reason. Tools that can turn a comment into a function or autocomplete entire classes are genuinely changing the developer experience. We’re writing more code, faster than ever before. It feels like a massive productivity win.

But is it?

While we’ve supercharged the early step of the software delivery lifecycle (SDLC), writing the code, we’ve left the rest of the pipeline largely untouched. The result is a classic DevOps anti-pattern: a powerful local optimization that creates a systemic dysfunction. More code is being generated, but it’s not necessarily reaching customers faster or more effectively.

This creates a “productivity paradox” where local efficiencies lead to global slowdowns. In fact, recent DORA metrics show that delivery throughput is actually decreasing. A METR randomized trial similarly found that while developers reported productivity gains, they could be slower in completing tasks with AI due to the additional time required for debugging.

To understand why this is happening and what to do about it, we need to go back to basics. We need to look at this new reality through the lens of the Three Ways of DevOps.

The First Way: Flow and the Firehose

The First Way (Flow) is centered on systems thinking. It emphasizes optimizing the performance of the entire value stream — the end-to-end process of delivering value — over the performance of any individual step or stage. As the Theory of Constraints teaches us, any improvement not made at the system’s bottleneck is an illusion.

AI coding assistants accelerate the “Dev” part of that flow. But that firehose of new code now slams into the same CI/CD and testing processes we’ve had for years: the same test suites, security scanners, manual approval gates, and deployment scripts.

The bottleneck isn’t writing code for most teams. It’s deciding whether the code is safe to ship.

We’re seeing a pile-up. Developers spend less time coding and more time waiting and fixing. They wait for slow builds, test results, remediate vulnerabilities, and babysit deployments. We’ve accelerated code generation only to exacerbate the real bottlenecks. We didn’t speed up the system; we just moved the traffic jam further down the road, overwhelming our downstream quality and security processes.

The Second Way: A Muted Feedback Loop

The Second Way is about creating and amplifying fast feedback loops. The goal is to obtain information from the right (Ops, production) and return it to the left (Dev) as quickly as possible. This allows teams to find and fix problems at the source, when they are cheapest to resolve.

The flood of AI-generated code creates a feedback crisis. Traditional, manual feedback mechanisms, such as peer review, simply cannot keep up with the volume. While impressive, these AI tools are far from infallible. One study found that 45% of AI-generated code samples introduced security flaws. Another study found 45% (yes, the same percentage) of all deployments to production linked to AI-generated code led to problems. When a developer gets feedback on a vulnerability days after the code was written, the context is lost, and the cost of remediation skyrockets. Even as coding assistants improve, with more code, there will always be more to review and remediate.

One way to manage this is to fight AI with AI. The feedback on AI-generated code needs to be nearly as fast as the generation itself. This means leveraging a new generation of intelligent tools for automated testing and security analysis that integrate directly into the developer’s workflow. The human reviewer isn’t eliminated. She’s elevated in her role from a line-by-line inspector to a strategic “human-on-the-loop” who validates business logic and architectural intent, work that machines can’t do.

The Third Way: Applying AI to the Entire System

The Third Way focuses on fostering a culture of continual experimentation and learning. The disruption from coding assistants forces us to get serious about this. We must use this moment as a catalyst to measure our systems, sense new bottlenecks, and invest in the technical excellence required to generate the Flow and Feedback that the first two Ways promise.

This starts with honest measurement. We must look beyond vanity metrics like “lines of code” and focus on system-level indicators like cycle time, deployment frequency, and change failure rate. At a more detailed level, where are the new logjams appearing now that code generation is off the leash? The Third Way demands we use data to find and address these constraints.

Once we see the bottlenecks, the next step is a deliberate investment in practices and platforms to keep up. This means embracing intelligent automation for the entire pipeline, including:
- Accelerated Feedback: To handle the volume, builds and tests must be fast and intelligent, to provide feedback in minutes, not hours.
- Automated Safeguards: To handle the risk, deployments must be protected by AI that analyzes production data and can automatically roll back a failing change.
- Embedded Security: To manage the new attack surface, a pipeline-out approach needs to be taken, replacing a security-as-a-silo.
When the entire pipeline can keep up, we achieve the true unlock. The conversation shifts from technical experimentation to business experimentation. An idea can move from conception to production to customer validation quickly and safely.

That’s the real promise of this technological shift, but it’s only available to those who apply the Third Way to the entire system.

Code Was Never the Bottleneck

AI coding assistants are a phenomenal leap forward. But they are not a silver bullet. By focusing on code generation, we’re optimizing a part of the process that, for many organizations, accounts for only about 30% of engineering time.

The real opportunity lies in applying intelligent automation to the other 70%, the complex, toil-filled work of getting good code tested and into production. It’s time to move beyond just AI for coding and embrace AI for delivery. That’s how we’ll truly fulfill the promise of speed, stability, and security.
November 25, 2025
Best of 2024: Policy-as-Code Will Rule Your CD Pipelines

Fear of losing control or being non-compliant has stopped too many DevOps transformations. In most organizations, including all regulated ones, there is a degree of governance required to manage production releases. Policies around releases could include necessary security checks, quality bars, deployment windows or approvals. Compliance with architectural policies and cost impacts may also be relevant for pipelines governing infrastructure changes.

Ensuring these policies are followed can be challenging. As recently as a few years ago, when monthly or quarterly release cycles were the norm, policies could be enforced manually. A release manager would gather evidence of compliance, and an approval group would review the evidence. Only with sufficient compliance would the application be cleared for release.

As we have developed more mature continuous delivery pipelines, our delivery cadence has made manual review of each release untenable. A time-consuming and expensive process may work once a quarter, but when released many times a week, it is not.

Bringing governance to rapidly moving delivery pipelines is familiar. However, it is not something the industry has mastered. We have good guidance from groups such as Capital One around what organizations should do, but scaling and maintaining governance at speed still needs to be improved.

The Challenge of Traditional Pipeline Governance

Bowing to the business need for speed, organizations have used a mesh of overlapping techniques to mitigate the risks the old processes attempted to address. These include:

• Security Training for Developers: If fewer security bugs are written, fewer will escape.
• Automating Checks in Pipelines: Application teams are asked to implement automated security scans and enforce promotion policies in their pipelines based on central standards.
• Code Review: After training developers in security and governance policies, teams can require code review, often through the pull request process, of changes to increase compliance.
• Regular Compliance Reviews: The CAB may be replaced by a governance architecture review that periodically (often quarterly) ensures that the appropriate checks appear in place.

Sadly, this patchwork often fails. For several reasons, but most often pressure from the business to release more, causing developers to start shortcutting checks. After the inevitable incident or failed review, organizations often take regressive steps such as handing control of pipelines to central teams, reducing the autonomy of the application team.

Organizations with this patchwork approach will also need help with challenges arising from gaps between central teams that manage policies and the distributed application teams that need to implement them. Policies are misunderstood, changes are slow to be rolled out and compliance may be uneven.

Governance at Speed Requires More Automation

We need a way for policymakers to apply it across an organization while minimizing the day-to-day impact on innovation and developer productivity. A solution here would have to meet a range of needs:
1. Automated Checks: Policy compliance could be validated in moments, not significantly slowing CD pipelines.
2. Can Centralize Definition: GRC (governance, risk and compliance) teams should be able to define policies.
3. Rapid Rollout: Policy changes should roll across the organization quickly and efficiently.
4. Understandability: Policy authors and application teams governed by policies should be able to understand a policy and its impacts.
5. Maintain App-Team Autonomy: Developers on application teams should be able to make policy-compliant changes to their pipelines without needing help from another team.

These needs, in turn, suggest the characteristics of a solution:
● Operates “On” Not “In” a Pipeline: If policies are defined inside pipelines, it is difficult to give developers autonomy. Further, making policy changes means dozens, hundreds or thousands of pipelines must be updated quickly and faithfully — no easy task. As a result, policy definition and enforcement must exist outside pipelines.
● Automation for GRC Teams: Policy automation must be authored by GRC teams while remaining widely understandable.

Policy-as-Code: The Solution?

With a policy-as-code (PaC) approach, such as using projects like the CNCF’s Open Policy Agent (OPA), GRC and platform teams can establish policies using an accessible DSL (domain-specific language). While a code will be machine-understandable, the DSL elements ensure it will remain human-understandable.

By wrapping a PaC engine around your pipelines, you can ensure policies such as requiring security scans. If the pipeline doesn’t have the scan step, it can be blocked. If a step that compares the results to your policies isn’t present, it can be blocked. The application team remains free to control how their pipelines build and deploy, but if they lack the required checks, they won’t be able to reach production. The application team owns application things, and the GRC team owns GRC things.

Policy-as-Code has Momentum

With PaC projects such as Open Policy Agent (OPA) graduating from the CNCF and an alternative, Kyverno, incubating PaC is moving into the mainstream and beginning to grow in its adoption within DevOps tooling.

Today, we see elements of PaC being adopted by major DevOps platforms:

● Azure DevOps: Azure DevOps Policies have as-code capabilities with a proprietary JSON-based template. Policies can be executed through Powershell so that they can be run through pipelines.
● GitLab: PaC has been introduced for security scans. Policies are defined in proprietary JSON documentation and are executed on merge request events or a schedule.
● Harness: The CNCF project, OPA, powers Harness’s PaC approach. Policies are available across the DevOps platform, from ensuring that security scans are run to requiring greater approvals for infrastructure-as-code executions that increase costs significantly.

Plan Your Use Now

As this approach starts taking hold in the industry, now is the time to learn more about technologies such as the CNCF’s OPA. If you are using tools with PaC, start building some policies, and if not, consider experimenting with those tools. You can find Harness’s free tier if you like OPA. Azure DevOps and GitLab have free offerings if JSON suits you.

December 31, 2024
Policy-as-Code Will Rule Your CD Pipelines

Fear of losing control or being non-compliant has stopped too many DevOps transformations. In most organizations, including all regulated ones, there is a degree of governance required to manage production releases. Policies around releases could include necessary security checks, quality bars, deployment windows or approvals. Compliance with architectural policies and cost impacts may also be relevant for pipelines governing infrastructure changes.

Ensuring these policies are followed can be challenging. As recently as a few years ago, when monthly or quarterly release cycles were the norm, policies could be enforced manually. A release manager would gather evidence of compliance, and an approval group would review the evidence. Only with sufficient compliance would the application be cleared for release.

As we have developed more mature continuous delivery pipelines, our delivery cadence has made manual review of each release untenable. A time-consuming and expensive process may work once a quarter, but when released many times a week, it is not.

Bringing governance to rapidly moving delivery pipelines is familiar. However, it is not something the industry has mastered. We have good guidance from groups such as Capital One around what organizations should do, but scaling and maintaining governance at speed still needs to be improved.

The Challenge of Traditional Pipeline Governance

Bowing to the business need for speed, organizations have used a mesh of overlapping techniques to mitigate the risks the old processes attempted to address. These include:

• Security Training for Developers: If fewer security bugs are written, fewer will escape.
• Automating Checks in Pipelines: Application teams are asked to implement automated security scans and enforce promotion policies in their pipelines based on central standards.
• Code Review: After training developers in security and governance policies, teams can require code review, often through the pull request process, of changes to increase compliance.
• Regular Compliance Reviews: The CAB may be replaced by a governance architecture review that periodically (often quarterly) ensures that the appropriate checks appear in place.

Sadly, this patchwork often fails. For several reasons, but most often pressure from the business to release more, causing developers to start shortcutting checks. After the inevitable incident or failed review, organizations often take regressive steps such as handing control of pipelines to central teams, reducing the autonomy of the application team.

Organizations with this patchwork approach will also need help with challenges arising from gaps between central teams that manage policies and the distributed application teams that need to implement them. Policies are misunderstood, changes are slow to be rolled out and compliance may be uneven.

Governance at Speed Requires More Automation

We need a way for policymakers to apply it across an organization while minimizing the day-to-day impact on innovation and developer productivity. A solution here would have to meet a range of needs:
1. Automated Checks: Policy compliance could be validated in moments, not significantly slowing CD pipelines.
2. Can Centralize Definition: GRC (governance, risk and compliance) teams should be able to define policies.
3. Rapid Rollout: Policy changes should roll across the organization quickly and efficiently.
4. Understandability: Policy authors and application teams governed by policies should be able to understand a policy and its impacts.
5. Maintain App-Team Autonomy: Developers on application teams should be able to make policy-compliant changes to their pipelines without needing help from another team.

These needs, in turn, suggest the characteristics of a solution:
● Operates “On” Not “In” a Pipeline: If policies are defined inside pipelines, it is difficult to give developers autonomy. Further, making policy changes means dozens, hundreds or thousands of pipelines must be updated quickly and faithfully — no easy task. As a result, policy definition and enforcement must exist outside pipelines.
● Automation for GRC Teams: Policy automation must be authored by GRC teams while remaining widely understandable.

Policy-as-Code: The Solution?

With a policy-as-code (PaC) approach, such as using projects like the CNCF’s Open Policy Agent (OPA), GRC and platform teams can establish policies using an accessible DSL (domain-specific language). While a code will be machine-understandable, the DSL elements ensure it will remain human-understandable.

By wrapping a PaC engine around your pipelines, you can ensure policies such as requiring security scans. If the pipeline doesn’t have the scan step, it can be blocked. If a step that compares the results to your policies isn’t present, it can be blocked. The application team remains free to control how their pipelines build and deploy, but if they lack the required checks, they won’t be able to reach production. The application team owns application things, and the GRC team owns GRC things.

Policy-as-Code has Momentum

With PaC projects such as Open Policy Agent (OPA) graduating from the CNCF and an alternative, Kyverno, incubating PaC is moving into the mainstream and beginning to grow in its adoption within DevOps tooling.

Today, we see elements of PaC being adopted by major DevOps platforms:

● Azure DevOps: Azure DevOps Policies have as-code capabilities with a proprietary JSON-based template. Policies can be executed through Powershell so that they can be run through pipelines.
● GitLab: PaC has been introduced for security scans. Policies are defined in proprietary JSON documentation and are executed on merge request events or a schedule.
● Harness: The CNCF project, OPA, powers Harness’s PaC approach. Policies are available across the DevOps platform, from ensuring that security scans are run to requiring greater approvals for infrastructure-as-code executions that increase costs significantly.

Plan Your Use Now

As this approach starts taking hold in the industry, now is the time to learn more about technologies such as the CNCF’s OPA. If you are using tools with PaC, start building some policies, and if not, consider experimenting with those tools. You can find Harness’s free tier if you like OPA. Azure DevOps and GitLab have free offerings if JSON suits you.

June 25, 2024
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
Machine Learning: Essential in Cloud Service Management

As businesses today compete more and more on digital experience, you need to ensure that what’s delivered performs optimally and provides an outstanding customer experience. With increasing complexities, growth and change in your IT infrastructure, you need complete visibility into the performance and availability of IT infrastructure, and also the applications that ride on it. To succeed in this modern domain, your IT operations team needs to be more proactive than reactive.

Proactive operations management have long been a goal of client-centric operations: the ability to avoid issues rather than simply reacting to issues more effectively or more efficiently. It is time traditional IT service management transforms to remain relevant. The good news is that machine learning has advanced to a stage where this is achievable at scale.

Machine learning may have been a distant dream, but not anymore. Almost every system or gadget, whether complex or simple, is getting smarter using basic pattern recognition and computational learning, which is the basis of any machine learning technology. Today, public cloud service providers offer machine learning services that make this technology affordable. So, you are not too far away from making your IT operations management more client-centric.

Machine Learning Meets IT Service Management

Applying cognitive and machine learning capabilities to service management will help accelerate diagnosis of events and patterns, extract deep insights from IT systems and provide early warnings of anomalies that could cause service impact or poor performance.

Machine learning will enable your IT service management to:

Continuously learn: Cognitive service management uses machine learning to learn the behavior of applications and resources and get a true understanding of how it should function normally. With machine learning, you can continuously learn application and infrastructure behavior and then use those insights to set and dynamically manage thresholds for all monitoring data. You can understand the relationships across applications and resources to anticipate service impacts. With these deeper insights, you can quickly and efficiently resolve issues, improve overall operational efficiency and significantly reducing operational costs.

Anticipate and adjust: With every outage is a potential service degradation. This is exactly where machine learning capabilities help proactively detect and avoid, which traditional service management capabilities lack. Insights from recurring anomalies help forecast potential service degradations. This information is used to proactively alert on potential problems so that organizations can adjust to the rapidly changing environments and intelligently prioritize their resolution.

Recommend action: Efficiency is critical when it comes to finding and fixing application and systems problems. A skilled service organization backed with machine learning capabilities helps provide expert advice for taking corrective action and can offer greater service assurance. Applying cognitive capabilities turn terabytes of data captured from their IT infrastructure, into relevant and actionable insights for quicker problem solving and better service.

Because machine learning uses algorithms that can learn by observing data, identifies important patterns in your data and by clustering them, you get to focus on the most urgent issues. It enables you to automatically detect problems and separate real issues from the noise. You gain faster time to resolution for troubleshooting problems that impact service to clients.

To learn more, join us as we present “Cloud Service Management: Why Machine Learning is Now Essential.” During this informative webinar, you’ll learn why IBM believes adaptive automation, delivered through innovative machine learning, is now essential to achieving cloud service management at scale.

— Eric Minick

June 13, 2018
How I Bet on DevOps – and Won
One evening in late 2015, after the kids were in bed, I sat down next to my wife and said, “I’d like to do something irresponsible. I want to gamble some of our savings on DevOps. I’d like to buy some stock.”

Nicole Forsgren’s 2014 presentation, “DevOps and the Bottom Line,” opened my eyes to the business impact of DevOps. Then the 2015 State of DevOps Report rolled out with the following tucked into a footnote:

The publicly traded companies that had high-performing IT teams had 50 percent higher market capitalization growth over three years than those with low-performing organizations.

I believed the data. It matched my intuition and experience.

DevOps and the Market

Companies doing DevOps win in the market. In a world where digital transformation has made competition between companies increasingly dependent on their ability to differentiate through technology, the ones who do best in tech are likely to win. As I heard an executive at an airline put it, “Anyone can spend tens of millions on a new Boeing or Airbus jet. There’s no sustained differentiation there. But a great booking experience … a great mobile app … that can win loyalty.”

So I found myself thinking that I sit in the middle of a DevOps community and know which companies are bragging about their DevOps successes. I truly believe it helps the business win.

The Bet, and Winning It

So that brings me back to that evening in December and the proposal I took to my wife.
1. This was gambling. We’d risk only a fraction of our savings.
2. We would buy and hold for one year, then re-evaluate.
3. I would do no research on the companies we’d invest in outside of their DevOps practices. We would assume other public information would be priced in by professionals acting in an efficient enough market.
4. Investments would be in companies “doing,” not “selling,” DevOps. No vendors.
After getting the green-light, I bought a dozen stocks based mostly on the “who talks DevOps at conferences a lot” criteria: Amazon, Bank of America, Capital One, Cisco Systems, Etsy, Live Nation Entertainment, Macy’s, Netflix, Nordstrom, Sherwin-Williams, Target and Verizon Communications.

So let’s talk about a few of these companies. Amazon and Cisco arguably violate the “no vendors” rule. Amazon I’ve excepted, as the company has a good reputation for DevOps internally, and many of the other retailers included are motivated to DevOps by fear of Amazon. They’re included as a hedge against Amazon killing all retail. In fact, Amazon was my only retailer to beat the S&P. Over the past three years, I found Cisco’s talks of its transformation at conferences (including IBM’s) compelling. Further, the hardware-to-network functions virtualization (NFV) transformation they’re going through seems similar enough to a retailer’s brick-and-mortar to e-comm to warrant inclusion.

My employer, IBM, is not included because it is a vendor and as an employee its performance already has a big effect on my life. Etsy and Netflix are my “unicorn” contingent. Etsy crushed it for the year (+38 percent). Netflix underperformed (+6 percent) and was a major drag through the first half.

Retail and e-commerce was generally a weak segment with Live Nation (Ticketmaster), Macy’s, Nordstrom, Sherwin Williams and Target all underperforming the S&P 500. Compared to a retail index fund (XRT), all but Nordstrom and Target came out ahead, though. It was a rough year for the segment, but those investing DevOps seemed to outperform their competition.

All in all, the approach beat the S&P 500 by about half for the year, albeit with considerably more volatility.

Good Sentiment, Sketchy Investment Strategy

That said, a deeper look at this approach makes me think it was more luck than skill. While I believe that high-performing IT yields business wins, I didn’t actually know which companies have high-performing IT. The DORA team has the best data. I don’t. A big financial institution is likely to have more techies than Facebook. Do a handful of them presenting at conferences really say much about their thousands of colleagues? I have doubts.

DevOps transformations, like Agile transformation, are hard to do at scale. It’s the scale that counts, and will generate the business differentiation. Some transformations led by brilliant champions will end up failing. Mid-year, I was at one of our DevOps networking events talking with someone from one of the companies in this list and suggested that they must be nailing DevOps given what I heard at conferences. The answer was, “Not really … we’re kind of starting over and the people championing DevOps have all left.” I’m not surprised that company is one of my underperformers.

Sophisticated investors will point out approaches for managing exposure to segments and better isolate DevOps effects from overall market moves. Not researching and using those is another flaw in the approach.

And yet, if picking stocks at random would yield average results, but DevOps helps company win, and people talking about DevOps likely represent companies with more DevOps than others, it’s not shocking to see this strategy happen to get lucky.

What Will I Do Next?

My focus will remain on ensuring the IBM UrbanCode business embraces DevOps practices, mindsets and approaches in every way and supporting IBM’s overall transformation. While transforming myself, I’ll remained focused on helping my clients with their own transformations. Check out some DevOps success stories.

As for investing, I’m not a gambler at heart and may simply close down this experiment while I’m ahead and pick a nice index fund. Or, I may refine the picks to only take those that are publicly talking about how they spreading these practices to thousands of practitioners.

Disclaimer: I’m a techie, not a financial advisor. I recommend improving your own business with DevOps. I do not have a recommendation for how you should invest. Past performance is not indicative of future results. This experiment could have gone badly, and for a while in the first quarter, it looked as though it would. Please don’t take risks you can’t afford based on the experience of a rank amateur investor like myself. This experiment was mine and mine alone. I speak for myself, not my employer.

About the Author/ Eric Minick

Eric Minick is a technical evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last 10 years helping organizations large and small adopt continuous integration, delivery and, now, DevOps. He is a frequent speaker on the topic, and co-authored “Application Release and Deployment For Dummies.” Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products. Follow him on Twitter at @ericminick.

— Eric Minick
January 25, 2017
Does Automating Application Release Mean the Same that it Used to?
Over the last ten years, we have seen a shift towards automation in how applications have been released. Automation has been encouraged first by agile’s embrace of continuous integration and delivery, and now the broader move to DevOps. As deployment automation left the sphere of the individual development team, another trend has emerged. The understanding of what it means to deploy an application in an automated fashion has steadily expanded. For developers in the early days of continuous delivery, production concerns were usually secondary. They would take a single build, and automate its deployment to test environments. Some teams would succeed in expanding this approach to production with a full-fledged delivery pipeline, but most would stumble. Ignoring production concerns in the lower environments resulted in their work being dismissed as unworkable in production environments. However, the success of agile development meant an increased demand for change in production. At the same time, the trend towards cloud services expanded the number of targets that a given deployment would impact. Production support teams had to automate, and in a way that would also work for the rapid rate of change in development and test. The build pipeline model was close, but didn’t meet the Ops needs of incremental change (rather than full builds), and orchestrating changes across multiple builds and tiers.

A 2012 survey of over 500 technologists by UrbanCode found that only 12% of teams scoped production releases to a single build. With the business demanding faster change, and DevOps ascending, we have seen automation mature in the production environments rapidly in the past several years. This includes the rise of Application Deployment/Release Automation as a tool category at the start of this decade. These ADA tools are defined by automation scoped at a business application – they coordinate across multiple tiers and components. So they deploy not just the new version of a web service, but also five other web services the backend databases, etc. With DevOps better linking development and operations, and an increased willingness to automate in production, we saw the first big shift in the scope of automation. From deploying a build, to deploying the build and related builds, content and database changes. The web app was still the most common scenario. Today we are seeing the next major expansion underway, and it’s hitting on several fronts at once.
1. The first front is that organizations whose releases span multiple business applications are adding release centric orchestration to speed releases of coupled applications.
2. The next front is a move beyond the web application itself. Mobile development tied to backend services is getting pulled in to the definition of the “business application” as are systems of record including the mainframe.
3. The third front is a shift down the stack. The environment and infrastructure are seen increasingly not as a place the application runs, but as part of the application itself. As that shift happens, we see a push to make a change to the CPU count in a VM go through the same types of automation and governance that updates to the behavior of a web service go through. Change is change.
4. Finally, we are seeing the normalization of Platform as a Service offering like Bluemix. That results in increased acceptance of the technology, but also the desire to coordinate change to services delivered through a PaaS platform and those delivered through other cloud or traditional data-center platforms.
Broadly, IT is delivering value to the business by delivering services. Changes to those services tend to be scoped to applications that are complex. The trend is to treat everything in that application that is software defined the same through the same channels. That lets system level testing validate the whole system, and for the whole system to be promoted forward together. The above discussion not only informs about the change taking place but also prompts at taking the step towards the change. The move to DevOps is bringing about change rapidly. On November 20, some of the industry experts and leaders got together to discuss the effects and steps to adopt the change effectively, at the IBM DevOps Symposium in the New York area (Jersey City). Understand how to adopt DevOps successfully by listening to distinguished industry leaders and experts. Join us for the replay of the webcast. Be a part of the change

About the Author:

Eric Minick is a Technical Evangelist. He joined IBM through its acquisition of UrbanCode. He has spent the last ten years helping organizations – large and small – adopt continuous integration, delivery and now –DevOps. He is a frequent speaker on the topic, and co-authored Application Release and Deployment For Dummies. Prior to consulting, Eric was a developer, test automation engineer and support engineer, and has contributed to multiple generations of UrbanCode products.
December 9, 2014