Five years ago, I wrote about 10 companies that were killing it with DevOps. Today, all of those enterprises—including Amazon, Walmart, and Netflix—remain household names, not just for consumers, but in the tech community, too.

Since then, who else has emerged as a clear DevOps leader? These 10 organizations are all pushing the boundaries of DevOps, breaking down barriers between development and operations, transforming their companies and their industries—and continuing to do so during a time of global upheaval.

1. Adidas

In 2015, Adidas released the first of its Yeezy sneakers, which were designed in collaboration with Kanye West. Demand for the original shoe—and its many follow-ups—was instantaneous and enormous, with Adidas selling over 2,600 shoes in the space of five seconds. That was great for business, but it presented a huge challenge for IT, which was tasked with ensuring the Adidas’ tech infrastructure didn’t collapse under the strain.

At the start, Adidas wasn’t ready. The site crashed when new Yeezys were announced. Inside the company, developers moaned that they were helpless to fix things and that it could take up to a week even to get a simple virtual machine spun up.

Faced with upset customers and employees, Adidas underwent a massive transformation that embraced cloud-native architecture, Kubernetes, and DevOps and that involved a wholesale cultural shift. A DevOps Cup competition was instrumental in taking the company’s delivery cycle from as slow as six weeks to as fast as five times a day. Today, you can find Adidas’ DevOps Maturity Framework on GitHub.

2. Capital One

In 2010, Capital One was a stodgy financial firm with a dated waterfall development process that was heavily outsourced, a massive in-house data center, and manual build, deployment, and test operations. By 2018, the firm had completed a multi-year journey that culminated in becoming the first major bank to host its banking application on the public cloud, solidifying its reputation as a DevOps leader.

Since that time, the company has been fully reinvented. Today, Capital One is regarded as a leader in agile development and cloud-native infrastructure. It has an almost ruthless devotion to developing its own tools through open-source software—done almost entirely in-house.

The initial goal of Capital One’s DevOps transformation was speed, but, as a financial services firm, security and governance were equally important. The culture of collaboration created through DevOps has been critical to this move, as has a focus on accountability and “fearlessness.” Capital One’s homegrown DevOps dashboard, Hygieia, is highly regarded—and, of course, it’s open source and available to the public, too.

3. Verizon

As the mobile industry began lurching toward 5G, America’s largest wireless carrier embarked on a digital transformation of its own. Verizon 2.0, as it’s known internally, introduced major changes in the business model to make the company more nimble and flexible. These were key qualities needed to enable its successful technical transformation.

Verizon went “public cloud first” in 2016 and embraced immersive DevOps dojos a year after. From there the company worked to modernize its monolithic architecture, embrace open-source tools, and generally become a more agile organization.

Today (or, at least, pre-COVID 19), Verizon has flipped its dojo concept from a six-week-long offsite training session to one where coaches travel to the developers and embed themselves directly within their business units. This has improved the pace of knowledge transfer and allowed for a wider range of training types.

4. CSG International

CSG isn’t a household name, but as a back-end provider of software and services for the telecom industry, it’s a business that touches just about everyone. It primarily provides billing, payment processing, and customer service.

The company launched a broad DevOps reorganization effort in 2016 and integrated the product management function with DevOps in 2018. Modernizing the technology stack has been a goal of the company ever since.

The problem is one of sheer history: In 1994, CSG was spun off from its original owner, First Data, which itself was founded back in 1982. Shards of First Data’s legacy software have endured in the CSG codebase ever since.

But a monumental effort over the last few years—involving revamping its version-control procedures and embracing automated testing—has successfully transformed the enterprise. After doubling down on DevOps, the company is now seeing dramatically improved efficiency, with an 83% reduction in incidents caused by each release.

5. Disney

Disney has been pursuing DevOps aggressively for nearly a decade, revamping its org chart from functional teams to a matrix organization. The company embedded its engineers and managers across various business units and improved cross-functional communications, both of which have radically enhanced the business’s technical capabilities.

The last few years of those efforts were instrumental in powering one of the biggest streaming video launches in recent history, which concluded earlier this year. Almost overnight, Disney+ became a serious competitor to services from Netflix, Amazon, Hulu, and HBO—adding 10 million subscribers in one day, all during a time of incredible global crisis.

6. Northrop Grumman

When your company’s job is to make billion-dollar military aircraft, it’s safe to say that reliability is at the top of the to-do list. With an estimated tens of millions of lines of code powering a single plane, application development is a serious challenge. It can’t be easily addressed through the traditional tools of agile and DevOps, given the potential hazards of pushing a prospective update to aircraft in the field.

Sure enough, Northrop Grumman’s first experiences with DevOps were rocky, in part because it had to work with all manner of government software tools. But it achieved a breakthrough when it embraced “continu-ish integration” and digital twins, and it is now running 15,000 automated test processes each day.

Northrop frequently presents at conferences with its industry mate Lockheed Martin, which has developed and adopted many of the same operating principles.

7. BMW

Now four years into a major DevOps overhaul, BMW has pursued a digital transformation journey as it has migrated its entire firm from a waterfall methodology to a fully agile one. A stodgy organizational culture revamped to support new ways of working.

In 2019, BMW’s “100% BizDevOps” approach began tying project funding to the business value that the project would potentially provide, while bringing microservices and cloud-first architecture into the mix. With 30,000 servers running 5,000 different applications, BMW found the road to success by starting small and taking baby steps toward change rather than attempting to make a wholesale transformation all at once.

8. Optum

Optum is the sister company of UnitedHealthcare, the largest healthcare company in the world. Optum is heavily focused on data management and analytics in the healthcare space. It faced a problem familiar to many large enterprises: Development wanted to move quickly by implementing new features and applications, while operations wanted stability in the apps it was already managing.

Optum embraced DevOps in earnest in 2014 to break down these silos, and the company’s recent metrics have shown that its efforts have proved very successful, with millions of dollars saved every year by reducing mainframe usage alone.

The amount of data managed by Optum and its parent company presented its greatest challenge, with unstandardized data coming at the organization from dozens of sources, all courtesy of thousands of APIs. A massive standardization and modernization effort has seen the creation of a scalable, centralized data platform that allows information to be seamlessly shared across multiple consumers. The approach was borrowed from successful digital transformations in the retail and financial industries.

That’s been a foundational part of a cultural shift that has been effective at finally getting some 160 tech teams on the same page.

9. Nationwide Mutual Insurance

Nationwide began its digital transformation journey in 2009, and since pulling out the stops in 2017, it’s become a poster child for DevOps evangelism and the business successes it can foment. After a wholesale move to agile and distributed development that took three years, the insurer improved code quality by 50% and reduced downtime by a whopping 70%—despite continuing to actively build for its legacy mainframe platforms.

The key has been a bimodal process that lets different groups iterate at different speeds, allowing Nationwide to “move slow and fast at the same time.” Large transactional systems with many dependencies can percolate a bit more methodically, while more visible, customer-facing services (such as mobile apps) are updated far more frequently. This ultimately lets Nationwide more effectively prioritize its tech efforts while giving staff the freedom to experiment.

10. Starbucks

Making coffee isn’t so easy when you have more than 300,000 people involved in the process. Starbucks’ bold move to DevOps began in 2015, and it learned quickly that it needed to balance the desire to constantly push code forward with the need to ensure that code is appropriately tested and ready for deployment. Organizational tweaks within the company were hugely successful, ultimately reducing cycle time by a massive 74%.

One of the most challenging parts of the move to DevOps at Starbucks was the transition of the company’s product leadership to an environment composed of self-managed teams. Working carefully with employees to understand how jobs and responsibilities change after DevOps is adopted is an essential step to smoothing the path forward, the company learned.

Looking ahead

Digital transformation efforts continue to drive enterprises in all industries toward DevOps and agile methodologies, and the payoff from those efforts hasn’t slowed. Even large and very old businesses are finding ways to integrate DevOps thinking with old ways of doing business, integrating legacy operations with cloud-first and open-source initiatives to create innovative operational structures.

As the Covid-19 pandemic continues to challenge traditional ways of operating, watch for these trends to accelerate in the next few years.

Linux Foundation and CDF Launch Free Jenkins Course

The Linux Foundation, in collaboration with the Continuous Delivery Foundation (CDF), launched a free introductory course on Jenkins, the widely used open source CI/CD platform. The course is the first in a planned series of both free and paid online training resources focused specifically on DevOps tooling.

Clyde Seepersad, general manager of training at the Linux Foundation, explained that while the foundation had previously offered higher-level conceptual DevOps courses, the formation of the CDF provided a focused organizational home from which the Linux Foundation could build tool-specific curriculum. The CDF operates as an arm of the Linux Foundation.

What Is Covered and What Comes Next

The Jenkins course is designed as an introduction to the platform, targeting practitioners who are new to CI/CD pipelines or looking to formalize their knowledge. Beyond Jenkins, Seepersad indicated that the Linux Foundation plans to release courses on Spinnaker—a continuous delivery platform originally developed at Netflix—as well as other DevOps tools maintained under the CDF umbrella.

Projects currently hosted under the CDF include Jenkins, Jenkins X, Spinnaker, and Tekton, among others. Providing structured training on these tools supports the CDF’s broader mission of growing the continuous delivery ecosystem.

Why Free DevOps Training Matters

Seepersad cited accelerating demand for DevOps skills as a key driver behind the initiative. Organizations undergoing digital transformation—a trend that intensified significantly during the COVID-19 pandemic—are increasingly adopting cloud-native technologies to build more flexible and resilient applications. Platforms like Jenkins help IT teams ship those applications faster and with greater reliability.

Free, accessible training lowers the barrier to entry for IT professionals who want to upskill but cannot invest in expensive certification programs. Expanding the pool of practitioners benefits the broader DevOps ecosystem, employers looking for qualified talent, and individuals seeking to advance their careers.

Tools Alone Are Not Enough: The Culture Problem

A recurring theme from Seepersad is that technical training must be paired with organizational change. Many companies underestimate the cultural transformation required to make DevOps work in practice. Handing developers a new tool without rethinking the workflows between development and operations teams often generates friction rather than efficiency.

His advice: foster an open dialogue about DevOps processes rather than avoiding the difficult conversations. Resistance to change grows when legitimate concerns go unaddressed. Training is one lever—but leadership, process redesign, and honest communication are equally important.

The Business Case for DevOps Expertise

DevOps practitioners are in strong demand across the industry. Teams with DevOps skills can:

• Automate application build, test, and deployment pipelines, reducing manual toil.
• Programmatically manage infrastructure at a scale that GUI-based administration cannot match.
• Enable organizations to scale IT capacity without a proportional increase in headcount.
• Improve deployment frequency and reduce mean time to recovery (MTTR) when incidents occur.

For IT organizations trying to do more with constrained budgets and smaller teams, these capabilities are not optional extras—they are operational necessities.

How to Access the Jenkins Course

The free introductory Jenkins course is available through the Linux Foundation Training portal. Interested learners should visit the site directly and search for the Jenkins course listing, as specific URLs and catalog contents may change over time. No prior Jenkins experience is required to begin the introductory course.

Key Takeaways

• The Linux Foundation and the CDF released a free introductory Jenkins CI/CD course in June 2020.
• Additional free and paid courses on Spinnaker and other CDF-hosted tools are planned.
• Demand for DevOps skills is rising, making accessible training strategically important.
• Cultural change within IT organizations is as critical as technical skill adoption.
• The course is available via the Linux Foundation Training portal at no cost.

TIBCO Software has added Microsoft Azure Cognitive Services support for TIBCO Spotfire and TIBCO Data Science.

TIBCO’s solutions extend existing services to analyse multivariate anomalies and add root cause analysis, using input from the Key Phrase Extraction cognitive skill to render decisions and automate actions like anomaly detection, the company states.

With visual analytics and data science services, sensor data and log data can be analysed at the edge. According to TIBCO this includes the ability to detect anomalies within reams of data and alert case managers to take preventive actions.

In use cases where internet connectivity is unavailable and clients need to process data in real time this is particularly useful.

TIBCO states its aim is to deliver advanced cognitive services on Microsoft Azure to joint customers, leveraging artificial intelligence at the edge and in containers for responsive analytics.

According to the company, the big benefits of added cognitive services are improved operational efficiency and lower equipment costs, TIBCO states.

Existing customers using Spotfire within their IoT environments cite ease of use and the ability to scale as key differentiators for their business, TIBCO states.

