The Goals and Reality of DevOps

— with Nilesh Gule, Enterprise Architect

'You build it, you run it' is the DevOps aspiration every org repeats. Nilesh Gule, Enterprise Architect and Docker Captain, on 21 years of watching what actually happens between that slogan and reality.

Watch or listen on your favourite app

https://youtu.be/imB3T5syjUA?si=j4I4EHEB9lnywDei

https://open.spotify.com/episode/40gluGW2lmM1BAIiawXTaE?si=_sorGFU9SbSIwmyKnbFdGA

https://podcasts.apple.com/us/podcast/the-goals-and-the-reality-of-devops-with-nilesh-gule/id1750189197?i=1000672259114

Key Points
Full Transcript

"You build it, you run it" is the line every organisation repeats about DevOps. Nilesh Gule has spent 21 years watching what actually happens between that line and the org chart — and it rarely looks the same twice.

Gule is an Enterprise Architect, Microsoft Most Valuable Professional, and Docker Captain. He started his career as a developer in an era when that meant something narrower than it does now: write the code, hand it to a release management team, and stop thinking about it. "We never really worried about how the software was packaged," he told Jon Scheele on this episode of The Loop Asia. "This team would then take it. They would use some scripts. They would deploy it. And then when issues came, it became like a big investigation" — hunting for a root cause across a boundary nobody on either side fully understood.

That boundary, and the dysfunction it created, is the actual origin story of DevOps. Not a methodology invented top-down, but a response to a specific, recurring failure mode.

The thing that used to be a topic is now a button

Gule dates the shift precisely. Continuous integration — the practice of building software automatically on every change — was a live debate in 2007 and 2008. "If you could just build your software continuously, continuous integration... was a big topic," he said. Now it is not a topic at all. "People can just click a button and say, this is my repository, build it and deploy it to my cloud provider or my target environment."

That maturity curve is real, but Gule is careful not to let it flatten the harder problem underneath it. Tools got easier. Organisations did not get simpler. He has worked with mid-size companies and with organisations running more than 10,000 developers, and the tooling was the least of the variables. "The implementation part of DevOps, it varies largely based on how the organization is structured."

Shift left is a scheduling decision, not a philosophy

Scheele pushed on a real tension in the Agile manifesto: it favours "individuals and interactions over processes and tools," yet DevOps runs on exactly those processes and tools — CI, CD, pipelines. Gule's answer reframes the question rather than resolving it as a contradiction. The tools aren't in tension with agility. They're what makes rapid iteration possible without losing quality.

His example is concrete. Testing used to happen late — near the end of the development cycle, when a defect is expensive to fix and a deadline is close enough to create pressure to ship anyway. "Shift left" means moving that check earlier: nightly builds instead of a pre-release scramble, vulnerability scanning built into the pipeline instead of a security team's final gate before production. "Instead of waiting for the security team to do the scans just before the release goes out to production, you can integrate these kinds of things quite early in your development cycle," he said. The practices aren't new. What changed is when they happen — and that timing question turns out to matter more than the tooling choice.

Two organisations' worth of evidence for Conway's law

The most concrete part of the conversation is two organisations Gule described that solved the same problem in structurally different ways.

At a mid-size insurance company in Singapore, a shared services team built reusable infrastructure — Terraform modules, specifically — that individual business units consumed as building blocks. A team in Singapore and a team in Indonesia each assembled their own infrastructure from the same shared components. Call it a shared-plus-democratic model: central team builds the primitives, local teams retain the decisions.

At a large bank, also in Singapore, the model split differently. An enterprise SRE team owned the tooling layer outright — which source control platform, which CI server, Jenkins or Bitbucket, decided centrally. A separate DevOps team sat inside each business unit and customised how those tools got used day to day. Centralised infrastructure, decentralised practice.

Neither model is more "mature" than the other in Gule's telling. Both work, for different organisations. What decides which one you end up with, he said, traces back to Conway's law — the principle that an organisation's systems will mirror its communication structure, whether anyone designs it that way or not. You don't choose your platform topology so much as your org chart chooses it for you, unless you're deliberate about the choice.

Version four, and the thing nobody argues about anymore

Scheele asked where this goes next, and Gule laid out an evolution rather than a single answer: continuous integration was version one, DevOps version two, site reliability engineering version three, and platform engineering — the current wave — version four. Each absorbed the last rather than replacing it.

