This article is based on a piece originally published on enterprisersproject.com. The analysis and structure below represent an independent editorial treatment of the same subject matter.
Why Scaling Agile and DevOps Is Hard
More organisations are investing in agile and DevOps for straightforward reasons: they want to move faster, run more experiments, and turn those experiments into competitive advantage. The challenge is that what works for a cross-functional team of ten people rarely translates cleanly to a team of one hundred, let alone an enterprise of thousands.
Until relatively recently, adopting DevOps at scale required heavily customised toolchains, significant hand-holding, and a great deal of organisational friction. That friction has historically made it easy for IT leaders to defer the change for another year. Two forces are now making that deferral increasingly costly: the maturation of container technology and the competitive pressure coming from smaller, faster organisations.
The Structural Problem: Dev and Ops Work Against Each Other
Development and operations teams are typically incentivised in opposite directions. Developers are rewarded for creating and changing software quickly. Operations teams are rewarded for stability, cost reduction, and security. They often sit in separate organisational units and minimise day-to-day interaction. This structure almost guarantees a handoff problem.
The traditional pattern looks like this:
- The business throws requirements over the wall with a nine-month delivery expectation.
- Developers build to those requirements, adjusting for technical constraints along the way.
- The completed software is thrown over the wall to operations to “figure out how to run it.”
- Operations makes a further round of changes to align the software with production infrastructure.
- The result often bears little resemblance to what the business originally envisioned.
This cycle has repeated across the industry for two decades. Agile methodology challenges the model but has struggled to displace it at enterprise scale because the tooling and processes required deep, bespoke integration work.
Why Containers Close the Gap
Linux containers address the handoff problem directly by separating what is delivered from where it runs. This single distinction changes the responsibilities of each team in a manageable way:
- Development teams own the application code and its internal dependencies. They define what the container contains and what it needs to consume from the outside world.
- Operations teams own the host environment that runs the containers, the security footprint, and the underlying infrastructure — on-premises or in the cloud.
The key benefit is that neither team needs to become expert in the other’s domain. Developers do not need to know how to run software at production scale. Operations engineers do not need to understand application-level minutiae. Containers create a well-defined interface between the two, eliminating most of the telephone-game that causes rework and delays.
This also means organisations can begin a DevOps transformation with the teams they already have, rather than attempting a decade-long retraining programme. Trying to make 30,000 engineers equally skilled in both development and operations is not realistic within a competitive timeframe. Containers make specialisation viable while still enabling genuine collaboration.
Where Kubernetes Fits In
Containers solve the packaging problem. At scale, however, a production application is not a single container — it is dozens or hundreds of containers that must be orchestrated to run reliably as a unit. This is where Kubernetes becomes essential.
Kubernetes acts as an abstraction layer between applications and infrastructure. It allows operations teams to provide the compute, networking, and storage resources an application needs without requiring them to understand every application-level dependency. Developers, in turn, can define resource requirements and deployment behaviour declaratively, without needing deep infrastructure expertise.
The practical result is that both teams can work in parallel without blocking each other:
- Developers can experiment, iterate, and deploy frequently.
- Operations can maintain infrastructure security and reliability independently.
- The business can take smaller, faster risks instead of infrequent, large bets.
Real-World Velocity: What Daily Deployments Actually Look Like
The transition from quarterly or monthly releases to daily deployments is not just a technical change — it restructures how organisations plan and prioritise work entirely.
KeyBank adopted a DevOps model using containers and Kubernetes and reached a cadence of deploying code every day. John Rzeszotarski, director of Continuous Delivery and Feedback at KeyBank, has described the cultural and process changes that accompanied the technical shift.
Macquarie Bank similarly used DevOps and containers to reach daily production deployments. Luis Uguina, CDO of Macquarie’s banking and financial services group, described the outcome this way: “An idea can get to a customer in a day.” Macquarie also used this capability as a developer recruiting tool, promising new hires that they would push something live within their first week.
These are not startups. They are established financial institutions operating under significant regulatory constraints. Their ability to reach daily deployment cadences demonstrates that containers and Kubernetes can work at enterprise scale, not just in greenfield environments.
The Cloud-Native Microservices Trap
A common response to the scaling challenge is to propose building new cloud-native applications from scratch using microservices, side-stepping the legacy codebase entirely. This approach is appealing in theory but difficult in practice for large organisations.
Building microservices one by one while maintaining existing systems creates parallel workstreams that are expensive to sustain. IT budgets are already constrained. Doubling or tripling them for the years it would take to rebuild at that scale is not realistic for most organisations. The risk is ending up with a siloed architecture that mirrors the organisational dysfunction it was meant to fix.
Containers offer a more pragmatic path: they can run the applications you already have on Linux today, and they are being designed to support the workloads coming next — machine learning inference, AI pipelines, and analytics at scale. Migrating to containers does not require a full rewrite of existing applications, which makes the transition financially and operationally viable.
Looking Ahead: AI, Machine Learning, and the Pace of Change
The urgency of adopting DevOps practices is increasing as machine learning and AI begin to affect software development itself. Today, a one- to three-week sprint cycle is considered fast for most enterprise teams. As AI-assisted development tools mature, the potential rate of iteration will increase significantly. Organisations that have not yet built the deployment infrastructure to support rapid release cycles will find it increasingly difficult to keep pace.
Kubernetes is being extended to support GPU-accelerated workloads and the scheduling requirements of machine learning training and inference, which means the same platform organisations adopt for application delivery today is also the platform likely to underpin AI workloads in the near future.
Practical Starting Points
If your organisation has attempted a DevOps transformation and stalled, containers and Kubernetes lower the barrier to re-entry. A few principles to keep in mind:
- Start with the team you have. You do not need to retrain everyone before you begin. Use containers to define clear boundaries between development and operations responsibilities.
- Choose a bounded scope for the first deployment. Pick one application or service and get it running in containers with a Kubernetes-based deployment pipeline. Demonstrate the velocity gain before expanding.
- Change planning alongside tooling. Daily deployment only creates value if planning and prioritisation processes are designed to take advantage of it. Sprint planning, backlog management, and stakeholder communication all need to adapt.
- Avoid parallel rewrites at scale. Resist the temptation to rebuild everything from scratch as microservices. Containerise existing workloads where practical and build new services only where the business case is clear.
- Measure deployment frequency and lead time. These are the most direct indicators of whether your DevOps transformation is gaining traction. Set a baseline and track progress explicitly.
Conclusion
Linux containers and Kubernetes have meaningfully reduced the organisational friction that has historically made DevOps difficult to scale. They do this by creating a clean interface between development and operations teams, allowing each to work at the pace their business requires without depending on the other to change its entire skill set first.
The window for making this transition before competitive pressure forces it is narrowing. Established enterprises — including regulated financial institutions — have demonstrated that daily deployment cycles are achievable. The technology has caught up with the ambition. The remaining question is whether your organisation is willing to change the planning and incentive structures that have kept the old model in place.