For instance, the company cites an education institution specialising in healthcare saw a drop of 74% in onsite surgical infections as a result of making predictive decisions directly in operating rooms.

In addition, a manufacturing business in the semiconductor industry has used digital twins and model operations to detect geospatial anomalies within wafer maps and uncover millions in cost savings.

TIBCO chief operation officer Matt Quinn says, “Increasingly, customers performing predictive maintenance must look for ways to leverage AI closer to where their data is generated for timely analytics and responses.

“TIBCO’s approach to visual AI, analytics, and ML integrates well with Microsoft Azure AI and Cognitive Services. In particular, Microsoft’s Python APIs are easily invoked from the TIBCO analytics offerings, giving our customers flexibility for AI core and edge scenarios, online and offline.

“The addition of Azure AI gives our customers flexibility and breadth of choice when using TIBCO Data Science with machine learning capabilities.”

Microsoft director of Azure Marketing Bharat Sandhu says, “TIBCO has a strong track record of delivering advanced analytics and data science solutions.

“TIBCO has leveraged the power of Azure Cognitive Services to give customers even greater flexibility when deploying AI solutions – from performing equipment asset management and analysing functionality, to identifying anomalous data points and alerting a case manager.”

According to TIBCO, this latest announcement shows the developing relationship the company has with Microsoft, and a growing focus on delivering solutions to organisations looking to accelerate their digital business transformation.

TIBCO Software is a global company specialising in enterprise data, working with customers to connect, unify, and predict business outcomes, with the aim of easing data-driven challenges.

Customers to benefit from an integrated DevOps toolchain with unparalleled mainframe operations management and agile application development and delivery

The Cloud Label Problem

“Cloud” has become one of the most overloaded terms in enterprise technology. Vendors routinely attach the label to solutions that are, in practice, little more than traditional hosted applications—your legacy software running on someone else’s server, with none of the architectural benefits that genuine cloud compute delivers. Before committing to any solution marketed as cloud, engineering and procurement teams should ask several pointed questions:

• Is this cloud or hosting? Has the vendor simply lifted an existing on-premises application into a data centre and made it accessible via a browser?
• Has the application been re-architected? Does it take advantage of elastic scaling, microservices, or cloud-native storage and compute primitives?
• Does the vendor have an agile development roadmap? Cloud-native platforms should deliver continuous, value-adding enhancements—not periodic monolithic upgrades.
• What are the actual total-cost and performance characteristics? A hosted legacy application may carry the same or greater operational overhead as the on-premises original.

Cloud adoption should be driven by pragmatism and due diligence, not by a mandate to move everything off-premises for its own sake. The right question is never “Can we put this in the cloud?” but rather “Does cloud compute provide a measurable advantage for this specific workload, security model, and user need?”

Where Cloud Migration Actually Stands

The first wave of cloud migration—moving straightforward, low-risk workloads—is largely complete. Estimates at the time of this analysis placed roughly 20% of enterprise compute in public cloud environments. What remains is a harder category: workloads that are more complex, more tightly coupled to on-premises systems, or subject to stricter compliance requirements.

These harder workloads are also, paradoxically, the ones most likely to generate meaningful business value once migrated successfully. The transition represents more than a technology change—it requires new operating models, new skills, and in many cases a genuine re-evaluation of application architecture. Some workloads will ultimately prove impractical or uneconomical to migrate, and new applications continue to be provisioned on-premises where that remains the appropriate choice.

Digital Transformation ≠ Wholesale Cloud Migration

A widespread misconception equates digital transformation with moving everything to the public cloud. This conflation carries real costs. According to data cited from an Everest Group survey, 73% of enterprises failed to deliver any measurable business value from their digital transformation efforts. While causation is difficult to isolate, a likely contributor is treating technology migration as an end in itself rather than as a means to improve processes, customer experiences, or competitive positioning.

A genuine transformation starts with identifying the target business outcomes and then selecting the appropriate technical form factor—cloud, hosted, or on-premises—to achieve them. The result is often a deliberate mix of all three, each serving the workloads it is best suited for.

Digital Distress Is a Real Competitive Risk

IDC projected that by 2020 a significant proportion of organisations would be either “digitally determined” (actively using technology to drive advantage) or “digitally distressed” (falling behind because of inadequate digitisation). The intervening years have borne this out: established brand names have struggled, been acquired, or exited markets, not because technology was unaffordable but because they failed to adapt to customer expectations for seamless, omnichannel digital experiences.

The barriers to effective digitisation are no longer primarily financial or technical. The determining factors are organisational: the willingness to change, the capability to execute, and the discipline to select the right platform for each use case while avoiding vendor lock-in that constrains future options.

Why Multi-Cloud Happened by Osmosis—and Why That’s Fine

Most enterprises did not architect a multi-cloud strategy from scratch. They arrived at it incrementally, as individual application choices drove platform selections—much the way mixed UNIX, Novell NetWare, LAN Manager, Windows NT, and VM environments emerged in earlier decades, each pulled into existence by the operating system requirements of the applications running on top of them.

Today, different SaaS and PaaS vendors offer varying levels of integration with AWS, Azure, Google Cloud, and other platforms. Choosing a single public cloud provider and constraining all future application decisions to that platform is increasingly impractical. The right cloud for a given application is determined by that application’s specific performance, compliance, integration, and geographic requirements—not by a top-down mandate.

Accepting multi-cloud as the default state removes a false constraint and lets teams optimise at the workload level. It does, however, introduce real operational challenges that must be addressed deliberately:

• Compliance and data sovereignty across providers with different certification scopes and regional footprints
• Skill set breadth required to operate competently across multiple cloud control planes and toolchains
• Consistent security posture when identity, network policy, and secrets management span disparate platforms
• Observability and monitoring across heterogeneous environments without gaps or duplicated tooling
• Cost visibility and optimisation when spend is distributed across multiple billing models

What the Forrester/IBM Research Found

The Forrester survey commissioned by IBM identified the primary drivers behind enterprise multi-cloud strategies:

• Higher application and infrastructure performance
• Flexibility to match workloads to the most appropriate platform
• Improved customer experience enabled by best-in-class services
• Ability to support rapid organisational change

The same research found that 39% of IT organisations reported a loss of competitive edge rather than a gain—a signal that cloud adoption without coherent strategy, skills investment, and architectural discipline can actively harm the business. The research also reinforced a point that many finance teams resist: delaying refresh and upgrade investments is not a saving. Deferred modernisation accumulates technical debt that ultimately costs more to resolve and imposes measurable drag on business performance in the interim.

Principles for a Workable Hybrid and Multi-Cloud Strategy

Based on the patterns described in the Forrester research and broader industry experience, effective hybrid and multi-cloud strategies share several characteristics:

1. Workload-first placement decisions. Evaluate each workload against the compute, security, compliance, latency, and integration requirements it actually has, then select the appropriate environment.
2. Portability as a design requirement. Architect applications to avoid deep dependency on proprietary platform APIs where the cost of that dependency exceeds its benefit. Containers and Kubernetes have become a common portability layer, though they introduce their own operational complexity.
3. Co-existence, not forced migration. Accept that a significant percentage of workloads will remain on-premises, and invest in the networking, identity, and management tooling that makes on-premises and cloud resources operate coherently together.
4. Centralised governance, decentralised execution. Standardise on security baselines, cost tagging, and compliance controls centrally, while allowing individual teams to choose cloud services that best serve their specific applications.
5. Skills investment as a first-order concern. Multi-cloud complexity compounds quickly without teams that understand the nuances of each platform. Training and hiring plans should be explicit components of any cloud strategy, not afterthoughts.

Conclusion

Hybrid and multi-cloud are not aspirational architecture patterns—they are the operational reality for most enterprises. The organisations that will gain competitive advantage are those that stop treating multi-cloud as a problem to be solved in favour of a single platform, and instead build the tooling, governance, and skills to operate heterogeneous environments well. Cloud adoption driven by genuine workload fit, with clear business outcomes attached, consistently outperforms adoption driven by the assumption that cloud is categorically better for everything.

The Forrester data is a useful reminder: technology investment without strategic clarity does not automatically translate to business value. The hard work—migrating complex workloads, upskilling teams, and building coherent multi-cloud operations—is where the real returns are found.

Myth 1: You Can’t Teach an Old Dog New Tricks

There’s a persistent belief that senior staff can’t adapt to DevOps ways of working—but experience often brings a hard-won appreciation for why silos and heavyweight Waterfall processes fail. Senior engineers who have lived through those frustrations can become some of the strongest advocates for change. That said, some senior staff will resist, just as some junior developers will. The challenge is not generational; it’s human.

To overcome this:

• Treat people as individuals, not stereotypes.
• Win allies early—engage top developers and solution architects in DevOps transformation decisions from the start.
• Invite senior staff into collaborative problem-solving around process improvements and tooling choices.
• Provide ample training opportunities, particularly just-in-time training that fits into existing workflows.
• Back requests with real budget and visible management support.

Myth 2: DevOps Collaboration Is Only for Developers and Sys Admins

A common misconception limits DevOps collaboration to the developer–operations relationship. In practice, information flows to many other teams—technical writers need access to early builds, marketing needs release timelines, and finance needs delivery cost data. Excluding these stakeholders creates gaps in communication and slows delivery.

Two practical approaches help bring non-developers into the loop:

1. Open the toolchain appropriately. Grant authorized staff outside development and operations role-based permissions to view data relevant to their work—without giving them the keys to production.
2. Reduce the learning curve. Provide job aids, short training sessions, or self-service dashboards. Third-party analytics and reporting tools embedded in the CI/CD toolchain can let stakeholders access the data they need without interrupting engineering workflows.

Myth 3: Diverse Teams Can’t Collaborate

When a diverse team struggles to collaborate, the root cause is usually culture or leadership—not diversity itself. Gimmicky team-building exercises won’t fix a culture that doesn’t genuinely welcome different perspectives.

Real fixes start at the top:

• Leadership must actively cultivate an environment that treats dissenting or non-traditional viewpoints as assets, not liabilities.
• Celebrate differences in background and discipline. A technical writer in a technical debate may surface user-experience issues that developers overlook.
• Make inclusive collaboration a core team value, not just a talking point in all-hands meetings.

Myth 4: Tools Don’t Matter

Poor tool selection has real consequences. When a collaboration or DevOps tooling decision is made top-down without developer input, the result is often shadow IT—teams building workarounds that fragment data, reduce visibility, and introduce security risks.

Make smarter tool decisions by:

• Running structured pilots on small, representative projects before committing to a purchase.
• Including a cross-section of development and operations staff in the evaluation.
• Collecting structured feedback and weighting usability alongside features and cost.

Myth 5: Soft Skills Aren’t Necessary in Technical Roles

The assumption that technical excellence is sufficient—and that skills like empathy, diplomacy, and clear oral communication are optional—is one of the most damaging myths in DevOps. Effective software delivery depends on developers and operations teams working as genuine partners, and that requires interpersonal skill, not just technical skill.

Building soft skills into the organization requires a systemic approach:

• Include soft skills criteria in job descriptions and evaluate them explicitly during interviews.
• Add communication expectations to onboarding documentation.
• Incorporate soft skills into annual performance reviews so they carry real weight.
• Partner with HR to provide accessible training—but acknowledge the scheduling challenge and offer asynchronous options where possible.

Myth 6: DevOps Eliminates Traditional IT Roles

DevOps does not mean every developer becomes a database architect, a cybersecurity specialist, and a cloud engineer simultaneously. What DevOps culture actually does is break down the walls between these disciplines—development, security, networking, QA, and operations—so that teams can deliver continuous value without waiting on handoffs between siloed departments.

Addressing this myth requires transparency:

• Communicate clearly that DevOps is about collaboration across roles, not role elimination.
• Hold managers and senior team members accountable for modeling cross-functional collaboration.
• Acknowledge that bringing together groups with different organizational priorities may require deliberate negotiation and executive support.

Myth 7: DevOps Requires Physical Co-location

Some managers still believe that effective DevOps collaboration requires everyone in the same room. This assumption is increasingly untenable—and was already becoming outdated before the widespread normalization of remote work. Remote engineers, third-party contractors, and cloud service providers are now integral participants in the software delivery lifecycle.

Distributed DevOps collaboration works when:

• Teams invest in the right communication and collaboration tooling—asynchronous and synchronous—and establish clear norms for using them.
• Processes are documented and transparent so that remote contributors can participate without depending on hallway conversations.
• Continuous improvement is established as a shared value from day one, not an afterthought once problems emerge.

