devopsy.kinsta.cloud

Tag: standardization

Will AI Kill the OSS Star?

What at first was only being whispered about at community meetups, in private chats among project maintainers, inside OSS business-model strategy meetings and other backwaters, has now fully bloomed into mainstream social media posts, blogs and articles.

Just what exactly is the effect of AI on open source software?

Put even more bluntly: Will AI kill off the OSS market as we know it?

It’s a funny thing. Things seem invincible, until they aren’t. Sometimes the end comes swiftly. Sometimes it comes by a thousand cuts. And even when it looks sudden, it usually isn’t. The decline has been happening quietly for a while, below the radar, until one day it’s visible for everyone to see.

We’re roughly three years in since generative AI burst onto the scene. In that short span, it’s gotten very good at writing code. Good enough that today it’s hard to argue with estimates suggesting more than half of new code is written either directly by AI or with heavy AI assistance. And during that same period, something else has been happening in parallel: Fewer developers reading docs, fewer stars and forks, fewer meaningful community interactions around open source projects.

Developers are still using open source. They just aren’t showing up.

That difference is everything.

For decades, open source thrived not just because the code was free, but because the ecosystem around it was alive. People read the docs. They filed issues. They debated approaches. They contributed back. That activity wasn’t just cultural; it was economic. Attention turned into adoption, adoption turned into credibility, and credibility eventually turned into revenue through support, services, enterprise editions or hosted offerings.

AI is quietly snapping that chain.

When a developer asks an AI assistant how to do something, they don’t land on your documentation site. They don’t browse your examples. They don’t even know which project the solution came from. The AI becomes the interface, the translator, the front door. The open source project itself fades into the background.

This dynamic has been documented increasingly well over the last year. Reporting from Hackaday and 404 Media, along with analysis from engineering consultancies and OSS practitioners, has described what’s now commonly referred to as “vibe coding” — a development pattern where AI mediates most interactions with open source rather than direct engagement with the project itself.

The result is a strange paradox: Usage goes up, but engagement goes down. And when engagement goes down, the business models that sustained open source start to wobble.

We’re already seeing it. Projects are reporting sharp drops in documentation traffic. Maintainers are noticing fewer thoughtful contributions. Companies built around open source are struggling to convert popularity into revenue. Sponsorships dry up when the visible signals of community health — stars, forks, discussion — evaporate.

This is what “vibe coding” really means. The vibe is convenience. The cost is connection.

If you want to understand where this hurts the most, talk to maintainers. Open source maintenance was never glamorous work, but it was at least grounded in a sense of shared responsibility. AI changes that dynamic. As several researchers cited by 404 Media point out, AI tools can generate large volumes of pull requests that technically function but lack an understanding of project context or long-term intent.

Burnout was already a problem in open source. AI is accelerating it.

There’s also a more subtle erosion happening. Open source wasn’t just a distribution model; it was an apprenticeship model. You learned by reading other people’s code, by seeing how problems were solved, and by participating in the conversation. When developers jump straight from a problem statement to an AI-generated answer, that shared learning loop weakens. The code may work, but the collective understanding doesn’t grow.

To be fair, there’s a counter-argument — and it’s not wrong. AI is trained on open source. It depends on open source. It often recommends open source libraries. In many cases, installation numbers are still climbing. As Made With Love has argued, AI can actually increase adoption of open source components even as it disrupts the surrounding economics.

And let’s be clear: AI does not replace high-quality, well-maintained libraries. It remixes existing knowledge. It does not assume responsibility for long-term maintenance, security patches or operational stability. When something breaks at scale, nobody opens a support ticket with an LLM.

So no, AI isn’t killing open source outright.

But that’s not the real issue.

The real shift is economic and behavioral. AI makes bespoke code cheap. Historically, open source won because it spread effort across the community. Why reinvent the wheel when someone else already built it? Why maintain your own version when the shared one is better?

AI flips that math. When generating a custom solution takes seconds, the incentive to standardize drops. Teams increasingly ask the AI to write “something like” what they need instead of pulling in a dependency. Both Hackaday and 404 Media highlight this trend as a core risk: Fragmentation replacing shared foundations.

In the short term, this feels empowering. In the long term, it leads to duplicated effort, harder-to-secure systems and brittle software nobody fully understands. Security teams hate this. Operators hate this. Future maintainers really hate this.

Layer on top of that the unresolved legal and licensing mess. Enterprises are uneasy about what they’re shipping. Maintainers are uneasy about how their work is being absorbed into training data. Nobody really knows where attribution begins and ends anymore. Add in the growing fear of “AI slop” — oceans of low-quality, insecure or redundant code — and the signal-to-noise problem only gets worse, a concern echoed across all three sources.

So where does that leave us?

In the short term, it’s hard to argue that AI isn’t dampening the fervor around open source. The energy has shifted. The gravity has moved. Communities feel quieter. Business models feel shakier. Maintainers feel more isolated.

Longer term, there’s still a path where this makes open source better, not worse. Scarcity has a way of clarifying value. Projects that survive will likely be better governed, better maintained and more intentional about sustainability. AI may force open source to grow up in ways it’s long postponed.

But make no mistake: We’re in a transition, not a victory lap.

And that brings me to Shimmy’s take.

Nothing lasts forever. Not empires. Not sports dynasties. And certainly not technology models. Open source has had a remarkable, historic run as the king of the hill. For years, it felt untouchable. The default answer to almost every software question started with, “There’s an open source project for that.”

AI isn’t some scrappy David throwing stones at OSS’s Goliath. It’s a structural force rearranging the ground beneath it. It’s already disrupting the open source apple cart. Whether it topples it completely or forces it to become something different — and maybe even stronger — is still an open question.

But one thing is clear.

Things only seem invincible, right up until the moment they aren’t.

February 9, 2026
Survey Sees Value But Limited Understanding of Platform Engineering

Platform engineering is emerging as method for managing DevOps at scale, but a survey suggested that many organizations are still not clear on the concept.

A survey of 100 DevOps engineers, platform engineers, developers, site reliability engineers and IT managers conducted by Civo, a cloud service provider, found 85% of respondents work for organizations that have partially or fully embraced a DevOps culture, with nearly two-thirds (65%) identifying platform engineering as the next evolution of DevOps. Nearly, a third (30%) of respondents work for organizations that are already currently evaluating whether they should adopt platform engineering.

Overall, the survey found 50% of the respondents at organizations that have adopted platform engineering reported improved standardization, with 43% also seeing faster product delivery.

However, only 41% of the respondents in DevOps roles that were familiar with platform engineering said they had a moderate to high level of familiarity with the concept.

Saiyam Pathak, director of technical evangelism at Civo, said the survey makes it clear that, in terms of understanding how platform engineering best practices should be implemented, there is need for more clarity. Many organizations initially adopted DevOps to spur innovation, so any approach to centralization shouldn’t come at the expense of developer productivity, he noted.

Historically, DevOps adoption of DevOps workflows in most organizations has been driven from the bottom up. As a result, it’s fairly common for multiple application development teams within an organization to have adopted multiple DevOps platforms to manage workflows. Advocates for platform engineering are making a case for eliminating many of those redundant platforms in favor of, for example, a single continuous integration/continuous delivery (CI/CD) platform that serves as a corporate standard.

At the core of those efforts is the assumption that centralization will reduce costs by eliminating redundancy. At a time when more organizations than ever are sensitive to the cost of IT, there is always going to be a natural tendency to rationalize platforms. Challenges arise, however, when centralization results in a loss of flexibility. Many of the teams adopt DevOps because they want to be able to add and replace tools as they see fit. If there is a corporate standard that narrows their tool options, those teams may start to look for ways to do an end-run around the corporate standard.

The philosophical IT battle between advocates for centralization and proponents of decentralization has been around since the first PCs showed up in enterprise IT environments. As always, organizations need to strike a balance between both extremes, said Pathak.

It’s not clear how much platform engineering might accelerate the pace at which applications are built and deployed, but the total cost of DevOps should decline as various tools and platforms are consolidated. The challenge, of course, is that centralizing DevOps workflows is likely to disrupt the application development workflows on platforms that may about to be rationalized.

Regardless of what platforms become the corporate standard, the one thing that is certain is the cultural challenges associated with successfully making that transition will loom large within most organizations.

June 28, 2023
Standardize: It’s Not the Where. Sometimes it’s Not the What

In our industry’s attempts to follow best practices that marketers assure us we must have or we are going to lose to our biggest competitor … No, wait, we’ll lose to that startup no one ever heard of … No, hold on, we’ll lose to foreign competition … No, wait … (okay, I’ll stop. You get the picture), many of us have gotten completely unreasonable in our IT approaches.

Like asking a vendor, “Where can I run your application?” Well, the more “where” options the better, because every organization has different needs. But a vendor has to start somewhere, and you can tell when they get to a certain size because they don’t want to talk about it. “We’re SaaS,” was the en vogue thing to say six months ago; now we’re back to “containers” or even “cloud,” thanks to a whole slew of cloud-first offerings out there. But what all of these vendors really need to be able to say (and a disappointingly small number of them actually can) is, “We run on containers, so we don’t have to care where you deploy us.”

Those are the types of scenarios that forward-looking enterprises need to start anticipating—the broadest, easiest-to-implement, longest-lasting solutions that can be found. The days of “devs picked this DB no one ever heard of because it was 0.0000001 microseconds faster on a hundred-line query,” need to be gone. Standardize on highly usable tools across the DevOps toolchain from libraries approved for use in apps to deployment technology.

A big part of this approach right now is my pretty common refrain: Advanced automation. The more a system can do, the more time staff has to do other important things. All forms of testing are finally within our grasp because of advanced automation technology ranging from Kubernetes programmability and controllers to ‘AI’ filtering of results (Side note: What most IT folks currently call AI is not; we need to stop calling it that and give it a more accurate name. Machine learning is better; advanced automation is more to the point, IMO). But whatever you call it, it enables massive pre-release testing. From functional to security, it offers the ability to make these tests useful by speeding up testing and results processing so staff need only look at issues considered critical. No one cares where the test engine runs, just that it can run tests wherever the application resides.

The same is true for a whole lot of other ‘whats.’ Vulnerabilities are probably the best example. Tools are starting to look for them in an automated fashion. Very few organizations have a comprehensive list of which vulnerability databases a tool must support. Any given organization might have one or two databases in their list, but most just require that the functionality be available.

So don’t get bogged down in the details, and don’t select five different tools to do the same job on five different teams. Start standardizing again. Oh, standardization won’t last when something evolutionary comes along in the space, but it will leave you less clutter to clean up and more specific expertise in-house.

And that leaves you more time to keep wowing the business. Keep those systems running smoothly and keep cranking out more useful stuff for the organization. Most orgs show their appreciation these days, but some still do not. In those cases, we thank you for them. We know what you’re going through—we are going through it, too, and yet the lights are still on. Keep rocking it.

May 17, 2023
Tips For Standardizing API Life Cycle Management