The practical evidence is consolidation. Tools that used to require two or three separate products now live inside one platform. "You see a platform like GitLab, for example, allowing you to build so many things just using one platform itself," Gule said. "You don't need a separate CI server. You don't need a separate continuous deployment tool."

And the baseline has moved far enough that the argument itself is largely over. "Very rarely nowadays you see a project starting in 2024, which doesn't have a continuous integration enabled," he said. CI/CD and infrastructure as code aren't strategic bets anymore — they're closer to what unit testing became a decade ago: assumed, not debated.

This episode opens a short series — automation, security, and observability follow in the coming weeks, each digging into one piece of what Gule outlined here. The organisational question, though, doesn't wait for the next episode. It's the one worth sitting with now: does your platform team's structure reflect a deliberate choice, or just whatever your org chart happened to produce?

Jon Scheele (00:00)

DevOps is considered a core capability in many technology organizations It had its origins in the concern that was expressed about having developers who create software, completely different career path and often completely different groups within the organization from the people who actually run it. And it aims to promote collaboration between those. But it's not always so simple.

To discuss some of these complexities and how to actually achieve the aims of DevOps.

I'm very glad to welcome Nilesh Gule to discuss. He's an enterprise architect, a Microsoft Most Valued Professional and a Docker captain. So welcome Nilesh.

Nilesh GULE (00:51)

Hi Jon, it's a pleasure speaking with you.

Jon Scheele (00:53)

Right, so the aim of DevOps is to increase collaboration between developers and operations. And this is pretty complex. The idea has been around for at least 20 years. I wouldn't say that everyone's achieved the optimum level of DevOps. We hear terms like "You build it, you run it", which some organizations aspire to. Can you sort of paint us a picture a little bit about where you see DevOps in the organizations that you've worked with and what they try to achieve with DevOps?

Nilesh GULE (01:46)

Yeah, as you rightly said, Jon DevOps is a set of principles, right? And if we look at some of the core tenets of DevOps practices, it's about collaboration, improving the culture of automation. And I remember when I started my career, we used to have this distinct set of personas or teams and I started as a developer.

But my role was more to just write code and then we would just give it to a release management team who would have their own set of tools and processes. We never really worried about how the software was packaged. This team would then take it. They would use some scripts. They would deploy it. And then when issues came, it became like a big investigation. Like where was the failure coming from or what was the root cause?

And as you start moving into, let's say, late 2010 or early 22nd decade of this century, we saw a lot of automation happening in terms of not just the software development, but also on the operations side. And that's where DevOps practices, they really picked up. Now, if I see I've been in the industry for more than 21 years, the things which we started back in 2005, 2006. They are very much part of the tooling now. But that time, if you could just build your software continuously, continuous integration in 2007, 2008 was a big topic.

Nowadays, if you see it just become part and parcel of the tooling itself, people can just click a button and say, this is my repository, build it and deploy it to my cloud provider or my target environment. So I think over a period of time, the practices and the tools have matured to a great extent. But as you rightly pointed out, the complexities of software development and the organizations itself, they pose a bit of challenge in terms of implementing some of the best practices. In my experience, I've worked with organizations which are, let's say medium size and even very large, where there are more than 10,000 developers as well in Teams. So I think the implementation part of DevOps, it varies largely based on how the organization is structured.

Sometimes you have teams which are co-located. So it's very easy for them to work out the collaboration part of DevOps. But as you move to distributed teams, you need to have those certain processes and some of these things which are part of DevOps, they have to be formulated more into like process guidelines and things like that. And that's where the differences come in terms of implementation is what has been my experience so far.

Jon Scheele (04:36)

So to me, the reason for having DevOps is to help with organizations become more agile. So agile is a concept that can be applied in any industry, in any job role or function, but in technology, it seems to me like DevOps is an enabler of agility.

But if we look at say the Agile manifesto, there are some things that seem a little counterintuitive because for example, in the Agile manifesto, it favors individuals and interactions over processes and tools. And you just mentioned some processes and tools. But another aim is responding to change over following a plan. And the aim of to achieve that in an agile organization, you need to go through very rapid iterations and cycles. So this is sort of the reason for having these processes and tools like continuous integration, continuous deployment to enable you to go through those cycles faster.

So how do we balance the needs of the automation, which defines and you could say it constrains you a little bit to follow a process with the aim of rapidly iterating.

Nilesh GULE (06:20)