Summary

DevOps collaboration myths persist because organizational change is hard and cultural transformation takes time. But each of these seven misconceptions is addressable with deliberate leadership, inclusive processes, smart tooling, and a genuine commitment to people—not just pipelines. Dismissing these myths is a necessary step toward a DevOps culture that actually delivers on its promise.

This article is based on themes originally published at searchitoperations.techtarget.com.

NFV Has Laid the Groundwork for Cloud-Native Telecoms

Communications service providers (CSPs) have been building toward cloud-native architectures for years, and the foundation they are building on is Network Functions Virtualization (NFV). According to Gabriele Di Piazza, VP of Solutions for VMware Telco Cloud Edge, the journey began in earnest with 4G. “4G kickstarted the shift towards virtualization and gave the operators experience,” he explained. New additions and expansions in 4G networks have been running in virtualized or cloud-based environments, making a fully physical packet core largely obsolete for new deployments.

A prominent example is Vodafone, which had been on its virtualization journey for more than five years at the time of reporting. Working with VMware, it completed the roll-out of its NFV Infrastructure (NFVi) platform, supporting more than 900 virtual network functions (VNFs) across 21 markets. That scale of deployment represents the operational muscle CSPs have developed through NFV — muscle that now needs to flex in a very different direction.

The Jump from VNFs to CNFs Is Not a Simple Swap

The move from virtual network functions (VNFs) to cloud-native functions (CNFs) is frequently mischaracterized as a straightforward upgrade. Di Piazza pushed back on that assumption directly: “The transition from virtualized functions to cloud native has a lot of implications… as applications are disaggregated into microservices, for the first time in many years there’s a need for the complete re-architecting of applications — it’s not a case of ‘I had a VNF and now I have a CNF and the problem is solved.'”

This architectural shift carries significant operational consequences. Moving to containerized, microservices-based network functions means operators must adopt CI/CD (continuous integration/continuous delivery) pipelines and Platform-as-a-Service (PaaS) deployment models that are fundamentally different from how they managed monolithic VNFs. The transformation is not just technical — it runs across the entire supply chain and introduces a significant skills gap at the human level.

Three Stars Must Align for Cloud-Native Telecoms to Work

Di Piazza outlined three interdependent conditions that must all be in place simultaneously before telcos can operate cloud-native networks at production scale:

1. Platform vendor maturity: Cloud infrastructure vendors — including VMware and its competitors — must deliver production-grade telco cloud platforms. Di Piazza was relatively confident here: “Sometimes I think this is the least of the problems because we are technology companies — this is what we do.”
2. CNF readiness from network function vendors: The containerized versions of core network functions need to be production-ready. At the time of the briefing, Di Piazza was candid: “Today CNFs, the containerized functions, are either barely ready or still in the process of being released.” Significant R&D work remained before those functions would be fit for telco production environments.
3. Carrier operational maturity: Operators themselves need to develop the Kubernetes expertise, CI/CD workflows, and cultural readiness to run cloud-native operations. This includes everything from retraining engineering staff to rethinking how software lifecycle management works at scale.

“If all three things are not in place at the same time — if you miss only one of those three — then you have a gap,” Di Piazza warned. He used a concrete illustration to convey the operational challenge: “Imagine deploying a network function continuously into tens of thousands of sites, updating these, maintaining a fresh version in a world where there is a new Kubernetes version every quarter” — that represents an entirely new operational paradigm for network engineers accustomed to long-lifecycle hardware and software deployments.

VMware’s Strategic Acquisitions Filled the Cloud-Native Gap

A few years prior to this briefing, VMware had limited credibility in the Kubernetes and cloud-native space. A series of acquisitions changed that trajectory. Di Piazza highlighted the purchases of Heptio (a Kubernetes-focused company co-founded by two of Kubernetes’ original creators), Pivotal Software (known for its Cloud Foundry PaaS platform), and Bitnami (an application packaging and deployment platform) as central to VMware’s cloud-native pivot.

“The transition towards the cloud native and containerized world matches really well with our recent acquisitions,” he said, adding that VMware was investing in automation, orchestration, and intelligence to build a more complete end-to-end portfolio. “Things are about to become way more complicated,” he acknowledged, positioning VMware’s portfolio evolution as a direct response to that increasing complexity.

VMware Telco Cloud Automation: From Project Maestro to GA

The product outcome of this portfolio evolution was VMware Telco Cloud Automation, previously known internally as Project Maestro. According to Di Piazza, it became generally available in February 2020. The platform is designed to address the orchestration and lifecycle management challenges that arise when deploying network functions not just in centralized data centers but across distributed edge locations — including central offices (near edge) and radio access network (RAN) sites (far edge).

“You have centralized sites and distributed sites, near edge in the central office or far edge all the way to the RAN, and with the RAN you have tens of thousands of endpoints — think about the impact that will have on orchestration and automation,” Di Piazza noted. Managing software lifecycle at that scale, with Kubernetes release cadence as a constant variable, is precisely the problem VMware’s telco cloud automation tooling aims to solve.

CSPs Are Becoming Their Own Systems Integrators

One of the more strategically significant observations from Di Piazza concerned the changing role of carriers themselves. Historically, CSPs relied heavily on large systems integrators to pull together complex network deployments. That model is shifting.

“The carriers are, de facto, becoming their own systems integrator as they undertake this digital transformation,” he said. “The network is at the heart of that transformation — this is their factory — and they are building those integration skills in-house.” This insourcing of integration capability is both a response to the complexity of cloud-native deployments and a strategic move to retain control over their most critical infrastructure.

Key Takeaways for DevOps and Platform Engineers in Telecoms

• NFV is the bridge, not the destination. Operators who invested in NFVi are better positioned for cloud-native, but the architectural assumptions are fundamentally different.
• CNF maturity was a real constraint in 2020. Platform readiness outpaced the readiness of the actual containerized network functions being deployed on it.
• Kubernetes operational skills are a critical bottleneck. The quarterly Kubernetes release cadence alone creates continuous operational pressure for teams unused to software-defined infrastructure.
• CI/CD isn’t optional for 5G core. Cloud-native 5G functions demand the same delivery automation that web-scale software companies use — applied to carrier-grade, highly available network infrastructure.
• Edge scale changes the orchestration problem entirely. Managing thousands of RAN edge sites is a qualitatively different problem from managing a handful of core data centers.

Image courtesy of VMware. Original reporting by TelecomTV.

Survey Overview

GitLab’s annual DevOps survey gathered responses from more than 3,500 developers across 21 countries. The survey covers three major areas: development and release practices, security, and testing. The overall picture is one of accelerating adoption — faster release cycles and improved quality — while emerging areas such as DevSecOps still require significant organisational fine-tuning.

Key Findings: Deployment Frequency and Role Evolution

The data points to a continued shift toward continuous deployment:

• 59% of companies now deploy at least once every few days, up from 45% in the previous year’s survey — a substantial year-over-year jump.
• 34% of developers report that they are now creating and managing the infrastructure their applications run on, reflecting a meaningful expansion of the traditional developer role into operations territory.
• Developers increasingly report fewer manual tasks such as manual testing, deployment, and code merging, indicating growing automation maturity.

At the same time, release velocity is not without friction. 47% of respondents identified testing as the primary reason for release delays, with bugs frequently discovered late in the release process rather than early in the pipeline.

Security: DevSecOps Still Maturing

Security integration remains a work in progress. Organisations continue to struggle with adopting practices like early Static Application Security Testing (SAST) scans and Dynamic Application Security Testing (DAST) as standard parts of their pipelines. While year-over-year progress is visible, DevSecOps as a discipline has not yet reached the same maturity level as core CI/CD practices in most organisations surveyed.

Interview: Brendan O’Leary, Senior Developer Evangelist, GitLab

InfoQ spoke with GitLab’s Senior Developer Evangelist Brendan O’Leary to unpack the survey findings and their broader implications.

On the Convergence of Development and Operations Roles

InfoQ: The survey confirms a significant portion of developers now play roles traditionally held by operations engineers. Is this a good trend? Where does it end? Will operations as traditionally understood eventually disappear?

O’Leary: I think this is a trend we’ll continue to see. DevOps aims to blur the lines between software engineering and operations engineering. While both disciplines have specific requirements, the more linked these disciplines become, the faster organisations can deliver stable software. When it comes to operating software, it’s critical for the developers of that software to have a deep understanding of how it operates at scale. At the same time, operators need to understand and deliver for the needs of the organisation’s main goal: delivering better products faster.

On the Challenges This Convergence Creates — Especially for Security

InfoQ: What challenges does the convergence of development and operations roles imply for the overall development process — and specifically for security?

O’Leary: The biggest challenge is the ability to connect real-world operations data with the changes either made or required to improve the customer experience. The old-style command-and-control security methodology doesn’t work when you’re shipping code to production every week, every day, or multiple times a day. The older disjointed toolchains developed for siloed roles need to evolve into a single DevOps platform that lets engineers work together and share a common set of data and measurements. We’ve seen the industry moving in this direction as DevOps tool makers consolidate around building a single platform for the entire software lifecycle.

On Shifting Testing Left — Benefits and Risks

InfoQ: Shifting testing left is widely seen as beneficial, but are there shadows to this trend? What risks should teams avoid?

O’Leary: Shifting testing left is critical to anyone’s DevOps transformation. However, there are risks if we don’t re-imagine what those tools look like in a modern DevOps context. Security testing must also shift earlier in the cycle, allowing developers to address issues before they progress further down the pipeline. It also becomes critical to invest as much attention in technical debt within CI/CD pipelines as we would with the product code itself. A “set it and forget it” testing model is no longer viable — the way we integrate, test, and deploy code needs to be just as adaptable as the code itself.

On Remote Work, COVID-19, and the Role of Tooling

InfoQ: The convergence of development, operations, testing, and security is fundamentally about communication and collaboration. How does this relate to the explosion of remote working driven by the COVID-19 pandemic?

O’Leary: The increased need for cross-discipline collaboration can directly benefit teams that now must collaborate remotely. From what we’re seeing in the industry, the current crisis has widened the gap between teams that have implemented effective communications and collaboration practices and those that have traditionally struggled. Long processes and organisational red tape have hindered velocity and have negatively impacted teams that now have to work together remotely. Organisations that had already invested in integrated tooling and async-friendly workflows were far better positioned to adapt.

What These Trends Mean for DevOps Teams

Taken together, the survey findings and O’Leary’s commentary point to several actionable takeaways for DevOps practitioners:

• Automate earlier and more broadly. The jump in deployment frequency is driven by automation. Teams that have not yet automated manual testing, deployment, and merging should treat this as a priority.
• Treat security as a pipeline concern, not a gate. Integrating SAST and DAST earlier in the pipeline reduces the cost of remediation and removes security as a bottleneck at release time.
• Invest in CI/CD pipeline maintainability. Pipelines accumulate technical debt just like product code. Treat them with the same engineering discipline.
• Consolidate toolchains. Fragmented tooling across roles makes collaboration harder. A unified platform with shared data reduces friction between development, operations, and security teams.
• Build collaboration infrastructure before you need it. Teams with mature async communication practices adapted more readily to forced remote work. Don’t wait for a crisis to build those habits.

The original interview with Brendan O’Leary was published on InfoQ. The survey data cited is from GitLab’s annual DevOps survey published in 2020.

What Are DevOps Tools?

DevOps tools are software platforms and utilities designed to break down silos between development, operations, and quality-assurance teams. By standardising and automating the movement of code through build, test, and deployment pipelines, they accelerate the software delivery lifecycle while reducing human error. Common functional categories include:

• Source control and collaboration – version control systems and code-review platforms
• Continuous integration / continuous delivery (CI/CD) – automated build and release pipelines
• Configuration management and infrastructure-as-code – tools that provision and maintain environments declaratively
• Monitoring and observability – platforms that provide real-time insight into application and infrastructure health
• Container orchestration – systems that manage containerised workloads at scale

Market Overview

The global DevOps tool market experienced sustained expansion heading into 2020, driven by enterprises accelerating their digital transformation programmes. The market spans tooling sold as on-premises software, cloud-based SaaS, and hybrid deployments, and is consumed across virtually every industry vertical — from financial services to healthcare to retail.

COVID-19 introduced both disruption and acceleration. Organisations that had invested in DevOps practices and cloud-native tooling were better positioned to shift their workforces to remote work quickly, maintain deployment velocity, and adapt products to rapidly changing customer needs. This dynamic is widely credited with accelerating cloud and DevOps adoption among organisations that had been slower to modernise.