Software life cycle management is becoming more critical for today’s technology-fueled organizations—because you can’t just release software into the world and expect it to work perfectly for years to come. More often than not, development teams must constantly adapt their software, progressively add features and cater to new use cases as they arise. This is nothing new for web APIs, which are prone to continual evolution and whose integrations require regular upkeep to avoid breaking changes.

As such, the discipline of API life cycle management has gathered steam. This concept focuses not only on the design and development of APIs, but on the entire life cycle, including testing, monitoring, documentation, maintenance, versioning, CI/CD and even deprecation. Localizing a strategy for API life cycle management from the get-go can increase the longevity and usability of a platform. It also helps software providers treat their APIs as an iterable product rather than a one-and-done offshoot of a digital platform.

I recently met with Rakshith Rao, co-founder and CEO of APIwiz, to gather insights on standardizing API management across an organization. According to Rao, there are many ways to implement governance to make these interfaces more consistent. For example, automated security analysis, contract-driven development and implementing style guides are just a few ways to wrangle an increasingly extensive API portfolio. Below, we’ll review these tips and others to consider how to best manage API life cycles, hopefully, before sprawl sets in.

Four Tips to Increase API Governance

Medium-to-large organizations might be handling thousands of APIs, said Rao. This new paradigm brings many opportunities for digital transformation, but it can also be a nightmare to manage. Too often, APIs aren’t built with tangible business requirements taking center stage.

Many of these initiatives didn’t begin with consistent policies from the get-go. For example, it’s also easy to skip out on documenting internal services. But, fractured practices harm discovery and reusability. To rectify this issue, Rao shared many ways in which technical leads can promote better API hygiene.

Enable Visibility of API Usage With API Monitoring

The API life cycle spans stages of design, deployment, deprecation and eventual retirement. And throughout this life cycle, developers will likely release new versions of the same service. But although you want consumers to adopt the latest version, some large organizations must support legacy versions for years to come, explained Rao. As a result, different API versions are often developed and run simultaneously by various internal or partner teams. Sometimes, “no one turned the tap off and the water’s still running,” he said.

To enhance visibility for all active (and non-active) sessions, it’s important to conduct ongoing monitoring. This will help discover individual client usage patterns and help avoid shadow or zombie APIs from forming. These forgotten endpoints could pose security vulnerabilities, said Rao, as you might not enforce best practices on older versions if you don’t know they exist.

Automate Security Analysis to Capture Vulnerabilities at the Design Level

Not having consistency between APIs could pose data compliance issues. One method to avoid errors is to conduct design reviews on an ongoing basis, and to automate this security analysis at the design level, said Rao. Perhaps authentication tokens need to be encoded, logging requests aren’t coming in, or payloads are structured incorrectly. Whatever the case, having a complete checklist to scan and performing ongoing security analysis early on to catch these inconsistencies can be a big boon to overall governance and long-term cybersecurity.

Adopt Style Guides but Allow for Flexibility

Very simple data modeling errors could severely impact a system, said Rao. Thus, it’s in an organization’s best interest to use standard taxonomies and ensure data governance is an overall aspect of life cycle management. One way to ensure consistency is by using specification-driven development—OpenAPI is a common standard for this need.

Rao also suggested developing API design style guidelines but admitted that these guides become challenging to enforce and limit as an organization scales. This is because various teams in different departments will have different API needs and often design their interfaces for various front-end requirements. His takeaway is to centralize practices but take a GUI approach to configuring and sharing them. This way, API style can be “minimally intrusive but uniformly enforced.”

Use an Abstraction Layer for Multi-Cloud

A full 98% percent of enterprises are using at least two cloud infrastructure providers, according to a recent Oracle report. Nearly everyone is adopting a multi-cloud strategy, but this new reality brings novel pressures for DevOps, especially when overseeing the deployment of APIs across different cloud platforms. An API life cycle management platform decoupled from these CSPs could help wrangle polyglot deployments.

Sticky Notes Aren’t Enough for API Management

API life cycle management goes well beyond the development and runtime phase. And as more API-first development occurs within organizations, maintaining standard interfaces will naturally require more effort. Rao also advocates for increased infrastructure automation and low-code solutions to meet these new challenges. Automating various parts of the API life cycle so there is less manual work “helps to bring down the guesswork of ensuring reliability when you release an API,” said Rao.

We’re seeing some enterprises move from supporting hundreds to thousands of APIs. In this new paradigm, “API sprawl is imminent,” said Rao. As such, it will become virtually impossible to manually keep these interfaces in line, understating the need for more automation. Especially during times of economic uncertainty and leanness in the tech market, the democratization of such API management automation will be vital in helping organizations move faster.

Having broken pieces of information and scattered API contracts will lead to a messy and potentially insecure adoption. As such, API management can no longer be done using sticky notes on the edge of a computer screen, said Rao. Taking the guesswork out, centralizing common policies and shifting more legwork behind the scenes will be required to avoid a splintered portfolio of services.

February 17, 2023
Build Once, Deploy Anywhere

This late in the game, it seems stunning to me that I have to write this, but there are plenty of you who aren’t there yet—so let’s try a different approach.

A huge part of DevOps is reducing redundancy. We have cut the fat until it hurt, then refocused and cut some more. There is a blog here about burnout, but we’ll save that for another day. The point is, we don’t do the same thing over and over unless there is a quantifiable benefit—like rebuilding and testing new iterations or spinning up base images to start a new project.

We insist that our applications run in as standardized an environment as possible, with images from a repository and standardized software installed.

And then we promptly put it into a unique environment where deployment is completely different. Yes, I’m talking about which cloud or which data center; if it’s deployed via a data center, then hardware, virtual machine or container? The work to standardize the important bits and leave the less impactful bits to teams to decide has been astounding on the Dev side of DevOps (for those new here, what I call DevOps), but have been far less effective in DevOps. Even companies that claim to be pure cloud generally have two or more cloud vendors, each of which is doing things differently.

So, with all of that said, I can say what I should not have to say after all of these years:

Make containers standard. I don’t care which flavor and management tool you use, but add in that portability layer. It will protect you from a future where your preferred hosting environment (be it cloud, local or hosted) becomes hostile or overly expensive—or simply ceases to exist. And it will standardize the rest of your DevOps processes. Yes, your preferred cloud vendor offers Kubernetes, and no, that’s not sufficient. Kubernetes offerings today are like Microsoft in the 1990s. Embrace and extend to build the lock-in barrier higher. You do get some great functionality from the cloud vendors I pay attention to, but processes become non-standard. Better to limit platform-specific work to “spin up a server” and have everything else be reusable whereever you are deploying. The benefits here are far-reaching; there will be configuration and security issues that are different when you move from cloud to cloud or cloud to data center or data center to cloud, but the core of DevOps will remain standardized. There are tools to help with baseline cloud security and risk management, so those in addition to using Kubernetes as a portability platform will make current work less onerous, and massively increase portability from deployment location to deployment location.

You’re short of staff. It does not take a rocket scientist to predict that this situation will not change. Adopt the things that will reduce your workload—like DevOps standardization on Kubernetes (or OpenShift or whatever) as a deployment platform—and keep rocking it. You can’t wave your hand and get more staff or hours in the day, but you can implement containers as the sole deployment option to save time. And use those hours to solve other company problems—because that’s what we do, solve problems for the business. And keep smiling, because you’re rocking it. If you weren’t, they’d find someone who could.

August 31, 2022
DevOps Unbound EP 18 – Standardizing DevOps – TechStrong TV

Alan Shimel: Hey, everyone, welcome to another DevOps Unbound. If this is your first time catching a DevOps Unbound, welcome. DevOps Unbound is a biweekly video series where we talk about relevant topics in DevOps. In addition to the biweekly show, we do, it’s every four to six weeks, a live roundtable show where we invite the audience to participate and drive the discussion with online questions and comments and so forth, so we open it up to a live audience. Unfortunately, this show is not one of our live roundtables, it is prerecorded, but we have a great panel and I think you’re gonna enjoy it.

I’m gonna get into today’s topic in a second, but before we do, let me introduce you to today’s panel. First of all, I wanna introduce a business partner of mine and my friend, Jayne Groll. Jayne, why don’t you introduce yourself to the audience, if you don’t mind?

Jayne Groll: Thanks, Alan. Hi, everyone. I’m Jayne Groll, I’m CEO of The DevOps Institute, we’re a global member association and a certification body around topics related to DevOps. I’m really, really excited to be here and I’m hope everyone listening joins us at DevOps Institute and becomes a member.

Alan Shimel: Fantastic. Welcome, Jayne. Joining Jayne, I’m happy to have Paul Bruce. Hey, Paul, welcome, and if you wouldn’t mind, you know, introducing yourself?

Paul Bruce: Yeah, hey, Alan. Good to be back. My name is Paul. In my full time job, I work with Tricentis in a number of different areas. I’m historically a performance and reliability nerd. In my off time, I organize a number of events, help to co-organize volunteer things like DevOps Days Boston, just did o11yfest this year about observability, we had that conversation, I think, with Christine Yen a couple months ago.

Alan Shimel: Good stuff. Mm-hmm.

Paul Bruce: And generally, I’m a people advocate. I had to pull DevOps out of my LinkedIn title because there were too many recruiters that I don’t need, because I’ve got a pretty good job. But also, because people advocate really describes what I care the most about, right? People are some of the hardest part of the DevOps people, process, and technology, really, software. So, I really focus my time on that.

Alan Shimel: That’s great to have you back on, too, Paul—good stuff. Next, we have a first time guest on DevOps Unbound today, a new member of the band, Sarah Baker. Sarah, welcome to DevOps Unbound, if you wouldn’t mind introducing yourself?

Sarah Baker: Thank you. Wonderful. Welcome. My name is Sarah Baker, my pronouns are she and her. I’ve been working in Operations my entire career and I’ve moved into DevOps as something I always—I needed a name for it. I always wanted the people part of Ops and technology and DevOps was that. And I’ve been doing that as soon as I learned the term. And I’ve been moved and started working with Paul Bruce in the IEEE work group 2675, who is trying to create a standard for DevOps.

Alan Shimel: Fantastic.

Sarah Baker: I work for—and today, I work as the Manager of Biztech in Airbnb.

Alan Shimel: Thank you, and thanks for joining us. That sounds like a great place for you to do this. And then the last member of our panel today is my co-host and another business partner, a long-time friend as well, Mitch Ashley. Mitch, if you wouldn’t mind introducing yourself?

Mitch Ashley: You bet. Always good to have a good panel on with you, Alan. Mitch Ashley, I’m CEO of Accelerated Strategies, an analyst firm that’s focused on DevOps, and also on cloud native, cyber security, and digital transformation. I come to DevOps both as a practitioner and a vendor leveraging it, so very interested in hearing the perspective of folks on our topic today. So, thanks for joining us, everybody, too.

And by the way, our DevOps Unbound is sponsored by Tricentis. I think you may have mentioned that, right, Alan?

Alan Shimel: No, I think I didn’t, Mitch, but thanks for picking it up for me. [Laughter]

Jayne Groll: [Laughter]