Yeah, I think Agile is more about doing iterative development. it's things like shift left, for example. If I look at when I started my career, testing used to happen quite late in the development cycle. And now if you look at most of the matured organizations, they integrate continuous testing as part of their development life cycle.

So that's an area that's a kind of thing which I feel has helped as part of agile practices to make teams make those minor changes in their software development lifecycle, but still achieve the principles of agile software development. The other example I would like to cite is that of doing like the vulnerability scanning or code scanning as part of your continuous integration builds.

It's not necessary that you do it with every check-in, but you could do it periodically. So instead of, let's say, doing your quality checks and saying you need to achieve a minimum code coverage, you wait all the way till it goes to UAT, and then you start thinking about making

the unit test or writing unit test to achieve your thresholds for code coverage. If you have it as part of your nightly build, say for example, it could still help the team members to achieve that objective of writing quality code. Same goes with the open source vulnerabilities. Instead of waiting for the security team to do the scans just before the release goes out to production, you can integrate these kinds of things quite early in your development cycle.

And I think this is where the integration of processes and tools comes into the picture and they go hand in hand. We are not deviating too much from the standard patterns and recommended practices. It's just that as part of agile development, we are shifting them earlier in the development lifecycle, which helps everyone in the process.

Let's say you find out that you have a big vulnerability to address, you could take adequate actions quite early in development cycle instead of waiting just a week or just few days before the release. So I think that's in my personal experience, a good thing which has happened over the last few years that things like DevSecOps integration in the development lifecycle has helped to shift many of the things early in the development cycle.

Jon Scheele (08:50)

So that goes hand in hand with how you organize teams. So there have been, in order to achieve shift left, it means that you have to have some knowledge of the testing and security vulnerability scanning within the team that actually creates things. whereas previously you'd have a very large development team handing over to a very large testing team and being checked by a very large security team. Now organizations are trying to make all those functions embedded within a single team in order to achieve that. And we hear terms like the two pizza team. But when you do that and you devolve large organizations into these semi-autonomous, smaller, multidisciplinary teams, how do you make sure you're still covering things and that you're providing the tooling so that they don't have to invent everything?

Nilesh GULE (10:10)

Yeah, this goes back to my earlier thing which I was trying to highlight that it depends on the size of the organizations and also the maturity in terms of their processes. I think if someone is starting quite new, it's like a startup. For them, it's quite easy to adopt all the latest and greatest tools and technologies. But in a big enterprise, you might already have systems, processes, which are already in place. And change management plays a key role in this. If you have to move from, let's say, one source code management system to another, it could take you years to do that.

if it's a very large organization. So again, in my experience, I've seen different types of models being used when we talk about DevOps and SRE kind of teams. In a medium-sized enterprise where I was working for a big insurance company in Singapore, we had a shared services team which would do a part of the automations, like Terraform modules, for example.

They were built by this shared services team. And then the individual business units, they would consume this as a consumable. So like a team in Singapore would then build their infrastructure based on these modules. A team in Indonesia would do their own. Whereas on another side, which was a big banking organization, a big bank in Singapore, we had a slightly different model where there was an enterprise SRE team, which was taking care of all the tooling, in terms of what software governance tool was used, what tool was used for building the like Jenkins or if we were going with Bitbucket. So the tooling was managed by one team.

And then there was another team which was looking at the DevOps practices and this was within the business unit. So each business unit had their own versions of the DevOps team who would customize the DevOps patterns and practices as per their needs. So I think I've seen both these versions where you have a kind of shared plus a democratic model and in other players where it is much more structured.

So in my opinion, it really depends on the size of the organization. And again, it could go back to the Conway's law, which says that you structure your teams based on how the organization is structured. So it would very much depend, in my opinion, on the maturity and the size of organization, how they actually implement the DevOps teams and the patterns and practices.

Jon Scheele (12:50)

I think there are a couple of things there. So there's Conway's law, is organizations are constrained to build systems that reflect the communication paths within the organization. And I think you mentioned Parkinson's law, is a challenge in any work environment that whatever you estimate, work seems to expand to fill the time allowed for its completion. since the

Nilesh GULE (13:16)

Yeah.

Jon Scheele (13:20)

the term DevOps came about, there have been some additional nuances or movements within that. So the site reliability engineering movement that was just started by Google is about optimizing that practice of the engineering of how systems are operated and changed.