Key Market Drivers

Several forces are pushing enterprise investment in DevOps tooling:

• Enterprise digitalisation – Organisations across manufacturing, retail, and financial services are automating business processes, increasing demand for reliable software delivery pipelines.
• Agile and cloud adoption – The widespread shift to agile methodologies and cloud-native architectures requires tooling that supports iterative, frequent releases.
• Collaboration between IT disciplines – Growing pressure to reduce mean time to recovery (MTTR) and accelerate feature delivery is pushing teams toward shared toolchains and shared responsibility models.
• IoT, mobility, and BYOD initiatives – Expanding device ecosystems increase the complexity of software environments, making automated testing and deployment more valuable.
• Cost reduction through automation – Automating repetitive tasks in testing, provisioning, and deployment delivers measurable reductions in engineering overhead.
• R&D investment by major vendors – Leading platform vendors continue to invest in new capabilities — particularly around AI-assisted operations (AIOps), security integration (DevSecOps), and low-code pipeline configuration.

Market Restraints

Despite strong tailwinds, the market faces meaningful challenges:

• Skills shortage – Demand for engineers with deep DevOps expertise consistently outpaces supply, slowing adoption particularly in mid-market organisations.
• Lack of standardisation – The DevOps toolchain ecosystem remains fragmented. Organisations frequently assemble bespoke stacks from dozens of point solutions, increasing integration complexity and total cost of ownership.
• Cultural resistance – Tooling adoption alone does not produce DevOps outcomes; organisational change management is a persistent barrier that technology vendors cannot solve on their own.

Market Segmentation

By Deployment Mode

Cloud-based (SaaS) DevOps tools are projected to record the strongest growth across the forecast period. The primary reasons are lower upfront capital expenditure, elastic scalability, built-in high availability, and reduced operational burden on internal IT teams. Cloud deployment also aligns naturally with modern containerised and microservices architectures, making it the default choice for greenfield projects and cloud-migration programmes.

By Enterprise Size

Large enterprises account for a significant share of market revenue. Their complex, multi-team engineering organisations and high deployment frequency create both the need and the budget for comprehensive, integrated DevOps platforms. However, mid-market and SMB adoption is growing as SaaS delivery models reduce the barrier to entry.

By Industry Vertical

The IT sector is the largest consumer of DevOps tooling — unsurprisingly, given that software delivery is the core business. Banking, Financial Services, and Insurance (BFSI) is the second-largest vertical, driven by the rapid growth of online and mobile banking, rising consumer expectations for digital services, and the competitive pressure to release features faster than fintech challengers.

Regional Analysis

North America and Europe

North America holds the largest share of global DevOps tool market revenue, reflecting the density of large technology companies, mature cloud infrastructure, and early enterprise adoption of agile and DevOps practices. Europe follows, supported by significant digital investment across financial services, manufacturing, and the public sector, as well as active regulatory pressure to improve software quality and auditability.

Asia Pacific

Asia Pacific represents the fastest-growing regional market. Rapid smartphone penetration, expanding digital infrastructure, and technology investment by governments and large enterprises in China, India, Japan, and South-East Asia are all contributing to rising demand for DevOps tooling. The region’s large base of software development talent is also a structural advantage for DevOps adoption.

Competitive Landscape

Key vendors operating in the global DevOps tool market are pursuing several strategic approaches to maintain and grow market position:

• Mergers and acquisitions – Platform vendors are acquiring specialist point-solution providers to broaden their toolchain coverage and reduce the integration burden on customers.
• Partnership ecosystems – Collaboration with cloud hyperscalers, system integrators, and consultancies extends market reach and embeds products into large enterprise programmes.
• Innovation labs and centres of excellence – Investment in internal research and partnerships with academic institutions is producing advances in AI-driven testing, predictive deployment risk assessment, and automated remediation.

COVID-19 Impact on the DevOps Tool Market

The pandemic accelerated several trends already present in the market:

• Remote-first engineering – Distributed teams increased reliance on cloud-hosted CI/CD pipelines, collaborative code-review platforms, and chat-integrated deployment workflows.
• Faster digital product iteration – Businesses pivoting to digital channels needed to ship new features and integrations at unprecedented speed, raising the value of automated delivery pipelines.
• Budget reallocation – Some organisations deferred on-premises hardware refreshes in favour of cloud-based tooling, accelerating the SaaS deployment trend.
• Security scrutiny – The sudden expansion of remote access surfaces increased focus on DevSecOps — integrating security scanning and policy enforcement directly into the delivery pipeline.

Key Takeaways

The global DevOps tool market in 2020 is characterised by strong structural growth, a fragmented but consolidating vendor landscape, and an accelerating shift to cloud-based delivery. The COVID-19 pandemic acted as a forcing function for digital transformation, benefiting organisations with mature DevOps practices while exposing gaps in those still reliant on manual, on-premises processes. For engineering leaders, the near-term priorities are toolchain consolidation, investment in developer skills, and integrating security earlier in the software delivery lifecycle.

Source: Originally reported by 3wnews.org, citing research by Trusted Business Insights.

The Problem Kasten Was Built to Solve

Like many successful startups, Kasten emerged from direct, personal experience with a hard problem. Co-founders Niraj Tolia and Vaibhav Kamra joined EMC through the 2014 acquisition of Maginatics, a company that provided a secure global namespace across storage platforms. When Tolia’s team began migrating their product’s control plane to Google Cloud and Kubernetes in 2015, the experience was painful enough to spark an idea.

“We were discovering integration issues much earlier in the lifecycle of product development than what we’ve traditionally seen,” Tolia explained. “This is five years ago, so that’s when the lightbulb went off in my head that this is going to be the future.”

At EMC, the team was working within the data protection group and found that existing tooling simply didn’t scale to Kubernetes workloads. Scripts were hand-crafted, brittle, and impractical at any meaningful scale. Kasten was founded in 2017 — its name taken from the German word for “box” or “container” — to build data management tooling that was truly cloud-native from day one.

Why Traditional Backup Tools Fail in Kubernetes Environments

Traditional data management platforms were designed for virtual machines with relatively static configurations. Kubernetes changes the fundamental assumptions those tools rely on:

• Component explosion: Tolia describes a roughly 100x increase in the number of discrete components that need to be captured compared to VM-based workloads.
• Frequent rescheduling: Pods are ephemeral and can be rescheduled at any time, making point-in-time snapshots taken at the infrastructure layer incomplete or inconsistent.
• No VM-to-application mapping: Legacy backup tools rely on VM identity to understand application boundaries. In Kubernetes, that mapping doesn’t exist.
• Network policy conflicts: Some legacy vendors require firewall exceptions or open network policies to access cluster internals — an approach that directly conflicts with Kubernetes security models.
• Constantly changing applications: Microservice architectures deploy frequently, so backup tooling must continuously rediscover application topology rather than relying on static configuration.

The K10 Platform: Architecture and Key Concepts

Kasten’s K10 platform is itself deployed as a Kubernetes application — what Tolia describes as a “critical cluster” pattern. K10 installs into its own namespace and uses a Kubernetes service account to discover and orchestrate other applications running on the same cluster. It also integrates with the underlying physical storage infrastructure.

Application Auto-Discovery

K10 uses Kubernetes-native APIs to automatically discover containerized applications, their components, startup processes, and associated policies. Rather than requiring manual inventory or agent installation on each workload, discovery is driven by the Kubernetes control plane itself.

Restore Points: More Than a Data Snapshot

A core K10 concept is the restore point — an atomic unit that captures not just volume data but the complete application state within a Kubernetes namespace, including:

• Kubernetes resource definitions (Deployments, Services, StatefulSets, etc.)
• Secrets and ConfigMaps
• Container image references
• Service account bindings
• Networking configuration

This dependency tree means a restore point can be used to fully reconstruct an application on a different cluster, region, or cloud provider without manual reconfiguration.

CSI Integration and Storage Agnosticism

K10 uses the Kubernetes Container Storage Interface (CSI) abstraction layer to interact with block and object storage systems. This means K10 does not need to understand the proprietary APIs of individual storage arrays. It works with a wide variety of storage backends and is designed to be storage-agnostic — it is not a storage system itself but a data management layer on top of existing infrastructure.

Blueprints: Agentless Extension for Complex Workloads

For workloads that require coordination across multiple services before a backup can be taken consistently — such as flushing a database write-ahead log — K10 provides an agentless extension mechanism called blueprints. Blueprints allow operators to define pre-backup preparation steps and post-restore transformation steps without modifying the application itself or its deployment pipeline.

Blueprint transforms are particularly useful during migrations: for example, updating DNS names, regenerating TLS certificates (such as those issued by Let’s Encrypt), or adjusting environment-specific configuration values as an application moves from production to a test environment.

Typical Backup and Migration Workflow

The K10 workflow for backup and cross-cluster migration follows a consistent pattern:

1. Scope a namespace — select the Kubernetes namespace representing the application to protect.
2. Run a backup action — K10 creates a restore point capturing data and all associated Kubernetes resources.
3. Run an export action — the restore point is exported to an object store (for example, Amazon S3 or a compatible endpoint).
4. Apply a backup policy — schedule the above steps on an hourly, daily, or weekly cadence.
5. Create an import policy on the destination cluster — the import action retrieves the exported restore point.
6. Run a restore action — the namespace, data, and configuration are recreated on the destination cluster, optionally with blueprint transforms applied.

This workflow applies equally to disaster recovery, environment promotion (production to staging), and full cluster migration.

Real-World Use Case: Sopra Steria’s OpenShift Migration

Sopra Steria, a UK-based IT consultancy, used K10 when migrating close to 200 applications from OpenShift 3.11 to OpenShift 4.3. Lead DevOps architect Michael Courcy described the process in a webinar, noting that K10’s restore-point model — combining data snapshots with full Kubernetes resource state — made it practical to migrate applications at scale while accommodating infrastructure differences between the source and destination clusters, including DNS name changes handled via blueprint transforms.

Balancing Operator and Developer Needs

K10 is designed to serve two audiences with different priorities:

• Operations teams get policy-driven automation, global visibility across multiple clusters, alerting, and compliance management without manual per-application configuration.
• Development teams are largely unaffected — K10 requires zero changes to application code or deployment pipelines. Developers who want finer control can optionally use blueprints to customise backup and restore behaviour for their specific workloads.

Cloud Native Transformation Framework

Kasten introduced the Cloud Native Transformation Framework as part of its Application Transformation Engine. According to the company, this layer adds capabilities including:

• Capture of underlying data and additional metadata
• Lock-free algorithms to reduce backup contention
• Pluggable encryption and compression
• Advanced deduplication to reduce storage consumption
• Smaller fault domains to improve backup reliability

Deployment and Scalability

K10 runs both on-premises and in public cloud environments. Because it is itself a Kubernetes application, it scales with the workload and does not require dedicated backup infrastructure separate from the cluster it protects. This can reduce overall IT infrastructure footprint compared to traditional backup appliances or agents.

Summary

Kasten K10 addresses a genuine gap: the mismatch between Kubernetes’ dynamic, namespace-scoped application model and the VM-centric assumptions baked into legacy backup tools. By treating a Kubernetes namespace as the unit of protection — capturing data, configuration, and resource state together — K10 makes backup, restore, disaster recovery, and cross-cluster migration operationally tractable for teams running stateful workloads on Kubernetes at scale.

Google Cloud Launches Its Las Vegas Region

Google Cloud opened a new cloud region in Las Vegas, Nevada in May 2020, expanding its infrastructure footprint in the western United States. With this launch, Google reached four cloud regions in the western US, seven regions across the entire United States, and 23 regions worldwide at the time of the announcement.

Western US Region Coverage

Prior to Las Vegas, Google Cloud’s western US regions included Los Angeles, California and Salt Lake City, Utah, along with at least one additional western location. Adding Las Vegas strengthens Google’s ability to serve customers and end users across the western United States with lower network latency, greater redundancy, and improved capacity for workload distribution.

For DevOps and platform engineering teams, multi-region deployments in the western US mean workloads can be distributed across geographically distinct data centers — reducing blast radius in failure scenarios and enabling compliance with data residency requirements.

Availability Zones: Infrastructure Architecture

Like all Google Cloud regions, the Las Vegas region provides access to three availability zones. Each zone operates with independent software, power, cooling, networking, and security infrastructure, as well as its own compute and storage resources. This zone-level isolation is a key design principle for building highly available, fault-tolerant systems on Google Cloud.