Mitch Ashley: I was trying to give you credit where credit may not be due.

Alan Shimel: Yeah, no, I don’t wanna take credit when I messed up. Yeah, DevOps Unbound is sponsored by Tricentis, and many thanks to them for their sponsorship. It makes all of this happen.

So, let’s turn to the topic at hand today, guys. You know, when I first started devopsy.kinsta.cloud eight years ago, I met Jayne maybe a year, within a year of that or a year and a half of that. One of the interesting things about DevOps is, there was no manifesto. There was no hard definition of what is DevOps and what is not DevOps, you know, contrary.

And ever since then, it’s been a double-edged sword. In some ways, it’s helped DevOps grow, it’s helped DevOps stay current over the last 8 to 10 years as the world has changed, DevOps has changed along with it. On the other hand, though, we’re still dealing with the, “So, what is DevOps?” Right? “What exactly is DevOps and what exactly is not DevOps?” which is sometimes harder than what is DevOps.

And as we sit here now, August, 2021, there really still is not a quote-unquote standard for DevOps. There is no standard DevOps. It is what you want it to be, right? As I think Andrew Clay Shafer said, “The DevOps you get is the DevOps you deserve,” right? But have we outgrown that stage? You know, that seems like a terrible twos stage of DevOps to some; to others, it’s what kept it cool. Has DevOps matured? Do we need standardization? Will it be something that kills the goose that lays the golden eggs?

We’re gonna discuss that today, and I’m interested in all of your views. Jayne, as the CEO of DevOps Institute, how many people have taken certified DevOps classes and certifications with DevOps Institute? It’s gotta be tens of thousands.

Jayne Groll: Yeah, about 25,000 so far. So, it’s a pretty large community.

Alan Shimel: Mm-hmm.

Jayne Groll: And if you don’t mind, I wanna kind of just lay the stage, because I’m really interested in the standardization initiative. So, you know, I had a privilege of seeing, going to DevOps Days in 2012 in California. So, if you can imagine, it was in an old, dusty data warehouse, right, and it was at the very, very early stages. And so, one of the reasons DevOps Institute emerged was because there was a lot of really cool things here culturally, from an automation perspective, right, doing things faster, collaboration.

And so, we started up DevOps Institute because we wanted to make sure the humans were represented. And I love that Paul and Sarah in particular both represented people. The problem with that is, at that point, it was very, very open, it was very kind of organic. You know, it was really a group of passionate people that were trying to just change the way IT operates, right, from a people, process, and technology perspective.

What happened after that, though, is that there’s so much noise about DevOps that if I were an enterprise CIO right now, my head would explode, right? Now, is there one right way to do DevOps? No. Is it only gonna get you there with automation? No. You know, is there a very, very strong human element—absolutely.

So, it’s a double-edged sword, Alan, as you said, is that we wanna be able to kind of scale down, right, some of the common language, some of the common definitions. I always say I’m married to a CPA, they have generally accepted accounting principles; maybe someday, we have generally accepted IT principles. But how do we distill the noise, right, and everyone having a different interpretation of how to do DevOps and what it is compared to, let’s get past the, “what is it?” We’ve spent, what, 10 years trying to figure out what it is, to, “how do we do this?” Right?

Paul Bruce: Mm-hmm.

Jayne Groll: And it isn’t just one roadway that takes you there. So, I think it’s a challenge. I mean, we introduced foundational certifications around DevSecOps and SRE and DevOps Foundation and DevOps Engineering, really, to create kind of a common vocabulary more than the, “here’s the single way to introduce CI/CD.”

So, I don’t know if that helps kinda set the stage, but I think it’s a really big challenge right now that, if we standardize it, we run into the risk of what happened with ITIL where it couldn’t keep pace, right, and it became religious. I come from the ITIL space, right, so it’s like, open chapter 1, verse 3 and sing a hymn before you introduce change management to how do we then, on the other end of the spectrum, it’s so open and so undefined that it’s really complicated for legacy, I call them heritage organizations, to be able to move from this step to this step.

Paul Bruce: Mm-hmm.

Alan Shimel: The church of ITIL. Paul, what’s your feeling on that?

Paul Bruce: Well, everybody’s on a journey, right? Your personal journey, your professional career, whatever, maybe you go do a walkabout on a particular topic to learn more about that. And so, we started this venture, there was an early round of, “Who wants to be involved in something like this?” in 2016. I answered a call from Bob Aiello and Lynn Carter, who were kind of forming this idea of, there’s a bunch of people who really care deeply who have practitioner practical experience in the field. And the early part of this process was just learning, kinda level setting on what we have done, right?

Jayne mentioned that it’s hard, maybe, to have accepted IT standards, even though there are standards, right, that not every organization applies the same way. I don’t think that invalidates some of the general principles that we know to be true, which is, you know, you ship broken software, you hurt people, you hurt yourself, right? But those are high level. How do we break this apart and start to make sense of the world, as you said, the heritage, Jayne, you said the heritage organizations—what is so wrong, what’s going on that we have these kind of security problems, these performance problems, this inability to be competitive in terms of acceleration and stuff.

And so, I think the purpose of a standard is not necessarily to force people to do something a certain way. I think it’s simply just kind of like, if you’ve ever had the Christmas ornaments or just ornaments box that has the insert that allows for things to be put in careful places and also work together as a unit, right, to provide a normative, not a prescriptive standard, but a normative standard to say, “Look, these processes that you already know? Well, you already followed these from, let’s say, 12207, right?” These processes around supply acquisition, knowledge management, human resources? Right, human resourcing in DevOps is a big problem, at least in the Boston area. Try to hire an SRE—there’s only about 15,000 to 20,000 in the United States, legitimately. There’s a reason for that demand.

So, how do we think about the processes we already know and start to say, how are these things different because there are some accepted principles and practices around DevOps? Now, the practices are not things that you would ever wanna dictate in a standard. This is not the same granularity level as some other standards that dictate how to encode time formats. That’s very important at that level. But the level that we were working on was how to level set across the things that, especially organizations in high compliance and high risk industries, right, risk-averse industries—how do they take the practices and processes that they know from a process standard and start to go, “I understand how to plug, now, what the DevOps principles are into the standard to encourage both of those practices in a more predictable manner?”

So, when we did all this work—it’s taken years, right, of a lot of learning collaboration between a whole host of people I don’t have even time to list out, but a lot of people from a lot of various different aspects of software have a lot of experience in those aspects. You know, it took synthesis and refactoring, and I was up nights and weekends just rewriting some of the statements, you know? And each of these, it’s a line to 12207, so there’s multiple processes, process declarations like quality management, quality assurance, verification and validation.

Like I said, these project enabling processes and then these technical processes, and each of those process sections have outcomes, activities, and tasks. Things that are likely to occur in this area, right, as well as, regardless of how you do this, right, not dictating what the DevOps looks like, it’s outcomes of these things that are auditable, that not compliance but conformance. That you can confirm at various levels to these outcomes to say, if it’s important to get this right, when you hit the piñata, what comes out should be candy, not garbage, right?

So, I’ll pause there, because I wanna give Sarah a chance to kinda provide perspective, because she’s also been working a lot with us, for all those years. [Laughter]

Sarah Baker: I think I counted 27 people on the final author list for the IEEE.

Paul Bruce: Yeah.

Sarah Baker: And it was many, many weeks of arguing, reading together the exact language. And I agree very much with some parts of what Paul says, and I wanna step back and talk a little bit about how I see, you know, what, to me, was the big shifts. And so, the way we wrote the doc was to kinda look at the 12207 and say, “How does DevOps change it? How has it changed the game? What are the perspectives that you need to have in mind in order to get the outcomes that Paul’s talking about, there?”

And so, when we were writing it, we were writing it to that. How is this different, and to what extent do you wanna consider these areas? It’s a framework of thinking. At its largest level, it’s a framework of, for me, the value chain of delivery of software. And it’s not—and it uses many of the concepts that come out of learnings of industrial engineering, way back in the ‘40s, ‘50s, ‘60s. But it had never really come into a lot of the thinking of software, because software is different. And the more I was working and kind of digging into what are the concepts underneath DevOps, I came quite aligned with a lot of industrial engineering concepts about how things flow and how things move back and what the peaceful aspects are in that.

And so, that—actually, if you read through the standard, you’ll see a lot of those flow pieces and all of the pieces that you then say, “Oh, it’s the feedback loops, yeah, lots of feedback. Collaboration, it’s all there.” And it’s just applying a lot of those learnings into software engineering, to me. And it was stuff I was like, “Oh, it’s so wonderful to have this.”

And the other thing, one of the big learnings that I think I brought into the conversation is how—and Paul will back me up on this—how security for a lot of us changed slightly as we started walking our way through the 2675 work. The terms of risk became a very interesting concept that flowed through the document more than I would have expected.

Paul Bruce: Mm-hmm.

Sarah Baker: And so, there was some learning within the totality of our team as we wrote this. It was quite fascinating.

Mitch Ashley: I’m really fascinated to hear from both of you that have been working on this, because it’s not something I’ve been involved in. I sorta have a mixed history with standards, because I’ve worked in areas like networking and things like that where standards are very beneficial or really fundamental, but I’ve also learned standards are kind of what you’re gonna do, not how you’re gonna do it. Because we ran a test lab that, even though it says we’re gonna do least cost routing in a network device this way, people implement it differently and they don’t always work together. So, it’s not a nirvana, but it’s also not a pariah, either.

Paul Bruce: Mm-hmm.

Mitch Ashley: So, what I wrestle with here is that, I think some of the thinking—and Jayne can speak to this, but innovation happens so quickly now. So many things are created without standards; maybe they evolve into standards, maybe they don’t. And it doesn’t bother me that there’s lots of noise around DevOps, because we’ve all seen the cycles, the hype cycles, right? If it’s worthwhile, everyone and their brother, sister, cousin, uncle will all jump on the bandwidth and call what they’re doing fill in the blank—it’s AI, it’s DevOps, it’s whatever. That’s just part of our industry. And it’ll either fizzle—you know, value stream management, is it a real thing? We’ll see. It’ll fizzle or it’ll happen, right, if it’s a real thing. And DevOps has proven itself not only is it a real thing, but other parts of the organization now see an opportunity to play, to participate, to become part of the software creation process.

Paul Bruce: Mm-hmm.

Mitch Ashley: And I think that’s what’s so powerful about DevOps—it’s not about a technology, it’s about how we create software. And if you were gonna start out, you know, Jayne, when you went to that meeting in 2012 when you said, “We’re gonna go create a standard for completely doing software differently because we have cloud and we have the ability to automate and we were gonna change the software architecture,” you couldn’t have known how to do that. But being the industry would’ve, you know, the antibodies would’ve crawled all over all of us and stopped it. So, I think there’s a lot of power in the innovative, organic nature of it.

And I don’t want DevOps to turn into ITIL, [Laughter] because that’s sort of taken on a life of its own, and now it’s trying to catch up and it’s done some good things, too. So, I wrestle with trying to constrain it when I think it’s real power is the innovation behind what we’re doing.

