Overview

In 2017, Capgemini published research indicating that enterprise adoption of cloud-native applications was poised for rapid growth. Conducted by Longitude Research on behalf of Capgemini, the study surveyed 902 senior professionals — evenly split between IT and non-IT roles — from 11 countries across Europe, the Americas, and Australia. Respondents came from banking, insurance, consumer products, retail, manufacturing, and high-tech sectors.

The headline finding: only 15% of new enterprise applications were cloud-native at the time of the study, but adoption was projected to more than double, reaching 32% by 2020.

What “Cloud-Native” Meant in This Context

The report defined cloud-native applications as software and services built specifically to perform optimally in the cloud, typically by leveraging Platform as a Service (PaaS) offerings. This contrasts with “lift-and-shift” approaches, where existing on-premises applications are migrated to cloud infrastructure without re-architecture.

Cloud-native applications are typically characterised by:

• Microservices architecture — functionality decomposed into independently deployable services
• Containerisation — packaging applications with their dependencies for consistent deployment
• Dynamic orchestration — using platforms such as Kubernetes to manage container lifecycles
• CI/CD pipelines — automating build, test, and deployment workflows
• Elastic scalability — scaling individual services horizontally based on demand

Why Organisations Were Moving to Cloud-Native

The study identified the primary business drivers behind the shift. Of the 900-plus respondents, the leading motivations were:

• 74% cited improved business agility
• 70% wanted to increase collaboration with external partners
• 67% aimed to deliver better customer experiences

Notably, cost reduction — traditionally the headline argument for cloud adoption — ranked lower than agility and customer experience improvements. This signals a maturation in how enterprises were framing the value of cloud investment by 2017.

Leaders vs. Laggards: The Performance Gap

The research segmented organisations into “leaders” — those with more than 20% of new enterprise applications developed cloud-natively — and slower adopters. The performance gap between the two groups was significant.

Cloud-native leaders were:

• Nearly twice as likely to report revenue increases attributable to cloud-native applications compared to laggards (84% vs. 44%)
• More likely to describe their software development approach as agile (69% vs. 37%)
• More likely to describe their deployments as automated (78% vs. 46%)
• More likely to report integrated DevOps teams (69% vs. 38%)

Leaders also held a different view of IT’s strategic purpose. Rather than primarily targeting cost reduction, they prioritised improving the customer experience (90%), business agility (87%), and scalability (85%), with cost reduction still valued but ranked lower (79%).

“We predict that cloud-native architectures will become the default option for customer-facing applications by 2020, driven by a need to continuously deploy innovations at an accelerated pace and enhance the customer experience. Businesses that delay adopting this approach will struggle to make up the gap with cloud-native competitors.”

Franck Greverie, Cloud and Cybersecurity Group Leader, Capgemini

Adoption Rates by Industry Sector

Cloud-native leadership was unevenly distributed across sectors. High-tech and manufacturing firms were ahead of regulated industries:

• High-tech firms: 26% were cloud-native leaders
• Manufacturing firms: 29% were cloud-native leaders
• Insurance providers: 18% were cloud-native leaders
• Consumer products, retail and distribution (CPRD): 22% were cloud-native leaders
• Banking providers: Only 11% qualified as cloud-native leaders

Despite lower current adoption, regulated sectors were accelerating. Banks were building 10% of new applications using cloud-native approaches. Nearly half of insurers (47%) and around a third of CPRD firms (27%) stated cloud-native formed a core part of their technology strategy. All three groups planned significantly increased PaaS spending over the following three years — banks and CPRD firms by 41%, insurers by 44%.

Barriers Holding Organisations Back

The report was candid about the obstacles CIOs faced, even in organisations that recognised the value of cloud-native approaches. Barriers fell into two categories:

Organisational Barriers

• 65% cited an ingrained culture resistant to cloud-native ways of working
• 70% reported a skills shortage when developing cloud-native applications
• Difficulty building internal business cases when leadership still measured IT success primarily through cost reduction

Technical Barriers

• 62% struggled to integrate cloud-native applications with legacy infrastructure
• 58% reported being locked into existing vendor contracts that constrained architectural choices

These barriers remain recognisable to DevOps practitioners today, suggesting the report captured structural challenges rather than temporary growing pains.

Six Recommendations for Becoming a Cloud-Native Leader

The Capgemini report offered a practical roadmap for CIOs seeking to close the gap with cloud-native leaders. The six recommendations were:

1. Assess the application portfolio — Identify which applications are candidates for cloud-native development and which should remain on legacy infrastructure for now.
2. Build credibility with a cloud roadmap — Demonstrate a clear, deliverable plan that connects cloud-native investment to business growth outcomes, not just technical metrics.
3. Start small, then scale — Begin with a contained project to develop team capability and organisational confidence before expanding the programme.
4. Adapt the IT operating model — Restructure teams and processes to support both business agility (speed of delivery) and stability (reliability and security).
5. Be pragmatic in technology selection — Avoid chasing the newest tools. Choose technologies that fit the organisation’s existing skills and integration requirements.
6. Incubate a culture of innovation — Actively build an environment that rewards experimentation, cross-team collaboration, and learning from failure — prerequisites for effective DevOps practice.

Why This Research Still Matters for DevOps Teams

Although the specific adoption percentages are now historical data points, several findings from the Capgemini study remain directly relevant to DevOps engineering work:

• The correlation between integrated DevOps teams and cloud-native success (69% of leaders vs. 38% of laggards) reinforces that tooling alone does not drive outcomes — team structure and culture are equally important.
• The skills gap identified in 2017 has deepened rather than narrowed in many organisations, making workforce development a persistent priority.
• Legacy integration complexity continues to be a primary technical constraint on cloud-native adoption, particularly in banking and regulated industries.
• The framing of IT’s role — shifting from cost centre to growth enabler — is a cultural change that DevOps advocates still actively navigate within enterprises.