• Independent power and cooling per zone reduces correlated failure risk.
• Separate network infrastructure allows traffic isolation between zones.
• Distinct compute and storage resources let teams distribute stateless and stateful workloads across zones for resilience.

Early Adopter: Aristocrat Gaming

One of the first customers to leverage the Las Vegas region was Aristocrat, a company specializing in digital gaming products including casino games. Given Las Vegas’s position as a global center of the gaming industry, proximity to this region offers Aristocrat reduced latency to players and operational infrastructure in an industry where real-time responsiveness is critical.

Cloud Growth Context: Q1 2020

The Las Vegas region launch came as Google reported strong cloud revenue growth for Q1 2020, with cloud revenue climbing 52 percent year-over-year despite the COVID-19 pandemic significantly impacting Google’s advertising business. This divergence highlighted the continued investment momentum in enterprise cloud infrastructure even during broader economic uncertainty.

For teams evaluating multi-region Google Cloud deployments in the western US, the Las Vegas region (region identifier us-west4) is a viable option for latency-sensitive workloads targeting Nevada, the broader Mountain West, and western gaming or entertainment industries.

Source: ZDNet

AWS Europe (Milan) Region Goes Live

Amazon Web Services (AWS) launched its Europe (Milan) Region in April 2020, bringing full datacentre infrastructure to Italy at a time when Italian businesses were under acute pressure from the Covid-19 pandemic. The announcement was made by Amazon.com CTO Werner Vogels in an official AWS blog post.

Italy was among the earliest and hardest-hit countries during the initial Covid-19 outbreak, and was one of the first nations to enforce a nationwide quarantine. The timing of the region launch reflected both long-standing expansion plans and an urgent need to support Italian organisations moving workloads to the cloud.

Why AWS Pressed Ahead During the Pandemic

In his launch post, Vogels framed the opening as part of AWS’s commitment to the communities it serves. He noted that education providers, healthcare organisations, and research teams across Italy were already using AWS services to support pandemic response work — and that locally hosted infrastructure would reduce latency and help those organisations meet data residency requirements.

“Now, more than ever, we are seeing customers use efficient and secure cloud computing infrastructure to make a meaningful impact on lives around the world.”

Werner Vogels, CTO, Amazon.com

Vogels highlighted three primary cloud use cases driving demand in Italy at the time: empowering scientific research, facilitating remote work and remote learning, and delivering new digital services in response to the health emergency.

What the Milan Region Means Architecturally

The Europe (Milan) Region follows the standard AWS regional model: each region contains multiple Availability Zones (AZs), and each AZ consists of one or more physically separate datacentres. This architecture is designed to provide:

• Resiliency: Workloads can be distributed across AZs to survive the failure of a single facility.
• Low latency: Applications served from in-country infrastructure have lower round-trip times for Italian end users compared with requests routed to, for example, Frankfurt or Dublin.
• Data residency: Organisations in regulated industries can keep data within Italy, which is important for compliance with Italian and EU data-protection rules.

At the time of launch, the Milan Region was the sixth AWS region in Europe and brought AWS’s total global footprint to 76 Availability Zones across 24 geographic regions.

Italy’s Prior AWS Presence: Edge Locations vs. a Full Region

It is worth distinguishing between an AWS edge location and a full datacentre region, because Italy already had the former before the Milan Region launched.

Before April 2020, Italian customers could cache content locally via edge locations but had to run compute and storage workloads in other European regions such as Frankfurt (eu-central-1) or Ireland (eu-west-1). The Milan Region changed that by making the full AWS service catalogue available on Italian soil.

Industries and Use Cases in Italy

Peter DeSantis, AWS Senior Vice President of Global Infrastructure and Customer Support, cited a broad spread of Italian industries already using AWS technology prior to the full region launch:

• Automotive
• Utilities
• Manufacturing
• Retail

DeSantis described Italian AWS customers as “among the most creative and innovative organisations” on the platform globally, and said the Milan Region was intended to accelerate innovation across virtually all industry verticals in the country.

Context: AWS European Region Expansion

The Milan Region was the sixth AWS region in Europe at launch. European regions that preceded it include Ireland, Frankfurt, London, Paris, and Stockholm. The geographic spread allows AWS customers operating across the EU to architect multi-region solutions that balance latency, compliance, and cost — without routing traffic outside of Europe.

For DevOps engineers and cloud architects, the practical takeaway is straightforward: workloads that previously had to tolerate cross-border latency or could not store data outside Italy can now be deployed natively in eu-south-1 (the AWS region code for Europe Milan), using the same Infrastructure-as-Code tooling — CloudFormation, Terraform, AWS CDK — used in any other AWS region.

Key Takeaways for Cloud Engineers

• The AWS Europe (Milan) Region (eu-south-1) launched in April 2020 and provides full AZ-backed infrastructure in Italy.
• Italy had AWS edge/CDN presence since 2012, but compute and storage workloads previously required routing to other EU regions.
• At launch, the region brought the global AWS total to 76 AZs across 24 geographies.
• The Milan Region is relevant for Italian data-residency compliance, latency-sensitive applications, and regulated-industry workloads.
• All standard AWS IaC and deployment tooling works with eu-south-1 with no special modifications beyond region targeting.

GitLab Broadens Its Global Partner Ecosystem

GitLab has expanded its global partner program to encompass both technology partners and channel partners, with the stated goal of helping more organizations navigate the DevOps transformation journey. The program is designed to function as a single destination where customers can access GitLab’s platform capabilities alongside complementary services and technology solutions delivered through partner relationships.

The expansion builds on earlier channel investments. In January 2020, GitLab hired Michelle Hodges as vice president of global channels, signaling a deliberate push to grow its indirect sales and services motion alongside its direct business.

Incentive-Driven Structure Replaces Traditional Tiers

One of the more notable design choices in the revamped program is the deliberate departure from a conventional tiered or medallion partner structure. Rather than classifying partners as Gold, Silver, or Bronze (or equivalent labels), GitLab instead focuses on propelling partner relationships through targeted incentives and investments.

The practical effect is that partners are rewarded for actively building GitLab-related services practices rather than simply hitting revenue thresholds. According to Brandon Jung, GitLab’s vice president of alliances, this approach addresses direct feedback from partners who wanted to build high-value joint offerings for customers rather than compete for badge status.

“When you look at the structure of the program, it is designed to allow partners to engage with customers in several different ways. In speaking with our partners, we got consistent feedback that they wanted to build joint high-value offerings for our customers. In order to do so, we are fostering a partner community that is built on more strategic relationships and creates an environment where every partner can contribute.”

Brandon Jung, VP of Alliances, GitLab

Key Technology Partner Integrations

The program strengthens existing relationships with major cloud and infrastructure providers. Jung specifically cited the following technology partners as central to the expanded ecosystem:

• Amazon Web Services (AWS)
• Microsoft Azure
• Google Cloud Platform
• VMware
• HashiCorp

These integrations are aimed at giving joint customers a cohesive experience across the DevOps lifecycle—from source code management and CI/CD pipelines through to infrastructure provisioning and secrets management.

“We are building on our current technology partner relationships with the largest cloud and Kubernetes providers (AWS, VMware, Azure, Google Cloud Platform, HashiCorp) to continue to strengthen the program and ensure success of our joint customers.”

Brandon Jung, VP of Alliances, GitLab

HashiCorp Integration: Terraform and Vault

HashiCorp’s VP of Global Alliances, Burzin Patel, highlighted two specific product integrations as delivering immediate customer value: HashiCorp Terraform for infrastructure-as-code provisioning and HashiCorp Vault for secrets management. Both are positioned as out-of-the-box integrations within the GitLab DevOps lifecycle.

“HashiCorp has been working closely with GitLab to enhance the experience for our joint customers, and we are looking forward to even greater connections between our companies and products as part of this new program. The HashiCorp Terraform and Vault product integrations offer a great out-of-the-box experience to customers looking to secure and manage their infrastructure as part of their DevOps lifecycle.”

Burzin Patel, VP of Global Alliances, HashiCorp

What the Program Means for Partners

From a business model perspective, the GitLab partner program is structured to create margin opportunities through services delivery rather than product resale alone. Jung acknowledged that many partners are actively looking to grow their services revenue, and the program is designed to reward those that build and staff GitLab-focused DevOps service practices.

The broader theme Jung articulated is that partners face the same organizational challenges their customers do—finding the right people, processes, and platforms to support digital transformation. The partner program is intended to provide resources and community structure to help partners solve those challenges at scale.

“Many businesses are looking for the right people, processes and technology platforms to enable them on their digital transformations. Bringing all of this together as we build these partnerships is critical to meeting customer demands and enabling their achievements.”

Brandon Jung, VP of Alliances, GitLab

Summary

GitLab’s expanded partner program reflects a broader trend in enterprise software: replacing rigid partner tiers with more flexible, incentive-driven structures that reward demonstrable customer outcomes and services investment. For DevOps practitioners, the practical takeaway is a growing ecosystem of certified partners capable of delivering integrated GitLab deployments alongside cloud, Kubernetes, and infrastructure-as-code tooling from major providers.

From Productivity Suite to Critical Infrastructure

When COVID-19 triggered widespread lockdowns in early 2020, organizations of every size were forced to become remote-first almost overnight. For many, the tooling to support that shift was already in place — but the scale at which it suddenly needed to operate was unlike anything planned for. Google Meet, the video-conferencing component of G Suite, became a striking example of cloud infrastructure absorbing a demand surge that would have broken most on-premises deployments.

Google reported that Meet was gaining more than two million new users every single day, with participants collectively logging over two billion minutes of meeting time per day — equivalent to more than 3,800 years of video calls in a 24-hour period. That figure is a useful illustration of why elastic, globally distributed cloud infrastructure matters: no fixed-capacity data center estate could have absorbed that growth curve without significant disruption.

The Infrastructure Behind the Scale

Google Meet runs on the same global infrastructure that underpins Google Search, Gmail, and YouTube. Key characteristics that allowed it to absorb the COVID-19 demand spike include:

• Elastic compute capacity: Google’s infrastructure is designed to allocate resources dynamically across its global fleet, rather than relying on pre-provisioned capacity tied to a single region.
• Purpose-built global network: Google owns and operates a private fiber backbone interconnecting its data centers, reducing reliance on the public internet for latency-sensitive traffic such as real-time video.
• Encryption by default: Meet encrypts data in transit and at rest, a requirement that becomes more visible — and more consequential — when sensitive use cases such as telemedicine and judicial proceedings move onto the platform.
• Zero-trust security model: G Suite’s architecture means users authenticate through Google’s identity layer rather than requiring a VPN, a significant operational advantage when corporate VPN gateways were themselves becoming bottlenecks during the pandemic.

Google also made advanced Meet features available at no cost to all G Suite and G Suite for Education customers during this period, later extending that offer through September 30, 2020.

Real-World Deployments: What Rapid Digital Transformation Looks Like

The following examples, drawn from Google’s own reporting, illustrate the breadth of industries and use cases that shifted onto cloud collaboration tooling during the pandemic. They are useful reference points for DevOps and platform teams thinking about enterprise-scale rollouts and resilience planning.

Healthcare: Cambridge Health Alliance

Cambridge Health Alliance, a health system serving 140,000 patients across Cambridge, Somerville, and Boston’s Metro North region, leaned heavily on G Suite for staff communication. James LaPlante, Sr. Director of Technology and Biomedical Services, noted that staff could connect from Gmail, Calendar, or Meet-enabled conference rooms across three hospitals and 15 health centers with a single click — a practical example of how unified identity and calendar integration reduces friction in high-pressure environments.

Government: Peru’s Judiciary and Hackney Council

Peru’s Judiciary branch used Meet to continue both internal meetings and formal hearings during a nationwide quarantine, allowing attorneys, lawyers, and clerks to participate without physical attendance. In the UK, Hackney Council deployed G Suite and Chromebooks across a 4,000-person staff to maintain essential citizen services. Both cases highlight a pattern relevant to platform engineers: when devices are heterogeneous and procurement cycles are slow, browser-based SaaS tools provide a faster path to continuity than client-heavy alternatives.

Manufacturing: KAESER Compressors and Kärcher

German manufacturing company KAESER Compressors had adopted G Suite in 2018. That prior investment allowed them to move 4,000 employees to remote work with minimal disruption when lockdowns began — a clear demonstration of the operational value of standardizing on cloud tooling before a crisis forces the issue.