Paul Bruce: Yeah, so, before I—

Sarah Baker: If I could take a moment—

Paul Bruce: – yeah, go ahead.

Sarah Baker: – I’d like to take a moment and call out something. Part of the problem with ITIL is like, it’s ITIL. And, you know, a gazillion managers said, “ITIL, let us get a hammer and hit you over the head with it.” And DevOps, fortunately doesn’t have that problem. It has, you know, a little fuzzier in its definition, but the great thing about DevOps is that it has that sort of fuzzy edges. You can’t, it’s really hard to beat someone over the head with it. You can try. I’ve seen it happen, you know? Everybody’s a DevOps engineer now, but it’s not necessary.

And what people talk about is not that, but the work, you know? It’s not, “We’re conforming with ITIL,” it’s like, “We’re doing DevOps.” The doing part is the important part, not the compliance part. So, when you say, when you hear people talk about it, they talk about it differently, and that’s the good thing.

I use ITIL, I just don’t tell anybody the word.

Jayne Groll: Which is a shame. It’s such a shame because, you know, I come from the ITIL space, and in the early days, this was not what the intent was to be. It was very much like DevOps in terms of, “Let’s help IT grow up,” right, in terms of some things.

And, you know, to what you’re all saying, you’re absolutely right. A framework, whether it’s a standard, is a guideline, right? It helps you with the journey, as Paul said. And so, if I wanna kinda check, check, check—you know, I’ve worked with some of the ISO standards, right? So, in the ITSM space, there was ISO 20,000, 27,000 for security, right? And it basically, like, in the one or service management says, “You should record all your changes.” It doesn’t say how to record it, it doesn’t—it’s a really great practice, you should do this.

The problem, sometimes, with standards—and I’m sure you know this and it’s a risk—the pure intention is pure. The ability to weaponize it, right, from the auditors and from others is a real risk, right? Because we’ve seen that with other standards as well, where it becomes more about the compliance than it is about how having it being a guiding light. So, I think there’s always a risk there.

And then the other risk is, you know, think about observability, right? So, observability has been trending, what, for a year, maybe two, right? Four—okay, but really mainstreaming, like, talking about observability as kind of a mainstream practice, right? And I will share with you, Mitch, to your point, when we launched DevOps Institute in 2015, we were not welcomed with open arms, right? We were vilified for trying to put some boundaries around this.

Now, you know, move forward seven years and I think we’ve overcome a lot of those and we have some that were detractors or really great supporters. But I think they were concerned that it would become weaponized or commoditized or whatever.

So, I’m just gonna say one last thing because I think it’s important. Commoditization of knowledge, which, this is kind of in support of the standard, right? Commoditization of knowledge where we make sure it’s available to everyone, some people see that as a negative—it’s not. What would happen if the whole world, right—every IT organization, every IT professional decided to take this standard and use it as a guiding light, according to the needs of their organization? They weren’t worried about the audit, they got trained, they shared knowledge—wouldn’t that be amazing? But that’s commoditization.

So, I think the risk of good versus evil on initiatives like this is real, but I also think that distilling it to everybody, kind of like accountants have done, right, is important because IT needs to grow up.

Paul Bruce: Yeah, well—

Mitch Ashley: Well, and if you look at the accounting standards, they don’t tell you how to do it, they tell you what to do.

Jayne Groll: Right.

Mitch Ashley: It isn’t prescriptive in the how very much, so it’s very much like an IEEE standard or whatever.

Paul Bruce: Yep. Well, first off, I forgot to mention when we first started—I speak as an individual contributor. If it isn’t abundantly clear, [Laughter] I don’t speak for the IEEE, and I don’t speak for the other people who have spent years contributing to this meaningfully.

So, when I say certification processes inherit all the exact same things you just mentioned as problems—weaponizing, actually low ROI maybe in some cases—we see these deficiencies and these outcomes that aren’t so great. And if you’re somebody who’s just gonna sit back and say, “I’m not willing to hold myself accountable” to stand up and say, “What does this thing actually mean like a real engineer should, you know, to start to break apart the problem and see what are the components, how does this thing work and how do I want it to work? How does it work best for the people around me as well?” If you’re not willing to do that, then I would call you the nay-sayer, you know what I mean? Like, not any one in particular, but that would be a nay-saying, like, let’s avoid accountability, let’s avoid doing what we know needs to be improved?

Continuous improvement is a huge element that is all throughout the entire standard. It’s one of the things that’s identified as some of the core principles in an ISO study that was done before we started in on this standard to see what are the common themes of people, when they’re really feeling like there is this DevOps mindset, this culture, these practices—what do they mean by it?

And a number of things came out. One was a high degree of automation, right? Okay, well, that’s very tactical. No matter how you do it, right—high degree of automation. Duh, right? How about effective communication and collaboration? How about shifting things and continuous everything? The notion of, that these things are not this one time and then three years later, you get to come back. No, no, no. If it’s a good idea now, maybe don’t bite off a three-year apple. Maybe take a bite, but know that you started in, there’s a continuous improvement process.

I can say, we mentioned earlier about a holy war that might exist when you start getting into what is DevOps and what is not DevOps. Like, I started—the best way I can describe to people, because like I say, half of my day is spent on and off of Slack with people who are actually doing, working this out in a highly statistical, large distribution across the country, you know, and sometimes outside the U.S., too, just time zone supply.

But I can say, for sure, after seeing the complete garbage Dumpster fire where nobody is willing to stand up and say, “Hey, aren’t these things common and standard?” And oh, by the way, not vendors that have something to push, right? I mean, that’s, I think, Jayne, where you were talking about maybe observability is now a thing. You know, the only reason why it’s a thing for the most part is because it’s in our face now because all the vendors are hash tagging the crap out of it.

Same thing happened with DevOps five, six years ago—everybody had to get on the bandwagon. I remember CEOs way back then going, “What is this DevOps thing?” Oh, man. You know, just talk to some of your engineers.

And what I can say, right, I have developed at least an internal personal perspective on what is not DevOps. So, if I can borrow the last 30 seconds of the mic for a second, here are some things I wrote as notes as I’m going back over the standard, re-reading it, going what I violently agree with from both others and myself, we did not have a chance to see this before it went live many times, right?

So, what I got from one of the higher order sections in Section 5 was this feeling of, like, what is not DevOps. And those things are burnout. DevOps is not burnout. You know, you’ve probably been burnt out if you’ve worked in DevOps before, so where is this coming from? Why is this the case? It’s not burnout, it’s not no help. You don’t get any help, go do this thing, you know? It’s not heroics. It’s not superheroes in capes, right? Single points of failure, as I call them. It’s not cliques—which, by cliques, I mean power silos. Huh-uh, there is no such thing as The DevOps Department, people. There’s no rogue decisions. There’s traceability in decisions. There’s accountability in decisions.

Leadership thrash—not easy to, if you’re really adopting this DevOps mindset and way of thinking about how to do things better, leadership thrash doesn’t really fit in. Toil and debt, right? One of my biggest things is, you know, I seek to eradicate toil, which is not easy. [Laughter] Just reducing it a little is nice, but it’s, and it’s probably pragmatic to say so, but really eradicating toil from other people’s plates and from your own, that’s a challenge, right? That’s kind of a life goal. And if we do this stuff together, right, if we say these are not the things we want, the question is how do we move towards something that isn’t those things, right, and that is closer to where we all align and agree, like, this is a better way of delivering software and doing it faster, right?

So, anyway, I’ll pause there.

Mitch Ashley: You know, one of the things I’d love to hear from both Sarah and Paul is, there’s always sort of that, “So what?” answer—question, right? “If we did this, what is the result? What’s the impact of it?” And I mean that in a positive way, I’m not being critical.

Paul Bruce: Yep.

Mitch Ashley: If this standard was widely adopted, how would it improve? How would it—what things are we wanting to improve and change from where we are today? Can you describe that in any way to kinda give myself and others maybe an idea about that?

Paul Bruce: I just did. People already implemented it.

Sarah Baker: Well, at the base, there’s the vocabulary, yeah.

Paul Bruce: Sorry, people are—

Sarah Baker: At the base, that is part of it. Sorry. Paul and I always get [Cross talk].

Alan Shimel: Sarah, go ahead. Paul spoke—you go.

Paul Bruce: Yeah, yeah.

Sarah Baker: Vocabulary is that first piece, making sure we’re all talking about the same framework. And so that, when we’re exchanging ideas, how did you do it, how did you do it—you know, not any one way to do it is gonna it, but knowing what your options are and talking about it with others and trying something out and figuring out if it works or not in your environment is one way to get everybody on the same playing field. But if you’re not talking about the same thing, you can’t do that.

So, it’s having the ability for a large corpus of options to apply to your situation. To me, that’s one of the biggest things that it provides, and it also gives you ways of interacting with the rest of the business that is not IT, and kind of, “Oh, this isn’t—it’s not just IT. You’re a stakeholder, you’re a customer.” And it includes all of those pieces for the collaboration and really helps support it.

So, to me, that’s what the standard brings. It widens the organization’s perspective a lot, and allows that cooperation to seep into the organization across all of these different pieces. Because to me, that’s how it started as DevOps, DevSecOps, DevOps Observation Ops. I mean, it grows because that’s part of its DNA is to include.

Paul Bruce: Yeah.

Sarah Baker: And so, it’s very natural that it has done that and it includes other parts of the organization into that basic thought processes. I totally could see DevOps marketing security—I mean, you see all that. That’s what’s, to me, the real advantage of thinking this way is that it includes the entire org.

Jayne Groll: Well, and first of all, utmost respect to Paul, Sarah, and the other 25 people that are working on this, because this is a gargantuan task, right? Trying to encapsulate something that creates a common framework, that has the purest intention and also, you know, if you think about the heart of why DevOps emerged in the first place, it emerged because we were not collaborating together, right?

So, you know, in the early days of IT—I always say I’ve been in IT longer than I really want to admit to—you know, there were 25 people that sat on the same floor, in the same office building, and we all knew each other and we went to happy hour. And then, you know, the tree grew and there were lots of branches and other things. So, you know, giving a central source of truth that everybody can kind of internalize, process, speak the same language—you know, IT, we have so many different languages, we’re like countries that are butt up right next to each other.

And I said, I have so much respect, because this is a gargantuan task. And Sarah, I agree with what you said, the purpose is really to take this need for collaboration and optimizing automation, right, so making automation essentially members of your team, right, and then taking that out into the business because every business is a technology organization, it’s—I’m sure you’re aware of the risks. You know, we’re not telling you anything that you’re not aware of, but as I said, I just have so much respect. Because it’s not gonna be an easy road, right? There are so many different opinions from vendors and from everyone who’s involved in this space that are going to have an opinion or whatever. And I think, you know, that’s something that everybody’s gonna have to deal with.

Again, the only thing I would suggest is build it in a way that it’s nimble—dare I use the word agile, so that—

Paul Bruce: So, this is already done, right?

Jayne Groll: Yeah.