Methodology

Longitude Research surveyed 902 professionals on behalf of Capgemini. Respondents were evenly divided between IT and non-IT roles and were based in 11 countries across Europe, the Americas, and Australia. Sectors represented included banking, insurance, consumer products, retail and distribution, manufacturing, and high-tech. The survey focused on views about cloud-native software development and organisational progress in adopting it.

Original source: Economic Times CIO, reporting on Capgemini research, 2017.

Why “Cloud Native” Is Hard to Pin Down

The software development industry has never been short of buzzwords, and for Java developers working in the cloud, few terms were repeated more frequently in 2017 than cloud native. Yet despite its ubiquity, arriving at a concise, universally accepted definition has proven surprisingly difficult. Ask ten experienced engineers and you are likely to get ten meaningfully different answers.

That ambiguity is not just a semantic inconvenience. When teams cannot agree on what cloud native means, they struggle to make coherent architectural decisions, evaluate tooling, or align development culture with operational practice. Understanding the overlapping definitions—and where they agree—is a prerequisite for building software that genuinely benefits from the cloud.

The Competing Definitions of Cloud Native

Several legitimate schools of thought shape how practitioners define cloud native computing:

• The container-first view: To the purist, cloud native simply means deploying a microservice into a managed, orchestrated container—think Docker containers scheduled by Kubernetes or a similar platform. If your workload runs in an ephemeral, independently deployable container, you are cloud native.
• The Twelve-Factor App view: Others argue that cloud native is primarily about application design. The Twelve-Factor App methodology defines a set of principles—stateless processes, environment-based configuration, declarative setup, and so on—that make applications portable across any cloud provider, from AWS to Google Cloud to Azure.
• The Agile view: A third camp insists that methodology matters as much as architecture. In this interpretation, an application is not truly cloud native unless the team building it follows an Agile process—iterating rapidly, delivering value in small increments, and incorporating feedback continuously.
• The DevOps culture view: Still others argue that cloud native development requires full assimilation into a DevOps culture: shared ownership of delivery pipelines, infrastructure as code, continuous integration and continuous delivery (CI/CD), and close collaboration between development and operations teams.

None of these definitions is wrong. The challenge is that each one captures a genuine and important dimension of cloud native practice while leaving the others partially in the shadows.

Microservices, Containers, and the Java Cloud

For Java developers specifically, the shift to cloud native has brought a distinct set of architectural and tooling changes. Monolithic Java EE applications that once ran on dedicated application servers are being decomposed into independently deployable microservices. Each microservice owns a single bounded context, exposes a well-defined API, and can be updated, scaled, or restarted without affecting its neighbors.

Containers—most commonly Docker images—have become the standard packaging format for these microservices. They provide consistent runtime environments from a developer’s laptop through to production, eliminating the classic “works on my machine” failure mode. Container orchestration platforms then handle scheduling, health checks, rolling updates, and service discovery at scale.

This combination—microservices as the architectural pattern and containers as the delivery mechanism—forms the technical core that most definitions of cloud native agree on. The disagreements tend to be about what surrounds that core: process, culture, and methodology.

A Unified Theory: Pulling the Threads Together

The most coherent articulations of cloud native computing do not choose one of the above definitions at the expense of the others—they synthesise them. A mature cloud native approach combines:

1. Architectural decomposition — breaking systems into independently deployable microservices with clear boundaries.
2. Container packaging and orchestration — using Docker (or equivalent) images and an orchestrator such as Kubernetes to manage lifecycle, scaling, and resilience.
3. Twelve-Factor design principles — ensuring applications are stateless, configuration-driven, and cloud-provider-agnostic wherever possible.
4. Agile delivery practices — short iteration cycles, continuous feedback, and incremental feature delivery that match the speed at which cloud infrastructure can be provisioned and changed.
5. DevOps culture and tooling — CI/CD pipelines, automated testing, infrastructure as code, shared on-call responsibility, and observability (logging, metrics, tracing) baked in from the start.
6. Developer autonomy — teams that own and operate their services end-to-end, reducing coordination overhead and enabling faster, safer deployments.

When these elements work together, the result is a system that can be updated frequently, scaled elastically, recovered automatically from failure, and understood by the teams responsible for it. That combination—not any single ingredient—is what makes an application genuinely cloud native.

Why Definitions Still Matter in Practice

It is tempting to dismiss the definitional debate as academic. In practice, however, the definition a team adopts shapes their investment priorities. A team that equates cloud native purely with containers may containerise a monolith and consider the job done—missing the architectural and cultural changes that deliver the real benefits. A team that focuses only on Agile ceremonies without modernising their deployment pipeline will iterate quickly but ship slowly.

A shared, multi-dimensional definition gives leadership and engineering teams a common vocabulary and a checklist against which to honestly assess their maturity. It also makes it easier to identify which gaps—architectural, tooling, or cultural—are the highest-priority investments for a given organisation.

Key Takeaways

• “Cloud native” is not a single thing—it is the intersection of microservices architecture, container packaging, Agile methodology, and DevOps culture.
• Java cloud developers need to engage with all four dimensions to realise the full benefits of cloud native computing.
• Containerising an existing monolith is a starting point, not a destination. Architectural decomposition and cultural change are equally important.
• Twelve-Factor App principles provide a practical, technology-agnostic design guide that complements container-based delivery.
• DevOps and Agile are not synonyms, but they are complementary: Agile governs how work is planned and iterated; DevOps governs how it is built, tested, and delivered.

The vocabulary around cloud native continues to evolve, but the underlying goal is consistent: building software systems that are resilient, deployable on demand, and aligned with the speed at which modern businesses need to change.