And then more recently, platform engineering is about making sure that developing the tools and processes so that developers can accelerate their productivity, which I think you hinted on that example that you gave about a team preparing tools for other people to use is an example of that.

So where do you see this heading in future?

Nilesh GULE (14:23)

I think it's an evolution as you rightly pointed out. I would say version one was about continuous integration. DevOps was version two. Then the SRE was version three. And now platform engineering is like version four of evolution of this automation and collaboration part when it comes to the developers and operators working hand in hand.

I see that the tools are becoming more and more mature and lot of these practices are integrated well within the tools. Earlier you might have had to use like two or three different tools to achieve the same. But now you see a platform like GitLab, for example, allowing you to build so many things just using one platform itself. You don't need a separate CI server. You don't need a separate continuous deployment tool.

This integration of various, I would say subsections of the platform engineering or SRE or DevOps practices, whatever you call it, into the tooling itself is one area where I see both the service providers as well as organizations maturing quite a lot. And it's become almost like acceptable nowadays that if you start a new project,

you would invariably start with DevOps integration and continuous integration, continuous delivery kind of pattern. Very rarely nowadays you see a project starting in 2024, which doesn't have a continuous integration enabled. And they're not trying to do something in terms of automating their infrastructure or using practices like the infrastructure as code and things like that.

So I think over a period of time, these things have just become normal. Like we don't think too much about them nowadays. It just assumed that you will start with at least these bare minimum things. So that's where I see as the tools mature and as the teams also mature in these.

different aspects, it's becoming just part of our life. Just like unit testing has become a part of developers life over the last few years. I see these platform engineering and DevOps SRE also becoming just a norm.

Jon Scheele (16:42)

Okay, well thanks very much for sharing that, Nilesh. So over the next few weeks, we're going to dig into some of these topics in a little more detail. Next week, it's automation. And so we'll discuss the CICD pipeline and automated testing and other aspects of that. And then we'll cover security and then observability. So I'll...

be talking to you about at least one or two of those topics in the coming weeks. But thanks very much.

Nilesh GULE (17:20)

Thanks, Jon.

Go deeper

Conway's law and your DevOps rollout

Two organisations solved the same DevOps problem two different ways — what actually decides which model you end up with.

Read the deep dive →

"It could take you years"

Why a core system migration is a change-management problem, not a technical one — and why it needs an executive, not an engineer, to own it.

Read the deep dive →

See more about DevOps and APIs

Debugging Kubernetes using AI with Nilesh Gule

In this conversation, Nilesh and I discuss the critical role of automation in DevOps, particularly through the use of Kubernetes. They explore the benefits and challenges of Kubernetes, emphasizing the complexities involved in debugging and managing Kubernetes clusters. Nilesh introduces K8sGPT, a generative AI tool designed to assist in diagnosing and resolving issues within Kubernetes environments. The discussion also touches on the future of Kubernetes management, highlighting the potential for AI to enhance operational efficiency while still requiring human oversight.

/podcast/s2e2-debugging-kubernetes-using-ai-with-nilesh-gule

Nilesh on YouTube

This channel is about my explorations with technology. I am a Microsoft Most Valuable Professional (MVP) for Microsoft Azure . This channel is my space to share the technologies that I work and explore. I am passionate about technology. I like to explore cloud technologies. I am also the First Docker Captain in Singapore.

You can expect things about Microsoft Azure, DevOps tools and practices as well as things that make developers life easier. Docker, Kubernetes and cloud native related technologies are my current areas of interest. I also have a blog www.HandsOnArchitect.com.

https://www.youtube.com/@nilesh-gule

The Interconnection of AI and APIs

Aki Ranin, co-founder of Bambu, and currently CTO of Goldberry Wealth, discusses the interconnection between AI and APIs. He shares his journey in the AI data science space and explains how AI and APIs are intricately linked. Aki highlights the potential of large language models and AI agents in transforming industries and making AI-assisted tasks more efficient. He also discusses the challenges of discoverability and the importance of metadata in making information accessible to AI agents. Aki provides recommendations for individuals looking to understand the trajectory of AI and APIs.

https://www.apiconnections.io/podcast/ep-01-the-interconnection-of-ai-and-apis-with-aki-ranin

powered by blue connector

API Strategy and Tech Advisory, Training and Events

We connect your organisation, your customers, partners and suppliers with the information and knowledge you need to make your tech work for you

Learn more