Paul Bruce: Like, this is not a draft, this is not an initiative. This has already been done for the past four years and is now an official standard. So, the good news is, to your point, I think, about suggestions about how to do this, we are working on the second version of this draft already.

As soon as it was out, even before it was out, we knew there were things that we just couldn’t—we couldn’t spend the time properly addressing. Like I said before, there was a lot of refactoring, but there was a lot of careful avoidance of not already repeating what was already in a good security standard over here, or in a good risk management thing, or one of the folks that worked with us, Tafline Ramos, works at the ISO, right? And what is it, 29119, right, verification and validation, the processes—that was already stuff that’s already been, and great thinking and not slow, you know? Can fully be put into a modern, unicorn sneeze rainbows and fart sprinkles type approach as well as the large Fortune 100.

So, just to say, this is already—we’ve already put a ton of, it’s already out there, and the easiest way is, I mean, some people might be wondering, “Oh, yeah, but it’s a standard, so now I gotta pay for it?” Some standards, you do; some standards, you don’t. This one, IEEE, they cover their costs with the standards. The easiest way, if you wanted to get a free copy, become part of the new, the next version of this, right? See what we’ve done, poke holes in it, have collaboration, let’s work on it together, because that’s the point of this is to bring a framework of how we are working together in a more effective manner.

Jayne, I’m really sorry I cut you off.

Jayne Groll: No, no, you didn’t cut me off. Just a cautionary tale. One of the reasons ITIL kind of lost a lot of its momentum—and I’ll be very frank, I owned an ITIL training company for 15 years and I was a chief evangelist, but it took 8 years between version 3 and version 4. And so, it wasn’t built, it was a monolith.

Paul Bruce: Mm-hmm.

Jayne Groll: And I think that was—you know, in the meantime, lots of other things happened, and I think there’s a cautionary tale. I’m not suggesting you’re looking at eight years, please don’t misunderstand, but this market is so—

Paul Bruce: No, it’s probably about three, right?

Jayne Groll: Yeah, this market’s pretty fast. Sorry.

Paul Bruce: Our target is about three, between where we officially started and now it’s out and the next revision, at most, would be another three, right, that’s our target. It could be earlier or later than that.

Think about, we’re all citizens of the United States here, right? Or anybody in Canada?

Alan Shimel: Is that a HIPAA violation to answer?

Paul Bruce: Yeah, right.

Alan Shimel: Just kidding, just kidding, just kidding.

Jayne Groll: [Laughter]

Mitch Ashley: I’m not showing you my vaccine card.

Paul Bruce: I ask because, I ask because—

Alan Shimel: I didn’t wanna go there, but go ahead.

Paul Bruce: – we all know what the U.S. Constitution is and where it came from.

Alan Shimel: Mm-hmm.

Paul Bruce: Do we think that it was perfect and never has to be revised? Absolutely not. That’s what the Amendments are for. And arguably, I people wanna go back to the original version, there are some serious problems with that original version. Same thing with ITIL, same thing—remember with, I think you might have heard about The Agile Manifesto. You know, that was a drunken party with a bunch of white dudes, okay?

Jayne Groll: I know. [Laughter]

Paul Bruce: So, yeah, there were some good ideas that were encoded in there, but do they not have to be revised and worked out? Even Dave Thomas says agile is dead, long live agile. Like, what people have taken it to is not the point.

So, the goal of this is to really get a full perspective. To what Sarah was saying, it’s not just—I’ve talked with a lot of the DevOps Days, various different people from DevOps Days, from a number of different, like, The DevOps Enterprise Summit and stuff, and there are some people out there that are like, “No, DevOps is just about developers and operations and it’s about just these things, and if you start getting biz in there—no, no.” And it’s like, what a narrow perspective, because you know what, you had a good idea and then you screwed it up by not including other people, by not realizing there are meta learnings that come out of what you locally did—maybe, arguably, you did well—that apply broadly. And when they do apply broadly, they bring us back to the same premise, which is, we’re all in this together, right? We all win when we all win. As Tim O’Reilly might say, provide more value than you consume, right?

So, that’s where we intend on taking this. It’s not to turn into a bunch of agile consultants again or ITIL consultants, right?

Mitch Ashley: [Laughter]

Jayne Groll: Framework growers, that’s what we call it.

Alan Shimel: Yep. Guys, I gotta pull the plug on ya, I’m sorry, guys, and ladies. We are out of time. I think a great way to end this, though, is—Sarah, Paul, where can people get more information on the standard from the IEEE?

Paul Bruce: Sure. Google it, Google IEEE 2675, you’ll get to that page if you wanna buy a copy.

Alan Shimel: 2675.

Paul Bruce: I think without being a member, it’s like 99 bucks—so, look, you know, if you wanna buy it for yourself—

Alan Shimel: It’s not breaking the bank.

Paul Bruce: You probably also have, in your organization already somebody’s a member, your Risk and Compliance are probably already members to IEEE.

Sarah Baker: Yeah.

Paul Bruce: And again, like I said, the best way to get a free copy is to come work with us on what does the next standard mean. It’s not a huge effort and commitment like Sarah and I have put in. [Laughter]

Sarah Baker: [Laughter]

Paul Bruce: You can dip your toes in, see what makes sense, what works for you, and we love to—we include people in that effort.

Alan Shimel: Great. Well, Paul, Sarah, Jayne—thanks for joining us on our panel today. Mitchell, as usual, great job. This is another edition of DevOps Unbound in the books, check it out. Go check out the IEEE standard. We’ll be back in two weeks with a fresh show and a fresh topic. Until then, this is Alan Shimel, be strong, be well—Tech Strong. Take care, everyone. Bye bye.

[End of Audio]

July 7, 2022
EP 18: Does Standardization Disrupt Innovation?

Although everyone has their own definition of DevOps, it all comes down to creating better software faster, empowering development and operations teams and delivering value to customers. However, there really isn’t a standard approach to DevOps.

Should we standardize DevOps to introduce automation, avoid confusion and speed up the process? Will standardizing DevOps foster or disrupt innovation?

In this episode of DevOps Unbound, hosts Alan Shimel and Mitch Ashley are joined by Jayne Groll from the DevOps Institute, Paul Bruce from Tricentis and Sarah Baker from Airbnb to discuss the pros and cons of standardizing DevOps, the challenges of standardization and possible solutions. The video is below, followed by a transcript of the converstation.

Alan Shimel: Hey, everyone, welcome to another DevOps Unbound. If this is your first time catching a DevOps Unbound, welcome. DevOps Unbound is a biweekly video series where we talk about relevant topics in DevOps. In addition to the biweekly show, we do, it’s every four to six weeks, a live roundtable show where we invite the audience to participate and drive the discussion with online questions and comments and so forth, so we open it up to a live audience. Unfortunately, this show is not one of our live roundtables, it is prerecorded, but we have a great panel and I think you’re gonna enjoy it.

I’m gonna get into today’s topic in a second, but before we do, let me introduce you to today’s panel. First of all, I wanna introduce a business partner of mine and my friend, Jayne Groll. Jayne, why don’t you introduce yourself to the audience, if you don’t mind?

Jayne Groll: Thanks, Alan. Hi, everyone. I’m Jayne Groll, I’m CEO of The DevOps Institute, we’re a global member association and a certification body around topics related to DevOps. I’m really, really excited to be here and I’m hope everyone listening joins us at DevOps Institute and becomes a member.

Shimel: Fantastic. Welcome, Jayne. Joining Jayne, I’m happy to have Paul Bruce. Hey, Paul, welcome, and if you wouldn’t mind, you know, introducing yourself?

Paul Bruce: Yeah, hey, Alan. Good to be back. My name is Paul. In my full time job, I work with Tricentis in a number of different areas. I’m historically a performance and reliability nerd. In my off time, I organize a number of events, help to co-organize volunteer things like DevOps Days Boston, just did o11yfest this year about observability, we had that conversation, I think, with Christine Yen a couple months ago.

Shimel: Good stuff. Mm-hmm.

Bruce: And generally, I’m a people advocate. I had to pull DevOps out of my LinkedIn title because there were too many recruiters that I don’t need, because I’ve got a pretty good job. But also, because people advocate really describes what I care the most about, right? People are some of the hardest part of the DevOps people, process, and technology, really, software. So, I really focus my time on that.

Shimel: That’s great to have you back on, too, Paul—good stuff. Next, we have a first time guest on DevOps Unbound today, a new member of the band, Sarah Baker. Sarah, welcome to DevOps Unbound, if you wouldn’t mind introducing yourself?

Sarah Baker: Thank you. Wonderful. Welcome. My name is Sarah Baker, my pronouns are she and her. I’ve been working in Operations my entire career and I’ve moved into DevOps as something I always—I needed a name for it. I always wanted the people part of Ops and technology and DevOps was that. And I’ve been doing that as soon as I learned the term. And I’ve been moved and started working with Paul Bruce in the IEEE work group 2675, who is trying to create a standard for DevOps.

Shimel: Fantastic.

Baker: I work for—and today, I work as the Manager of Biztech in Airbnb.

Shimel: Thank you, and thanks for joining us. That sounds like a great place for you to do this. And then the last member of our panel today is my co-host and another business partner, a long-time friend as well, Mitch Ashley. Mitch, if you wouldn’t mind introducing yourself?

Mitch Ashley: You bet. Always good to have a good panel on with you, Alan. Mitch Ashley, I’m CEO of Accelerated Strategies, an analyst firm that’s focused on DevOps, and also on cloud native, cyber security, and digital transformation. I come to DevOps both as a practitioner and a vendor leveraging it, so very interested in hearing the perspective of folks on our topic today. So, thanks for joining us, everybody, too.

And by the way, our DevOps Unbound is sponsored by Tricentis. I think you may have mentioned that, right, Alan?

Shimel: No, I think I didn’t, Mitch, but thanks for picking it up for me. [Laughter]

Groll: [Laughter]

Ashley: I was trying to give you credit where credit may not be due.

Shimel: Yeah, no, I don’t wanna take credit when I messed up. Yeah, DevOps Unbound is sponsored by Tricentis, and many thanks to them for their sponsorship. It makes all of this happen.

So, let’s turn to the topic at hand today, guys. You know, when I first started devopsy.kinsta.cloud eight years ago, I met Jayne maybe a year, within a year of that or a year and a half of that. One of the interesting things about DevOps is, there was no manifesto. There was no hard definition of what is DevOps and what is not DevOps, you know, contrary.

And ever since then, it’s been a double-edged sword. In some ways, it’s helped DevOps grow, it’s helped DevOps stay current over the last 8 to 10 years as the world has changed, DevOps has changed along with it. On the other hand, though, we’re still dealing with the, “So, what is DevOps?” Right? “What exactly is DevOps and what exactly is not DevOps?” which is sometimes harder than what is DevOps.

And as we sit here now, August, 2021, there really still is not a quote-unquote standard for DevOps. There is no standard DevOps. It is what you want it to be, right? As I think Andrew Clay Shafer said, “The DevOps you get is the DevOps you deserve,” right? But have we outgrown that stage? You know, that seems like a terrible twos stage of DevOps to some; to others, it’s what kept it cool. Has DevOps matured? Do we need standardization? Will it be something that kills the goose that lays the golden eggs?