Kärcher, also German and known for its cleaning equipment, had originally planned a G Suite rollout by 2021. The pandemic forced an acceleration: the company deployed G Suite to its entire 14,000-person workforce in five days. Weekly active users of Meet and Chat grew 20x by the end of March 2020. This is a noteworthy case study in emergency enterprise rollout — and in the tradeoffs between a controlled, phased deployment and a rapid all-hands migration.

Retail and Logistics: NTUC FairPrice and Schnucks

NTUC FairPrice, Singapore’s largest supermarket chain, reported a capacity demand increase of over 400% as customers stocked up during the pandemic. G Suite helped the organization manage this surge while simultaneously transitioning most of its workforce to remote work — a dual operational challenge that illustrates the value of integrated collaboration tooling when both demand and workforce models change at the same time.

Schnucks, a family-owned US supermarket chain with 100 stores across five Midwest states, adapted Meet in a creative operational context: running a 24/7 helpdesk channel accessible to both corporate and in-store employees, and using a Meet “hotline” as a work-from-home dispatch platform for its transportation department. This is a practical example of repurposing a video-conferencing tool as lightweight operational infrastructure — a pattern worth noting for platform teams looking for low-overhead solutions to internal communication bottlenecks.

Enterprise Software: Salesforce and Shopify

Salesforce reported handling 50,000 video calls per workday on Google Cloud — double their pre-pandemic volume — without reliability issues. Andy White, VP of Platform Engineering at Salesforce, attributed this to Google Cloud’s scale and support.

Shopify’s Director of Technical Infrastructure, Garth Pyper, described a 20-person meeting that livestreamed simultaneously to 4,000 employees without problems. With 5,000 employees relying on Meet as their primary video-conferencing tool, reliability at that scale was non-negotiable.

Broadcasting: Milenio Televisión

When a news anchor at Mexican cable news channel Milenio Televisión self-quarantined after potential COVID-19 exposure, the channel used Meet to keep its broadcasts on air — citing security and audio/video quality as the deciding factors. The channel extended this to video conferences with correspondents in other countries, effectively using a business collaboration tool as broadcast infrastructure.

Key Takeaways for Platform and DevOps Teams

The COVID-19 acceleration of digital transformation surfaced several durable lessons for teams responsible for internal platforms and productivity infrastructure:

1. Pre-pandemic investment in cloud tooling pays off in a crisis. Organizations that had already standardized on cloud-based collaboration — KAESER, Korean Air, TELUS International — transitioned significantly faster than those that had not.
2. Emergency rollouts are possible but carry risk. Kärcher’s five-day G Suite deployment for 14,000 users is impressive, but rapid rollouts typically compress testing, change management, and training timelines. Platform teams should document what those tradeoffs look like in their own environments.
3. SaaS eliminates one class of infrastructure problem while creating others. VPN bottlenecks, hardware procurement delays, and capacity limits largely disappeared for organizations on cloud tooling. New challenges — identity management, endpoint security, and data governance at scale — moved to the foreground.
4. Resilience is a product of architecture, not just redundancy. Google’s ability to absorb 2 million new users per day was a function of its global network design, not simply having more servers. Elastic, distributed architecture is the correct model for workloads with unpredictable demand profiles.
5. Collaboration tooling can serve operational as well as productivity use cases. The Schnucks dispatch hotline and Peru’s judicial hearings are examples of meet-in-the-middle adaptations that should prompt platform teams to think broadly about what their tooling can support under pressure.

Context and Caveats

The data points and quotes in this article originate from Google’s own communications, published in April 2020. They should be understood as a snapshot of conditions at that specific moment rather than a sustained benchmark. The “2 million new users per day” and “2 billion minutes per day” figures reflect peak pandemic onboarding, not steady-state usage. G Suite has since been rebranded as Google Workspace. Pricing, feature availability, and free-tier offers described here applied to the period around April 2020 and have changed since.

It’s taken just a couple of decades for humanity to develop a digital reflex. The consulting of connected devices has become second nature, and software applications are now the primary interface between a business and its customers. This means app performance has become business-critical. Customers demand speed, accuracy and accessibility. And apps are the primary source of the digital era’s most precious resource — data.

When apps don’t work, customers go elsewhere. Fast. And when customers move to a competitor’s app, that competitor gains their data value, as well as their business.

“We know, from our app retention index, that 50% of users are willing to pay more for a competitor’s product if it performs and gives them a better experience,” said Danny Winokur, general manager at AppDynamics, a Cisco company.

Even worse, 63% of users in AppDynamics’ app-retention index not only drop the app, but tell everyone else to drop it as well. And these days, it doesn’t take many influencers spreading bad reviews on social media to affect a company’s brand reputation.

Keep an eye on your apps

AppDynamics was founded in 2008 to provide digital companies with a way to monitor and optimize their real-time business performance. Its Application Intelligence Platform was unique, in that it used digital agents and bots to track the source of slow-downs across the entire application ecosystem.

The company received several successful rounds of filing, and by 2017 it had an established product portfolio underpinned by the enhanced Application Intelligence Platform. Its strategy was simple: “Applications are really becoming the foundation of the modern business, and understanding the performance of those applications, the users, the application, the business metrics themselves is critical, as this really signifies the brand for most companies,” said Thomas Wyatt, chief product officer at People.ai and previous chief strategy officer at AppDynamics.

Hopes for a rebirth in tech initial public offerings were kindled when AppDynamics filed for an IPO in 2017. Then, just one day before its market debut, Cisco Systems Inc. acquired the company at a massive $3.7 billion price tag. This was more than twice what it had been estimated to gain from its IPO. The surprise switch even had some wondering if AppDynamics had pulled a “classic M&A fake” to lure potential buyers.

It was a bold move. Cisco is known for its aggressive acquisitions policy, but at the time, the company was undergoing an internal restructuring as it prepared to take on the cloud market. Rowan Trollope, then senior vice president and general manager of internet of things and Applications at Cisco justified the strategy, saying, “We acquired AppDynamics because they are a market leader in a category that will be a cornerstone for how enterprises drive their business forward, Together, AppDynamics and Cisco will be the only company that can deliver complete visibility spanning from the infrastructure to application to end user.”

Application performance management is a growing market … and so is cloud computing
The prediction was sound. In the year after Cisco purchased AppDynamics, the Application Performance Management Software Market grew 13.4% to annual revenue of $4.3 billion. From $4.3 billion in 2018, the market grew to $5.8 billion in 2019. In addition, research firm Mordor Intelligence predicts the market will continue to grow at 12% CAGR from 2020 to 2026 to a value of $11.43 billion.

But more important than a financial investment, AppDynamics has proved to be central to Cisco’s play in the complex market of hybrid and multicloud.

The company seems to have an uncanny knack for making purchases that chart the course of enterprise computing. Competing with the cloud-native tech giants has caused many traditional tech companies to struggle, and Cisco is no different. As software increasingly replaces traditional hardware, Cisco has expanded its portfolio in a way that supports its position as a leader in infrastructure while moving toward software-centric solutions.

The AppDynamics purchase was a ground-floor investment that cemented the company’s commitment to cloud-native architecture. Since then, Cisco has purchased companies with a view to combining their cloud-native savvy with its existing expertise. Some examples are software-defined networking startup Viptela Inc. and hyperconverged infrastructure vendors Springpath Inc. and Skyport Systems Inc.

Cisco’s cloudification

With compute all but virtualized, cloud is moving to the next level in its quest to turn traditional hardware software-centric: Network virtualization.

“The public cloud itself now has become such a super-compute system that it’s like a massive computer. And, of course, a massive computer has massive networking,” said Saar Gillai, independent board director and chief executive officer adviser and former senior executive at Cisco Systems Inc. and Hewlett Packard Enterprise Co.

With edge computing, 5G, and WiFi 6 due to debut in 2020, next-generation networks hold the promise of fulfilling the potential of the internet of things.

“Traditional networking companies such as Cisco are hoping their strength in data centers and corporate networks along with newly developed and acquired 5G and other edge technologies can help them remain a mainstay in enterprises as they rethink their networks,” stated Wikibon’s Paul Gillin in a special report on NextGen Networks for SiliconANGLE.

Once again, AppDynamics is helping Cisco join the dots. Over the past three years, Cisco has been integrating AppDynamic’s technology throughout its portfolio.

“The whole point now is about multidomain and actually connecting the different layers of the technology stack to produce insights,” said Winokur. “The winners in an experience-driven world are those that can implement with velocity, not break things, and deliver well-designed, beautiful experiences.”

Cisco guides AppDynamics’s strategy from performance monitoring to customer journey analysis
AppDynamics has made several key changes in its offerings over the past three years. And all have the common focus of supporting Cisco as it reboots for a hybrid and multicloud world.

Rather than focusing on monitoring performance at the application level, the platform has adapted to the needs of the digital business by providing common tools across the technology stack. “As changes in the market push [teams] to work together, they need common tooling and common data sets,” Winokur said.

As part of this shift, AppDynamics updated its platform to provide Kubernetes monitoring. Integrating the machine-learning technology of Cisco acquisition Perspica Inc. led to the creation of the Cognition Engine. And Experience Journey Maps provides end-to-end visibility into the customer journey as they navigate through an app.

Strategic acquisitions are the not-so-secret game plan that have kept Cisco relevant as other tech pioneers have fallen by the wayside. And AppDynamics is a lynchpin, keeping the company in a strong position to remain top of the heap as network joins compute in the virtualized world of cloud.

“This is about Cisco setting the table,” said John Furrier, co-host of theCUBE, SiliconANGLE Media’s mobile livestreaming studio, during his opening day analysis of the 2020 Cisco Live EU event. “To me, the top story so far is that Cisco is not going to yield to the big cloud guys. They are, brick by brick, rebooting their products to be cloud-enabled for hybrid and then ultimately multicloud.”

The Core Tension in Digital Transformation

Digital transformation promises competitive advantage, but it routinely fails to deliver lasting value. The reason is a structural tension that every engineering organisation faces: systems must remain stable, secure, and predictable while development and operations teams are simultaneously expected to ship new features rapidly.

This pull between reliability and velocity shapes almost every architectural and tooling decision a team makes. Should you extend existing infrastructure to support new workloads, or redesign your delivery pipeline from scratch? The answer organisations are increasingly landing on is a cloud-native development strategy—and for good reason.

What Cloud-Native Actually Means

“Cloud-native” is used loosely, but at its most precise it describes an architectural approach with these defining characteristics:

• Microservices architecture: Applications are decomposed into small, independently deployable services, each owning a single business capability.
• Linux containers: Services are packaged and run in containers, making them portable across environments and easy to scale.
• API-first communication: Services interact through well-defined APIs, keeping them loosely coupled and replaceable without cascading changes.
• DevOps and CI/CD: Small, cross-functional teams own the full lifecycle of a service—from development through deployment and on-call operations—using continuous integration and continuous delivery pipelines.

When these elements work together, individual services can be built quickly, deployed automatically, and updated on independent release cadences. A change to the payment service no longer requires a full-application release freeze.

The Role of Modern Middleware

Traditional middleware—the software layer that connects applications, data sources, and users—was designed for monolithic, long-running server deployments. It does not translate cleanly to a containerised, ephemeral environment.

Modern middleware must be refactored to align with cloud-native assumptions: it needs to be lightweight, start quickly, expose APIs, and integrate naturally with container orchestration platforms such as Kubernetes. One example is Quarkus, a Kubernetes-native Java framework designed to reduce JVM startup time and memory footprint, making Java workloads viable in serverless and container-dense environments. Quarkus is positioned to bring existing Java skill sets into cloud-native delivery without requiring a complete rewrite in a new language.

Building a Modern Infrastructure Foundation

Container platforms do more than package code—they shift orchestration responsibility away from application servers and into the infrastructure layer. This separation means application teams can focus on business logic while the platform handles scheduling, scaling, self-healing, and service discovery.

Two infrastructure principles that have become standard practice in cloud-native environments:

• Fail-fast design: Container infrastructure makes it straightforward to spin replacement instances up and down, so rather than trying to prevent all failures, teams design systems that recover from them automatically and quickly.
• Chaos engineering: Popularised by Netflix, chaos engineering involves deliberately injecting failures into production systems to validate that resilience mechanisms actually work under real conditions—not just in theory.

Organisations with workloads still locked in legacy environments face a harder path. Those systems accumulate technical debt, are expensive to operate, and resist the automation that cloud-native delivery requires. Migrating or modernising those workloads—even incrementally—is a prerequisite for simplifying the broader IT environment.