We’re gonna discuss that today, and I’m interested in all of your views. Jayne, as the CEO of DevOps Institute, how many people have taken certified DevOps classes and certifications with DevOps Institute? It’s gotta be tens of thousands.

Groll: Yeah, about 25,000 so far. So, it’s a pretty large community.

Shimel: Mm-hmm.

Groll: And if you don’t mind, I wanna kind of just lay the stage, because I’m really interested in the standardization initiative. So, you know, I had a privilege of seeing, going to DevOps Days in 2012 in California. So, if you can imagine, it was in an old, dusty data warehouse, right, and it was at the very, very early stages. And so, one of the reasons DevOps Institute emerged was because there was a lot of really cool things here culturally, from an automation perspective, right, doing things faster, collaboration.

And so, we started up DevOps Institute because we wanted to make sure the humans were represented. And I love that Paul and Sarah in particular both represented people. The problem with that is, at that point, it was very, very open, it was very kind of organic. You know, it was really a group of passionate people that were trying to just change the way IT operates, right, from a people, process, and technology perspective.

What happened after that, though, is that there’s so much noise about DevOps that if I were an enterprise CIO right now, my head would explode, right? Now, is there one right way to do DevOps? No. Is it only gonna get you there with automation? No. You know, is there a very, very strong human element—absolutely.

So, it’s a double-edged sword, Alan, as you said, is that we wanna be able to kind of scale down, right, some of the common language, some of the common definitions. I always say I’m married to a CPA, they have generally accepted accounting principles; maybe someday, we have generally accepted IT principles. But how do we distill the noise, right, and everyone having a different interpretation of how to do DevOps and what it is compared to, let’s get past the, “what is it?” We’ve spent, what, 10 years trying to figure out what it is, to, “how do we do this?” Right?

Bruce: Mm-hmm.

Groll: And it isn’t just one roadway that takes you there. So, I think it’s a challenge. I mean, we introduced foundational certifications around DevSecOps and SRE and DevOps Foundation and DevOps Engineering, really, to create kind of a common vocabulary more than the, “here’s the single way to introduce CI/CD.”

So, I don’t know if that helps kinda set the stage, but I think it’s a really big challenge right now that, if we standardize it, we run into the risk of what happened with ITIL where it couldn’t keep pace, right, and it became religious. I come from the ITIL space, right, so it’s like, open chapter 1, verse 3 and sing a hymn before you introduce change management to how do we then, on the other end of the spectrum, it’s so open and so undefined that it’s really complicated for legacy, I call them heritage organizations, to be able to move from this step to this step.

Bruce: Mm-hmm.

Shimel: The church of ITIL. Paul, what’s your feeling on that?

Bruce: Well, everybody’s on a journey, right? Your personal journey, your professional career, whatever, maybe you go do a walkabout on a particular topic to learn more about that. And so, we started this venture, there was an early round of, “Who wants to be involved in something like this?” in 2016. I answered a call from Bob Aiello and Lynn Carter, who were kind of forming this idea of, there’s a bunch of people who really care deeply who have practitioner practical experience in the field. And the early part of this process was just learning, kinda level setting on what we have done, right?

Jayne mentioned that it’s hard, maybe, to have accepted IT standards, even though there are standards, right, that not every organization applies the same way. I don’t think that invalidates some of the general principles that we know to be true, which is, you know, you ship broken software, you hurt people, you hurt yourself, right? But those are high level. How do we break this apart and start to make sense of the world, as you said, the heritage, Jayne, you said the heritage organizations—what is so wrong, what’s going on that we have these kind of security problems, these performance problems, this inability to be competitive in terms of acceleration and stuff.

And so, I think the purpose of a standard is not necessarily to force people to do something a certain way. I think it’s simply just kind of like, if you’ve ever had the Christmas ornaments or just ornaments box that has the insert that allows for things to be put in careful places and also work together as a unit, right, to provide a normative, not a prescriptive standard, but a normative standard to say, “Look, these processes that you already know? Well, you already followed these from, let’s say, 12207, right?” These processes around supply acquisition, knowledge management, human resources? Right, human resourcing in DevOps is a big problem, at least in the Boston area. Try to hire an SRE—there’s only about 15,000 to 20,000 in the United States, legitimately. There’s a reason for that demand.

So, how do we think about the processes we already know and start to say, how are these things different because there are some accepted principles and practices around DevOps? Now, the practices are not things that you would ever wanna dictate in a standard. This is not the same granularity level as some other standards that dictate how to encode time formats. That’s very important at that level. But the level that we were working on was how to level set across the things that, especially organizations in high compliance and high risk industries, right, risk-averse industries—how do they take the practices and processes that they know from a process standard and start to go, “I understand how to plug, now, what the DevOps principles are into the standard to encourage both of those practices in a more predictable manner?”

So, when we did all this work—it’s taken years, right, of a lot of learning collaboration between a whole host of people I don’t have even time to list out, but a lot of people from a lot of various different aspects of software have a lot of experience in those aspects. You know, it took synthesis and refactoring, and I was up nights and weekends just rewriting some of the statements, you know? And each of these, it’s a line to 12207, so there’s multiple processes, process declarations like quality management, quality assurance, verification and validation.

Like I said, these project enabling processes and then these technical processes, and each of those process sections have outcomes, activities, and tasks. Things that are likely to occur in this area, right, as well as, regardless of how you do this, right, not dictating what the DevOps looks like, it’s outcomes of these things that are auditable, that not compliance but conformance. That you can confirm at various levels to these outcomes to say, if it’s important to get this right, when you hit the piñata, what comes out should be candy, not garbage, right?

So, I’ll pause there, because I wanna give Sarah a chance to kinda provide perspective, because she’s also been working a lot with us, for all those years. [Laughter]

Baker: I think I counted 27 people on the final author list for the IEEE.

Bruce: Yeah.

Baker: And it was many, many weeks of arguing, reading together the exact language. And I agree very much with some parts of what Paul says, and I wanna step back and talk a little bit about how I see, you know, what, to me, was the big shifts. And so, the way we wrote the doc was to kinda look at the 12207 and say, “How does DevOps change it? How has it changed the game? What are the perspectives that you need to have in mind in order to get the outcomes that Paul’s talking about, there?”

And so, when we were writing it, we were writing it to that. How is this different, and to what extent do you wanna consider these areas? It’s a framework of thinking. At its largest level, it’s a framework of, for me, the value chain of delivery of software. And it’s not—and it uses many of the concepts that come out of learnings of industrial engineering, way back in the ‘40s, ‘50s, ‘60s. But it had never really come into a lot of the thinking of software, because software is different. And the more I was working and kind of digging into what are the concepts underneath DevOps, I came quite aligned with a lot of industrial engineering concepts about how things flow and how things move back and what the peaceful aspects are in that.

And so, that—actually, if you read through the standard, you’ll see a lot of those flow pieces and all of the pieces that you then say, “Oh, it’s the feedback loops, yeah, lots of feedback. Collaboration, it’s all there.” And it’s just applying a lot of those learnings into software engineering, to me. And it was stuff I was like, “Oh, it’s so wonderful to have this.”

And the other thing, one of the big learnings that I think I brought into the conversation is how—and Paul will back me up on this—how security for a lot of us changed slightly as we started walking our way through the 2675 work. The terms of risk became a very interesting concept that flowed through the document more than I would have expected.

Bruce: Mm-hmm.

Baker: And so, there was some learning within the totality of our team as we wrote this. It was quite fascinating.

Ashley: I’m really fascinated to hear from both of you that have been working on this, because it’s not something I’ve been involved in. I sorta have a mixed history with standards, because I’ve worked in areas like networking and things like that where standards are very beneficial or really fundamental, but I’ve also learned standards are kind of what you’re gonna do, not how you’re gonna do it. Because we ran a test lab that, even though it says we’re gonna do least cost routing in a network device this way, people implement it differently and they don’t always work together. So, it’s not a nirvana, but it’s also not a pariah, either.

Bruce: Mm-hmm.

Ashley: So, what I wrestle with here is that, I think some of the thinking—and Jayne can speak to this, but innovation happens so quickly now. So many things are created without standards; maybe they evolve into standards, maybe they don’t. And it doesn’t bother me that there’s lots of noise around DevOps, because we’ve all seen the cycles, the hype cycles, right? If it’s worthwhile, everyone and their brother, sister, cousin, uncle will all jump on the bandwidth and call what they’re doing fill in the blank—it’s AI, it’s DevOps, it’s whatever. That’s just part of our industry. And it’ll either fizzle—you know, value stream management, is it a real thing? We’ll see. It’ll fizzle or it’ll happen, right, if it’s a real thing. And DevOps has proven itself not only is it a real thing, but other parts of the organization now see an opportunity to play, to participate, to become part of the software creation process.

Bruce: Mm-hmm.

Ashley: And I think that’s what’s so powerful about DevOps—it’s not about a technology, it’s about how we create software. And if you were gonna start out, you know, Jayne, when you went to that meeting in 2012 when you said, “We’re gonna go create a standard for completely doing software differently because we have cloud and we have the ability to automate and we were gonna change the software architecture,” you couldn’t have known how to do that. But being the industry would’ve, you know, the antibodies would’ve crawled all over all of us and stopped it. So, I think there’s a lot of power in the innovative, organic nature of it.

And I don’t want DevOps to turn into ITIL, [Laughter] because that’s sort of taken on a life of its own, and now it’s trying to catch up and it’s done some good things, too. So, I wrestle with trying to constrain it when I think it’s real power is the innovation behind what we’re doing.

Bruce: Yeah, so, before I—

Baker: If I could take a moment—

Bruce: – yeah, go ahead.

Baker: – I’d like to take a moment and call out something. Part of the problem with ITIL is like, it’s ITIL. And, you know, a gazillion managers said, “ITIL, let us get a hammer and hit you over the head with it.” And DevOps, fortunately doesn’t have that problem. It has, you know, a little fuzzier in its definition, but the great thing about DevOps is that it has that sort of fuzzy edges. You can’t, it’s really hard to beat someone over the head with it. You can try. I’ve seen it happen, you know? Everybody’s a DevOps engineer now, but it’s not necessary.

And what people talk about is not that, but the work, you know? It’s not, “We’re conforming with ITIL,” it’s like, “We’re doing DevOps.” The doing part is the important part, not the compliance part. So, when you say, when you hear people talk about it, they talk about it differently, and that’s the good thing.

I use ITIL, I just don’t tell anybody the word.

Jayne Groll: Which is a shame. It’s such a shame because, you know, I come from the ITIL space, and in the early days, this was not what the intent was to be. It was very much like DevOps in terms of, “Let’s help IT grow up,” right, in terms of some things.