Why CI/CD Is Central to the Cloud-Native Value Proposition

Continuous integration and continuous delivery are not optional extras in a cloud-native strategy—they are the mechanism by which microservices provide value. Without CI/CD, independently deployable services create operational complexity rather than reducing it.

Key benefits CI/CD brings to a cloud-native environment:

• Automated quality gates: Tests run at every stage of the pipeline, catching defects early before they compound.
• Fast feedback loops: Developers learn within minutes whether a change breaks existing behaviour, rather than discovering problems during a quarterly release cycle.
• Reduced deployment risk: Frequent, small deployments are statistically less risky than infrequent, large ones. Problems are easier to isolate and roll back.
• Continuous delivery of value: Business stakeholders see working features sooner, and can redirect priorities based on real usage rather than roadmap assumptions.

The Observability and Resilience Stack

A distributed microservices architecture is harder to reason about than a monolith. You trade a single failure point for many smaller ones, and debugging a latency issue that spans five services requires different tooling than reading a single application log.

Cloud-native operations depends on three pillars:

• Observability: Metrics, distributed tracing, and structured logs must be built into every service from the start—not bolted on after incidents reveal blind spots.
• Manageability: Services need health endpoints, graceful shutdown behaviour, and configuration externalised from code so that operators can manage them without redeployment.
• Resilience: Patterns such as circuit breakers, retries with back-off, and bulkheads prevent a failing downstream service from cascading failures through the entire application graph.

Culture and People: The Non-Technical Requirements

Technology alone does not deliver cloud-native outcomes. Organisations that invest in Kubernetes clusters and CI/CD pipelines while leaving team structures, incentives, and communication patterns unchanged typically see limited improvement.

A genuine DevOps culture requires:

• Shared ownership: Development teams take responsibility for the operational behaviour of their services, not just their source code.
• Psychological safety: Engineers need to be able to surface problems, propose experiments, and report failures without fear of blame. This is a prerequisite for the blameless post-mortems that drive real learning.
• Continuous skill development: Cloud-native technology evolves quickly. Organisations must invest in upskilling existing staff rather than assuming that hiring alone closes capability gaps.
• Cross-functional collaboration: Silos between development, security, and operations are the single biggest process bottleneck in most large organisations. Breaking them requires deliberate structural change, not just tooling.

A Practical Path Forward

Cloud-native transformation is rarely a single, big-bang migration. A more durable approach is incremental:

1. Assess your current portfolio. Identify which workloads are candidates for containerisation versus which need re-architecture versus which should simply be retired.
2. Establish a container platform. Kubernetes (or a managed distribution of it) is the de facto standard. Get the platform running and stable before migrating workloads at scale.
3. Build your CI/CD foundation. Automate build, test, and deployment pipelines for new services before tackling legacy migration.
4. Start with a bounded, low-risk service. Pick a service that is relatively self-contained and non-critical for your first cloud-native deployment. Use it to validate your platform and practices before scaling.
5. Invest in observability from day one. Instrument services with metrics and distributed tracing before you need them in an incident—not after.
6. Iterate on culture in parallel. Team structures, on-call processes, and engineering practices need to evolve alongside the technology.

The Long-Term Competitive Case

Cloud-native architecture is not primarily about cost reduction—though operational efficiency is a real benefit. The deeper value is the organisational ability to respond to market change faster than competitors whose monolithic systems require multi-month release cycles.

When application delivery is measured in hours rather than months, businesses can run more experiments, respond to user feedback quickly, and reduce the cost of being wrong. That compounding advantage is what makes cloud-native strategy genuinely future-proof—not any specific technology version or vendor platform.

The organisations that extract the most value from cloud-native technology are those that treat it as a continuous programme of technical and cultural improvement, rather than a project with a defined end date.

Microsoft Acknowledges Potential Azure Capacity Pressure

In March 2020, as the COVID-19 pandemic drove a rapid, unprecedented shift to remote work, Microsoft publicly acknowledged it could not rule out Azure capacity constraints resulting from surging cloud computing demand. The company moved quickly to establish a clear prioritization framework should those constraints materialize.

In an official blog post, Microsoft stated: “As demand continues to grow, if we are faced with any capacity constraints in any region during this time, we have established clear criteria for the priority of new cloud capacity. Top priority will be going to first responders, health and emergency management services, critical government infrastructure organizational use, and ensuring remote workers stay up and running with the core functionality of Teams.”

Capacity Priority Order

Microsoft’s stated prioritization hierarchy for Azure capacity, in the event of regional constraints, was:

1. First responders and emergency management services
2. Healthcare organizations
3. Critical government infrastructure
4. Core functionality of Microsoft Teams for remote workers

The company also noted it would consider adjusting its free service offers if necessary to protect existing paying customers — a significant caveat given that Microsoft had simultaneously begun offering Teams free for six months to businesses and educational institutions.

Teams Outage Underscores Scale of the Challenge

The announcement came shortly after Microsoft experienced a notable outage of its Teams collaboration platform the previous week, caused by a sudden surge in work-from-home deployments. The incident highlighted how even hyperscale cloud platforms can face operational stress when demand spikes within compressed timeframes — something traditional on-premises data center architectures would have struggled with far more severely.

Satya Nadella: Modern Cloud Architecture Built for Elasticity

Speaking to CNBC in late March 2020, Microsoft CEO Satya Nadella expressed confidence in the platform’s resilience. “I feel we’re definitely holding up,” he said, adding: “If this was a previous generation of data center architectures or software architectures, I don’t think we would have been able to deal with this crisis as effectively as we have been able to.”

Nadella emphasized that modern cloud infrastructure has elasticity built into it — the ability to dynamically scale compute, storage, and networking resources in response to demand — a property that traditional co-located or on-premises environments fundamentally lack at the speed required during a crisis.

Industry Perspective: The Electric Grid Analogy

Ric Opal, principal and national GTM and strategic partnerships leader at BDO Digital, offered a useful analogy for how cloud providers must manage sudden demand spikes: cloud infrastructure should be managed like electricity during a heat wave — with deliberate, transparent prioritization of who gets resources first.

“My expectation would be that Microsoft prioritizes commercial workloads — especially those that are relevant to assisting with the pandemic. Give health care the No. 1 priority, give the federal government and state government priority. The focus and effort has to be to slow the spread globally — use all of our resources and prioritize them in an orchestrated effort so that the world can benefit.”

— Ric Opal, BDO Digital

Opal noted that within his firm’s client base at the time, he had heard “zero complaints about people having issues with anything in Azure,” even as BDO Digital saw a 40 percent uptick in service requests. That demand included increased provisioning of Windows Virtual Desktop, VPN connectivity, and Microsoft Teams.

The Digital Transformation Dividend

The pandemic served as a stress test that exposed the gap between organizations that had invested in cloud infrastructure and those that had not. Opal was direct in his assessment:

“For any customer who’s feeling pain right now, they need to think about IT infrastructure no different than they think about water supply, electricity or natural gas. It cannot be under-invested in. Those who invested are reaping the benefits. Those who are not doing well were maybe the cloud laggards, or the ones who did some, but didn’t fully invest.”

— Ric Opal, BDO Digital

Organizations that had already moved workloads to SaaS and PaaS platforms — and adopted tools like Teams, Azure Virtual Desktop, and cloud-native VPN or zero-trust networking — were able to scale remote work operations quickly. Those still reliant on on-premises infrastructure faced bottlenecks in VPN capacity, hardware provisioning timelines, and remote access licensing.

Key Takeaways for DevOps and Infrastructure Teams

• Capacity planning must account for crisis scenarios. Even hyperscale providers can experience regional stress under sudden, broad demand shifts.
• Prioritization frameworks matter. Microsoft’s public commitment to triage capacity by use-case type provides a model for how SLAs and resource allocation policies should be communicated during incidents.
• Elasticity is a design goal, not a default. Applications must be architected to take advantage of cloud elasticity — auto-scaling, stateless services, and distributed data layers — to benefit when capacity is available.
• Cloud-native investments pay off during disruptions. The organizations best positioned during the pandemic were those that had already adopted PaaS and SaaS, reducing dependence on physical infrastructure.

Original reporting by CRN Australia, March 2020.

The Fundamental Misconception About Digital Transformation

Despite years of investment, many enterprises are still not seeing the business outcomes they expect from digital transformation programmes. The root cause is often a conceptual one: organisations treat digital transformation as a project with a start date, milestones, and a finish line, rather than as a permanent change in how they operate.

Digital transformation is not fundamentally about launching a new mobile app, migrating workloads to the cloud, or deploying a machine-learning pipeline — even though it can include all of those things. The point is to reach an ongoing state of IT agility that allows an enterprise to continuously adapt to shifting customer preferences and marketplace dynamics. Finite projects can contribute to that state, but no single project delivers it.

Why IT Agility Is a Precondition, Not the End Goal

Achieving IT agility does not by itself transform business outcomes. It is, however, a necessary precondition for creating the leverage needed to produce transformative outcomes. As agility improves, an enterprise gains the ability to:

• Increase operational efficiency by reusing and recombining existing capabilities.
• Evolve how it interacts with partners, suppliers, and customers.
• Experiment with and validate new revenue models faster.

This agility starts with IT architecture — not in the narrow sense of cloud versus on-premises, but in the broader sense of how easily a business can leverage, recompose, and share its proprietary digital capabilities for different purposes.

The Problem With Monolithic Architecture

Every enterprise has valuable digital assets: data, business logic, transaction capabilities, and domain knowledge encoded in software. These assets are only strategically useful if the company can do things with them quickly — securely sharing, reusing, and recombining them with minimal friction.

Traditional monolithic architectures work against this goal. In a monolith, functionality is tightly coupled inside a single application. This creates several compounding problems:

• Brittle updates: Changing one part of the application risks breaking unrelated parts.
• Locked-in functionality: A capability embedded in one application cannot easily be reused in another context without duplication or significant rework.
• Developer contention: Teams working on the same codebase block one another, reducing autonomy and overall velocity.
• Slow release cycles: End-to-end testing and deployment of a large monolith takes significantly longer than deploying a small, focused service.

The key to agility — and to the transformative business outcomes it enables — is to systematically decouple these dependencies.

What an Agile Architecture Actually Looks Like

Microservices

Digitally mature enterprises are moving away from monoliths and toward microservices: small, single-responsibility services that each own a discrete slice of business functionality. Multiple microservices are then composed together to create applications and digital experiences.

Because each microservice is independently deployable, development teams no longer block one another. Organisations can shift from large, slow, coordinated release trains to smaller, faster, more autonomous teams that build, release, learn, and iterate in parallel — compressing the innovation cycle considerably.

APIs

Application Programming Interfaces (APIs) are the connective tissue of a decoupled architecture. APIs abstract back-end complexity behind a stable, well-defined contract that front-end developers and external partners can consume without needing to understand the underlying implementation.

APIs serve several practical purposes in an agile architecture:

• They allow microservices to be shared safely across internal teams and with external partners.
• They can wrap legacy systems, connecting older applications to newer technologies without requiring a full rewrite.
• They enable ecosystem participation, allowing a company’s capabilities to appear inside third-party digital experiences where customers already spend time.

An enterprise is unlikely to decompose every monolithic application into microservices — it is unrealistic and often unnecessary. APIs bridge the gap, allowing older systems to participate in modern architectures incrementally.

Containers

Microservices are frequently packaged as containers, which decouple an application from the underlying hardware and operating system. This is an advance over traditional virtualisation, which decoupled from hardware but still coupled applications to a guest OS.

Containers deliver several agility benefits:

• Policy separation: Security and operational policies can be applied at the container-orchestration layer rather than embedded in application code, reducing duplication and inconsistency.
• Environment portability: Containerised services can move between on-premises infrastructure, private cloud, and public cloud environments with far less friction than VM-based workloads.
• Hardware agnosticism: Enterprises no longer need to provision dedicated servers per application, reducing infrastructure sprawl and cost.

The Indispensable Role of Management Tooling

A loosely-coupled architecture of containers, microservices, and APIs dramatically increases operational complexity. An enterprise running this architecture at scale may need to orchestrate thousands of services distributed across multiple environments simultaneously. Human operators cannot manage this manually at the required speed or reliability.

Management tooling is therefore not optional — it is a core architectural component. Effective tooling must address at least three concerns:

• Orchestration and observability: Automated service-to-service communication, health checking, and unified dashboards that provide a consistent view of API and microservice usage across all environments.
• Governed self-service: Developer-facing portals and catalogues that allow teams to discover and consume internal APIs and services without raising heavyweight approval tickets — while still enforcing access control, rate limiting, and usage auditing.
• Automated operations and security response: Alerting, circuit breaking, and automated remediation so that operations and security teams are notified quickly and, where possible, issues are resolved without manual intervention.

How IT Agility Translates Into Business Outcomes

IT agility is not an end in itself. The strategic value is the business capabilities it unlocks. One of the clearest illustrations is ecosystem participation.

APIs make it straightforward for a company not only to recombine its own capabilities into new digital experiences, but also to compose its capabilities with those of partners. Most applications that include mapping features, for example, do not build those features in-house — they consume third-party APIs (such as mapping or directions services) alongside their own APIs. The result is an experience assembled from multiple organisations’ services, delivered seamlessly to the end user.

This model fundamentally changes the economics of customer acquisition. Instead of bearing the full cost of building and maintaining the infrastructure required to attract customers directly, a business can use APIs to insert its core capabilities into digital contexts where customers already exist.

Real-World Examples of API-Driven Business Evolution

Several well-known enterprises illustrate how loosely-coupled, API-first architectures have enabled genuine business model evolution — not just technology modernisation:

• Ticket distribution (unnamed major U.S. company): A company that historically relied on phone sales, physical booths, and first-party apps — all channels that require the company to attract customers — restructured its core capabilities as APIs for event discovery and ticket purchasing. Those APIs were then embedded into social media platforms and other digital properties where potential buyers were already present, dramatically expanding reach without proportionally expanding acquisition cost.
• Pitney Bowes: Transitioned from selling physical postage meters to offering shipping and logistics APIs — such as address validation and carrier rate comparison — that partners embed directly into their own applications. The company’s intellectual property now flows through partners’ products rather than requiring customers to interact with Pitney Bowes-owned surfaces.
• AccuWeather: Monetised its proprietary weather data by exposing it through tiered API subscription models. This expanded both revenue and the developer ecosystem building products on top of its data, without requiring AccuWeather to build every downstream application itself.

In each case, the business model evolution was made possible not by a single project but by an architectural posture — decoupled, API-accessible capabilities — that allowed the company to keep adapting.

The Practical Takeaway for Engineering and Platform Teams

For DevOps engineers and platform teams, this framing has concrete implications for how work should be prioritised and measured:

• Portability matters more than placement. Whether a service runs on-premises or in the cloud is less important than whether it can be moved when circumstances change. Design for portability from the start.
• Reusability is a first-class requirement. Before shipping a new capability, ask whether it is exposed in a way that another team — or a partner — can consume without re-implementing it.
• Governance must be automated. Manual approval gates destroy the developer experience and slow the innovation cycle. Invest in API management and internal developer portals that enforce policy programmatically.
• Measure architectural agility, not just delivery throughput. Deployment frequency and lead time for changes (DORA metrics) are useful proxies, but also track how quickly a new team can consume an existing capability and how easily a service can be relocated to a new environment.

Conclusion

Digital transformation is most usefully understood not as a programme to be delivered but as a state to be maintained: perpetual architectural agility, governed well enough to remain controllable, and exposed through APIs broadly enough to enable ongoing business model evolution.

The enterprises seeing real transformative outcomes are not those that completed the biggest cloud migration or shipped the most apps. They are the ones that built — and continue to operate — architectures capable of continually adapting to whatever customers and markets demand next.

Most developers come from backgrounds in computer science, engineering, or mathematics. These disciplines train people to decompose complex problems, reason about systems, and iterate toward solutions—precisely the skills organizations need when navigating transformational change. Giving developers a meaningful voice in business decisions is not just good people management; it is a competitive advantage.

To unlock the full value of developer talent during a digital transformation, organizations should focus on four key areas.

1. Encourage Personal Development

A growing number of developers are actively investing in communication and leadership skills, recognizing that technical ability alone no longer defines a successful career. Soft skills are essential for building internal relationships, advocating for the engineering team’s work, and engaging empathetically with end users and customers.

Consider two common scenarios: a stakeholder who needs to understand how a product team operates, and a client who needs hands-on guidance when adopting a new solution. In the first case, a developer must be able to translate technical decisions into business language. In the second, they must apply empathy and patience—skills that go well beyond writing code.

Organizations that offer structured learning and development programs—covering new programming languages, emerging tooling, and interpersonal skills—are more likely to attract developers who are motivated to contribute across the business, not just within their immediate team.

2. Keep Things Agile

Working within an Agile framework provides developers with a built-in mechanism for developing soft skills through regular ceremonies such as sprint planning, retrospectives, and daily standups. Each meeting gives team members a structured opportunity to communicate blockers, offer solutions, and take ownership of outcomes.

This open, iterative approach stands in sharp contrast to the traditional Waterfall model, where siloed teams hand off deliverables with minimal communication and feedback arrives too late to be actionable. In Agile teams, shared responsibility is the norm: a developer may need to understand a UX decision, a tester may flag an architectural risk, and a business analyst translates all of this into stakeholder updates.

Agile also surfaces natural leaders. Developers with an inclination for leadership can demonstrate it organically through cross-functional collaboration, rather than waiting for a formal promotion. The relatively small size of most Agile teams means individual voices are heard and feedback loops are short—making learning on the job practical and continuous.

3. Be Clear on Requirements and Standards

Attracting strong developer talent is only part of the equation. Organizations must also be transparent about daily expectations—both technical and behavioral. Clear requirements reduce ambiguity, minimize rework, and allow developers to focus energy on work that genuinely moves the business forward.

On the technical side, efficient and well-tested code should be the goal. Workarounds and technical debt may resolve immediate problems, but they introduce systemic risk—particularly when defects surface in production or a client encounters unexpected behavior. Fewer bugs in a sprint naturally shifts scrum meeting focus from firefighting to strategy and innovation.

Organizations should establish documented coding standards, code review processes, and definition-of-done criteria to reduce the temptation of quick fixes and ensure releases are production-ready. Developers must also be comfortable working from design specifications and incorporating client feedback quickly—especially in teams operating continuous integration and continuous delivery (CI/CD) pipelines.

An interest in emerging technologies is valuable, but so is the pragmatic ability to leverage existing solutions rather than rebuild them from scratch. Reuse reduces cost and protects return on investment in established platforms.

4. Keep an Eye on the Future

An organization’s long-term competitive position increasingly depends on how quickly it can respond to technology advances. This means developers need the freedom—and the time—to explore new tools, experiment with emerging technologies, and bring innovation back into the product roadmap.

Technologies such as IoT and connected devices, AI and machine learning, augmented and virtual reality, blockchain, and 5G networks are already opening new business models and user experiences. Developers who build hands-on expertise in these areas become more than implementers—they become advisors who can identify viable use cases, flag risks early, and propose solutions that business stakeholders may not yet know are possible.

This creates a virtuous cycle: developers who grow their skills make themselves more valuable to employers, and employers who invest in that growth gain advocates who can connect technical decisions to strategic outcomes. In a digital transformation, that connection is everything.

Conclusion

Developers are not just executors of a digital transformation strategy—they are among its most capable architects. Organizations that create the conditions for developers to grow personally, work collaboratively, operate to clear standards, and stay ahead of technology trends will find that their engineering teams become a genuine driver of business change, not just a cost center delivering features.

This article is based on original reporting from devops.com.

DevOps Has Grown Up — Now What?

The phrase “DevOps 2020” is a milestone marker. The term — and the culture and practices it represents — has long shed its “new and shiny” status in IT. That doesn’t make DevOps passé; it means it has become pervasive. As organizations at every stage of the adoption curve continue to mature, understanding where the practice is heading matters as much as knowing where it started.

“In 2020, we will see organizations [continue to] embrace DevOps practices at all levels,” says Tom Iverson, Managing Principal, Cloud and DevOps at RBA.

By “levels,” Iverson is not referring to organizational hierarchies. He means that every team’s starting point with DevOps was different — including when they started. More advanced teams may be innovating and optimizing their continuous delivery pipelines, while organizations earlier in the adoption curve might still be experimenting with basic automation or working through the cultural changes that DevOps demands.

Regardless of where your organization sits on that spectrum, the following four trends are worth understanding.

Trend 1: DevOps Maturity Fuels Continued Interest in Cloud-Centric Tools

As DevOps practices mature, they naturally drive adoption of cloud-native technologies. The relationship is bidirectional: DevOps culture pushes teams toward better tooling, and better tooling reinforces the cultural and process improvements that DevOps demands.

One technology stands out as a clear example of this dynamic: Kubernetes.

“In 2020 we expect to see the continued and increased adoption of Kubernetes for organizations to deploy services. The combination of its ease of use, depth of features, and integration with major cloud platforms will make it an increasingly appealing choice for developing and deploying software — even more so if your organization already deploys containerized software.”

— Josh Komoroske, Senior DevOps Engineer, StackRox

Beyond container orchestration, cloud technologies more broadly are shifting how governance and self-service are handled inside IT organizations. Heavy, manual governance models are giving way to lighter, automation-driven custodial approaches.

“Cloud technologies will continue to grow and a ‘DevOps first’ mindset will be baked into new developments. Heavy-handed governance models will turn to more of a custodial approach due to the amount of automation available in the cloud space. For example, IT will look to provide self-service options to support rapid provisioning of temporary resources for proof-of-concept work.”

— Tom Iverson, Managing Principal, Cloud and DevOps, RBA

Iverson also noted that commodity tools — office suites, low-code platforms, and ChatOps solutions — would increasingly serve as the interface for that self-service experience, bringing DevOps-style capabilities directly to teams where they already work.

What This Means Practically

• If your team hasn’t yet invested in Kubernetes, the ecosystem maturity and managed Kubernetes offerings from major cloud providers lower the barrier significantly.
• Self-service infrastructure provisioning — backed by guardrails rather than gatekeeping — reduces bottlenecks and accelerates experimentation.
• ChatOps integrations (e.g., triggering deployments or querying system status from a Slack channel) bring operations closer to the teams that need visibility.

Trend 2: IT Leaders Are Revisiting DevOps Success Metrics

Measurement has always been central to DevOps. Metrics like mean time to deploy (MTTD), deployment frequency, and change failure rate gave teams concrete ways to demonstrate improvement. But as DevOps matures, organizations are questioning whether those operational metrics tell the full story.

“We’ve learned that faster is not always better when it comes to software release cycles. As a result, we’re seeing organizations pivoting away from release cadences and emphasizing business value and customer satisfaction.”

— Justin Donato, VP of IT, Nintex

This shift represents an intersection between DevOps and broader digital transformation goals. The original pitch for DevOps — “we’ll ship faster and more frequently” — was a means to an end, not the end itself. Organizations are now asking the harder follow-up question: does shipping faster actually benefit the business?

Donato points to accelerated sales cycles and time-to-revenue as examples of concrete, business-level outcomes that DevOps can and should be measured against.

“Businesses today aren’t looking so much for fast releases as for quality releases. Competitors can spring up overnight, so it’s key to deliver capabilities that keep your customers satisfied and loyal; you don’t want them looking elsewhere.”

— Justin Donato, VP of IT, Nintex

Rethinking Your Metrics Dashboard

If your DevOps scorecard is still primarily composed of pipeline throughput metrics, consider adding or elevating:

• Customer satisfaction scores (CSAT/NPS) — Do releases actually improve the user experience?
• Time to revenue — How quickly does a shipped feature generate measurable business return?
• Change failure rate combined with user-reported defects — Speed means little if quality suffers.
• Feature adoption rates — Are users engaging with what you’re shipping?

The goal is not to replace operational metrics but to connect them to outcomes your executive team and customers actually care about.

Key Takeaways

DevOps is no longer a movement — it’s a baseline expectation in modern software organizations. The trends highlighted here reflect a broader maturation: teams are moving from “are we doing DevOps?” to “are we doing DevOps well, and does it matter to the business?”

• Cloud-native tools, particularly Kubernetes, are consolidating their position as core DevOps infrastructure.
• Self-service and automation are replacing manual governance as the primary IT control model.
• Business-value metrics are increasingly important alongside traditional operational measurements.
• Quality and customer satisfaction are competing with — and sometimes overtaking — release velocity as primary success indicators.

Whether your team is just beginning its DevOps journey or refining a well-established practice, these themes provide a useful frame for evaluating priorities and investments.