And, you know, to what you’re all saying, you’re absolutely right. A framework, whether it’s a standard, is a guideline, right? It helps you with the journey, as Paul said. And so, if I wanna kinda check, check, check—you know, I’ve worked with some of the ISO standards, right? So, in the ITSM space, there was ISO 20,000, 27,000 for security, right? And it basically, like, in the one or service management says, “You should record all your changes.” It doesn’t say how to record it, it doesn’t—it’s a really great practice, you should do this.

The problem, sometimes, with standards—and I’m sure you know this and it’s a risk—the pure intention is pure. The ability to weaponize it, right, from the auditors and from others is a real risk, right? Because we’ve seen that with other standards as well, where it becomes more about the compliance than it is about how having it being a guiding light. So, I think there’s always a risk there.

And then the other risk is, you know, think about observability, right? So, observability has been trending, what, for a year, maybe two, right? Four—okay, but really mainstreaming, like, talking about observability as kind of a mainstream practice, right? And I will share with you, Mitch, to your point, when we launched DevOps Institute in 2015, we were not welcomed with open arms, right? We were vilified for trying to put some boundaries around this.

Now, you know, move forward seven years and I think we’ve overcome a lot of those and we have some that were detractors or really great supporters. But I think they were concerned that it would become weaponized or commoditized or whatever.

So, I’m just gonna say one last thing because I think it’s important. Commoditization of knowledge, which, this is kind of in support of the standard, right? Commoditization of knowledge where we make sure it’s available to everyone, some people see that as a negative—it’s not. What would happen if the whole world, right—every IT organization, every IT professional decided to take this standard and use it as a guiding light, according to the needs of their organization? They weren’t worried about the audit, they got trained, they shared knowledge—wouldn’t that be amazing? But that’s commoditization.

So, I think the risk of good versus evil on initiatives like this is real, but I also think that distilling it to everybody, kind of like accountants have done, right, is important because IT needs to grow up.

Bruce: Yeah, well—

Ashley: Well, and if you look at the accounting standards, they don’t tell you how to do it, they tell you what to do.

Groll: Right.

Ashley: It isn’t prescriptive in the how very much, so it’s very much like an IEEE standard or whatever.

Bruce: Yep. Well, first off, I forgot to mention when we first started—I speak as an individual contributor. If it isn’t abundantly clear, [Laughter] I don’t speak for the IEEE, and I don’t speak for the other people who have spent years contributing to this meaningfully.

So, when I say certification processes inherit all the exact same things you just mentioned as problems—weaponizing, actually low ROI maybe in some cases—we see these deficiencies and these outcomes that aren’t so great. And if you’re somebody who’s just gonna sit back and say, “I’m not willing to hold myself accountable” to stand up and say, “What does this thing actually mean like a real engineer should, you know, to start to break apart the problem and see what are the components, how does this thing work and how do I want it to work? How does it work best for the people around me as well?” If you’re not willing to do that, then I would call you the nay-sayer, you know what I mean? Like, not any one in particular, but that would be a nay-saying, like, let’s avoid accountability, let’s avoid doing what we know needs to be improved?

Continuous improvement is a huge element that is all throughout the entire standard. It’s one of the things that’s identified as some of the core principles in an ISO study that was done before we started in on this standard to see what are the common themes of people, when they’re really feeling like there is this DevOps mindset, this culture, these practices—what do they mean by it?

And a number of things came out. One was a high degree of automation, right? Okay, well, that’s very tactical. No matter how you do it, right—high degree of automation. Duh, right? How about effective communication and collaboration? How about shifting things and continuous everything? The notion of, that these things are not this one time and then three years later, you get to come back. No, no, no. If it’s a good idea now, maybe don’t bite off a three-year apple. Maybe take a bite, but know that you started in, there’s a continuous improvement process.

I can say, we mentioned earlier about a holy war that might exist when you start getting into what is DevOps and what is not DevOps. Like, I started—the best way I can describe to people, because like I say, half of my day is spent on and off of Slack with people who are actually doing, working this out in a highly statistical, large distribution across the country, you know, and sometimes outside the U.S., too, just time zone supply.

But I can say, for sure, after seeing the complete garbage Dumpster fire where nobody is willing to stand up and say, “Hey, aren’t these things common and standard?” And oh, by the way, not vendors that have something to push, right? I mean, that’s, I think, Jayne, where you were talking about maybe observability is now a thing. You know, the only reason why it’s a thing for the most part is because it’s in our face now because all the vendors are hash tagging the crap out of it.

Same thing happened with DevOps five, six years ago—everybody had to get on the bandwagon. I remember CEOs way back then going, “What is this DevOps thing?” Oh, man. You know, just talk to some of your engineers.

And what I can say, right, I have developed at least an internal personal perspective on what is not DevOps. So, if I can borrow the last 30 seconds of the mic for a second, here are some things I wrote as notes as I’m going back over the standard, re-reading it, going what I violently agree with from both others and myself, we did not have a chance to see this before it went live many times, right?

So, what I got from one of the higher order sections in Section 5 was this feeling of, like, what is not DevOps. And those things are burnout. DevOps is not burnout. You know, you’ve probably been burnt out if you’ve worked in DevOps before, so where is this coming from? Why is this the case? It’s not burnout, it’s not no help. You don’t get any help, go do this thing, you know? It’s not heroics. It’s not superheroes in capes, right? Single points of failure, as I call them. It’s not cliques—which, by cliques, I mean power silos. Huh-uh, there is no such thing as The DevOps Department, people. There’s no rogue decisions. There’s traceability in decisions. There’s accountability in decisions.

Leadership thrash—not easy to, if you’re really adopting this DevOps mindset and way of thinking about how to do things better, leadership thrash doesn’t really fit in. Toil and debt, right? One of my biggest things is, you know, I seek to eradicate toil, which is not easy. [Laughter] Just reducing it a little is nice, but it’s, and it’s probably pragmatic to say so, but really eradicating toil from other people’s plates and from your own, that’s a challenge, right? That’s kind of a life goal. And if we do this stuff together, right, if we say these are not the things we want, the question is how do we move towards something that isn’t those things, right, and that is closer to where we all align and agree, like, this is a better way of delivering software and doing it faster, right?

So, anyway, I’ll pause there.

Ashley: You know, one of the things I’d love to hear from both Sarah and Paul is, there’s always sort of that, “So what?” answer—question, right? “If we did this, what is the result? What’s the impact of it?” And I mean that in a positive way, I’m not being critical.

Bruce: Yep.

Ashley: If this standard was widely adopted, how would it improve? How would it—what things are we wanting to improve and change from where we are today? Can you describe that in any way to kinda give myself and others maybe an idea about that?

Bruce: I just did. People already implemented it.

Baker: Well, at the base, there’s the vocabulary, yeah.

Bruce: Sorry, people are—

Baker: At the base, that is part of it. Sorry. Paul and I always get [Cross talk].

Shimel: Sarah, go ahead. Paul spoke—you go.

Bruce: Yeah, yeah.

Baker: Vocabulary is that first piece, making sure we’re all talking about the same framework. And so that, when we’re exchanging ideas, how did you do it, how did you do it—you know, not any one way to do it is gonna it, but knowing what your options are and talking about it with others and trying something out and figuring out if it works or not in your environment is one way to get everybody on the same playing field. But if you’re not talking about the same thing, you can’t do that.

So, it’s having the ability for a large corpus of options to apply to your situation. To me, that’s one of the biggest things that it provides, and it also gives you ways of interacting with the rest of the business that is not IT, and kind of, “Oh, this isn’t—it’s not just IT. You’re a stakeholder, you’re a customer.” And it includes all of those pieces for the collaboration and really helps support it.

So, to me, that’s what the standard brings. It widens the organization’s perspective a lot, and allows that cooperation to seep into the organization across all of these different pieces. Because to me, that’s how it started as DevOps, DevSecOps, DevOps Observation Ops. I mean, it grows because that’s part of its DNA is to include.

Bruce: Yeah.

Baker: And so, it’s very natural that it has done that and it includes other parts of the organization into that basic thought processes. I totally could see DevOps marketing security—I mean, you see all that. That’s what’s, to me, the real advantage of thinking this way is that it includes the entire org.

Groll: Well, and first of all, utmost respect to Paul, Sarah, and the other 25 people that are working on this, because this is a gargantuan task, right? Trying to encapsulate something that creates a common framework, that has the purest intention and also, you know, if you think about the heart of why DevOps emerged in the first place, it emerged because we were not collaborating together, right?

So, you know, in the early days of IT—I always say I’ve been in IT longer than I really want to admit to—you know, there were 25 people that sat on the same floor, in the same office building, and we all knew each other and we went to happy hour. And then, you know, the tree grew and there were lots of branches and other things. So, you know, giving a central source of truth that everybody can kind of internalize, process, speak the same language—you know, IT, we have so many different languages, we’re like countries that are butt up right next to each other.

And I said, I have so much respect, because this is a gargantuan task. And Sarah, I agree with what you said, the purpose is really to take this need for collaboration and optimizing automation, right, so making automation essentially members of your team, right, and then taking that out into the business because every business is a technology organization, it’s—I’m sure you’re aware of the risks. You know, we’re not telling you anything that you’re not aware of, but as I said, I just have so much respect. Because it’s not gonna be an easy road, right? There are so many different opinions from vendors and from everyone who’s involved in this space that are going to have an opinion or whatever. And I think, you know, that’s something that everybody’s gonna have to deal with.

Again, the only thing I would suggest is build it in a way that it’s nimble—dare I use the word agile, so that—

Bruce: So, this is already done, right?

Groll: Yeah.

Bruce: Like, this is not a draft, this is not an initiative. This has already been done for the past four years and is now an official standard. So, the good news is, to your point, I think, about suggestions about how to do this, we are working on the second version of this draft already.

As soon as it was out, even before it was out, we knew there were things that we just couldn’t—we couldn’t spend the time properly addressing. Like I said before, there was a lot of refactoring, but there was a lot of careful avoidance of not already repeating what was already in a good security standard over here, or in a good risk management thing, or one of the folks that worked with us, Tafline Ramos, works at the ISO, right? And what is it, 29119, right, verification and validation, the processes—that was already stuff that’s already been, and great thinking and not slow, you know? Can fully be put into a modern, unicorn sneeze rainbows and fart sprinkles type approach as well as the large Fortune 100.

So, just to say, this is already—we’ve already put a ton of, it’s already out there, and the easiest way is, I mean, some people might be wondering, “Oh, yeah, but it’s a standard, so now I gotta pay for it?” Some standards, you do; some standards, you don’t. This one, IEEE, they cover their costs with the standards. The easiest way, if you wanted to get a free copy, become part of the new, the next version of this, right? See what we’ve done, poke holes in it, have collaboration, let’s work on it together, because that’s the point of this is to bring a framework of how we are working together in a more effective manner.

Jayne, I’m really sorry I cut you off.

Groll: No, no, you didn’t cut me off. Just a cautionary tale. One of the reasons ITIL kind of lost a lot of its momentum—and I’ll be very frank, I owned an ITIL training company for 15 years and I was a chief evangelist, but it took 8 years between version 3 and version 4. And so, it wasn’t built, it was a monolith.

Bruce: Mm-hmm.

Groll: And I think that was—you know, in the meantime, lots of other things happened, and I think there’s a cautionary tale. I’m not suggesting you’re looking at eight years, please don’t misunderstand, but this market is so—

Bruce: No, it’s probably about three, right?

Groll: Yeah, this market’s pretty fast. Sorry.

Bruce: Our target is about three, between where we officially started and now it’s out and the next revision, at most, would be another three, right, that’s our target. It could be earlier or later than that.

Think about, we’re all citizens of the United States here, right? Or anybody in Canada?

Shimel: Is that a HIPAA violation to answer?

Bruce: Yeah, right.

Shimel: Just kidding, just kidding, just kidding.

Groll: [Laughter]

Ashley: I’m not showing you my vaccine card.

Bruce: I ask because, I ask because—

Shimel: I didn’t wanna go there, but go ahead.

Bruce: – we all know what the U.S. Constitution is and where it came from.

Shimel: Mm-hmm.

Bruce: Do we think that it was perfect and never has to be revised? Absolutely not. That’s what the Amendments are for. And arguably, I people wanna go back to the original version, there are some serious problems with that original version. Same thing with ITIL, same thing—remember with, I think you might have heard about The Agile Manifesto. You know, that was a drunken party with a bunch of white dudes, okay?

Groll: I know. [Laughter]

Bruce: So, yeah, there were some good ideas that were encoded in there, but do they not have to be revised and worked out? Even Dave Thomas says agile is dead, long live agile. Like, what people have taken it to is not the point.

So, the goal of this is to really get a full perspective. To what Sarah was saying, it’s not just—I’ve talked with a lot of the DevOps Days, various different people from DevOps Days, from a number of different, like, The DevOps Enterprise Summit and stuff, and there are some people out there that are like, “No, DevOps is just about developers and operations and it’s about just these things, and if you start getting biz in there—no, no.” And it’s like, what a narrow perspective, because you know what, you had a good idea and then you screwed it up by not including other people, by not realizing there are meta learnings that come out of what you locally did—maybe, arguably, you did well—that apply broadly. And when they do apply broadly, they bring us back to the same premise, which is, we’re all in this together, right? We all win when we all win. As Tim O’Reilly might say, provide more value than you consume, right?

So, that’s where we intend on taking this. It’s not to turn into a bunch of agile consultants again or ITIL consultants, right?

Ashley: [Laughter]

Groll: Framework growers, that’s what we call it.

Shimel: Yep. Guys, I gotta pull the plug on ya, I’m sorry, guys, and ladies. We are out of time. I think a great way to end this, though, is—Sarah, Paul, where can people get more information on the standard from the IEEE?

Bruce: Sure. Google it, Google IEEE 2675, you’ll get to that page if you wanna buy a copy.

Shimel: 2675.

Bruce: I think without being a member, it’s like 99 bucks—so, look, you know, if you wanna buy it for yourself—

Shimel: It’s not breaking the bank.

Bruce: You probably also have, in your organization already somebody’s a member, your Risk and Compliance are probably already members to IEEE.

Baker: Yeah.

Bruce: And again, like I said, the best way to get a free copy is to come work with us on what does the next standard mean. It’s not a huge effort and commitment like Sarah and I have put in. [Laughter]

Baker: [Laughter]

Bruce: You can dip your toes in, see what makes sense, what works for you, and we love to—we include people in that effort.

Shimel: Great. Well, Paul, Sarah, Jayne—thanks for joining us on our panel today. Mitchell, as usual, great job. This is another edition of DevOps Unbound in the books, check it out. Go check out the IEEE standard. We’ll be back in two weeks with a fresh show and a fresh topic. Until then, this is Alan Shimel, be strong, be well—Tech Strong. Take care, everyone. Bye bye.

[End of Audio]

September 19, 2021
Next Up: Portable CI

One thing that we’re very good at in IT is breaking new ground, coming up with ideas that work astoundingly well, getting broad adoption, then standardizing them for interoperability. When a new technology (looking at you, cloud) has problems with standardization and interoperability, we find a way around vendors’ reluctance to give you freedom of choice. For cloud, for instance, we found another great technology – containers – that greatly limits our lock-in to a given cloud vendor’s fare. Of course, whether standards or workarounds are the answer we arrive at, there are always wrinkles. Vendors are certainly not motivated by interoperability; they want your regular cash infusions, and interoperability could be more of a drain on them than a feed of new customers. Particularly in today’s environment, where vendors sometimes think that doing “to” customers is an acceptable substitute for doing “for” customers. We have to work around things like “embrace and expand,” which is still very real, and deploying containers to cloud A versus cloud B still has a bit of vendor-specific work, but we have enough to get it done.

As continuous integration (CI) has become critical to an increasing number of organizations’ IT processes, the time has come to do the same with CI tools. Standardization is a good first goal, but it is more difficult here than in many areas, because the topic is so broad. An app might be built in one tool and tested in another, or it might be built via the use of shell scripts while tested with a UI tool, etc. It is not an easy solution to build, but it is an idea whose time has come – particularly with the cloudification of the space. We now have full-on CI systems that are in the cloud, and which hook you in with custom instructions. We’ve already had one large DevOps vendor essentially tell their entire user base, “We’re moving you to the cloud, unless you pay these inflated fees,” and others that never offered options for traditional architectures at all.

Yet, we know apps move from in-house to cloud (and though it is uncool to mention, move back), and organizations are motivated by cost containment and mobility more than by what their chosen vendor wants them to do.

So, it is time for some bright company or OSS team to put together a standard and a tool that implements said standard. It will be a lot of work, to make portability between CI tools that came from widely disparate roots – some from build, some from test, some even from deployment. But we’ll be needing it. A while back, everyone was a Puppet shop. Now, it seems, everyone is an Ansible shop. In simple terms, everyone will inevitably be a [something else] shop, because nothing lasts forever. So, a tool providing CI mobility between tools will definitely have a market – smaller today, but eventually large. We don’t need Yet Another CI Tool, we need that portability.

I’m sure it’s coming. History does offer glimpses of the potential future, and we’ve seen this cycle before. I’m just saying, the time is now, not five years from now. We can target the OS of our choice and the cloud vendor of our choice, using containers to simplify the differences in host OS/vendor. The ability to use the CI tool of our choice is the logical next step.

I haven’t heard of a project or company working on this yet; if you have, drop me a link in comments or email (I prefer comments, so others can look at your suggestion too, but whatever works for you), and I’ll take a look. It would be cool to support this kind of effort, when it eventually comes about.

April 29, 2021
We All Have to Have Standards

I was working on an e-book recently about the state of the market for certain DevOps toolsets, and got really interested in how standardized organizations are becoming. We have been on this roller coaster of changing technology and different teams making different choices in language, libraries, platforms and toolchains. We all knew that couldn’t go on forever, but I started to really get into the idea of “How much standardization is being introduced?” While talking with vendors about their experience, it seems that enterprises are finally attempting to standardize, at least in the platform and toolchain areas.

Not the type of “technology by edict” standardization we used to see, but a checklist of “If your project fits these criteria, use this platform. If it fits those criteria, use this toolset for your build chain.” Which is a good compromise between the days of “We’re a Cisco shop” or “We’re an Oracle shop,” and the days of “Yeah, first developer on a project chooses the language, database, etc.” You limit the amount of technical debt and vendor/OSS project dependency, while offering teams options for how best to get the job done.

I’m excited about the change, and it is one of the things driving much-needed consolidation in core DevOps markets. I won’t go beyond that, as you’re supposed to read the e-book when it gets released, but it’s an exciting time to be in DevOps. We’re getting more and more tools, better integrations and even some full lifecycle toolsets starting to become clear.

Our shop is small, and we’ve exercised standards all along, just because we don’t have the time for everyone to train on five different CI products, so we use one. But for larger organizations with more diverse needs, standardization will offer savings in both maintenance and cross-training.

Consider that at one point there was no standardization on vehicles–everything from tires to engine oil was custom to the brand you owned. Now, it is quite often the case that the engine in your vehicle is the same engine as in a competitors’ vehicle (VW using Saab engines for years is a good example), and that means maintenance is streamlined. Tooling with onboard computers makes maintenance even faster, much like tooling monitoring/reporting is doing for the DevOps iteration. It’s a good time to be in the field, watching as things unfold.

Stay aware of what your vendors are doing, and what their competitors are doing. One of the reasons DevOps exploded is because tools and processes became static and weren’t as productive as they could have been. Don’t repeat that mistake, keep an eye on rapidly changing developments and adopt what suits your organization. You’re rocking it now, take a bit of time to make sure it stays that way.

And consider standardizing some of your toolset. The fewer tools to maintain, the more time to work on productive issues. And the fewer toolchains a DevOps team member has to know to be productive on multiple projects, the more productive they can be. Agility applies here also.

— Don Macvittie

March 31, 2020
Standardization, De Facto Style

The first decade or so of DevOps had one truth to it: It was about change. Not just change in the way that IT worked, but change in the way DevOps worked—particularly in the tools space, where products and product preferences both are in flux. We’re still seeing a massive change, but increasingly the effect is more like the ripples created when a rock is thrown into a pond than a tsunami, dumping change upon change.

You could look at this one of two ways (and no doubt those who have more reason to dig into details than I have already done so): Either the slow but steady standardization typified by tools such as Jenkins and Puppet have enabled participation of enterprises in the DevOps life cycle, or the demands of enterprises for some amount of stability in their massively complex systems have driven standardization.

Either way, the result is the same. We are seeing a lot of change further out, but the core technologies for build/test/deploy are settling into a few products by a few vendors. That is good for adoption, even if you would argue that it is bad for innovation. It means that skill sets are, at least to a certain extent, portable across DevOps teams and organizations, which for a long while was not true. When I was knee-deep in deployment technology, knowing how to use product A did not mean you knew how to use product B. The more people using one or the other, the better for employee mobility and the pool of available resources, as both people and support tools like standardized scripts.

I recently was going through the offerings of a service provider in a space that doesn’t traditionally have DevOps enablement. The company’s offering included DevOps, so I drilled down. Seeing the company supported Jenkins, Jira and Xebia Labs made me feel better about the program it was putting together. It meant the company was adapting mainstream tools to a specialty market.

That’s what spurred this blog. It’s been a long time that these things were seen as “new and shiny”; now, for a service provider to include them as proof it is serious about customers’ problems shows just how far we have come.

There’s still a long way to go. The DevSecOps community is currently in the throes of growth, and lots of outer-edge DevOps tools are incompatible with each other and chosen per shop without a clear market leader. But we’re getting there. And at this point, a person going into DevOps who asks me what they should know will actually get an answer of “Learn X, Y, Z” rather than “You should learn X, but pick up some of X.1, X.2, and A too, then there’s Y …”

The thing is, though de facto standardization is happening, to many (particularly enterprise) shops, this is all still new. So if you don’t know the recognizable tools yet, don’t worry too much; there will be opportunity to learn as they are rolled out across a given org.

— Don Macvittie

February 27, 2018