This article is based on analysis originally published by Container Journal (January 2019), drawing on predictions from Siddhartha Agarwal, Vice President of Product Management and Cloud Strategy at Oracle Cloud Platform.
Cloud-Native Adoption Is Accelerating—and Forcing DevOps to Evolve
Enterprise IT is at an inflection point. According to Siddhartha Agarwal, Oracle’s VP of Product Management and Cloud Strategy, the rapid adoption of cloud-native technologies—Docker containers, Kubernetes, serverless frameworks, and managed infrastructure services—is not just changing how applications are built. It is fundamentally reshaping how IT organizations structure their teams, automate operations, and practice DevOps.
Agarwal’s core argument is straightforward: cloud-native architectures introduce a level of infrastructure complexity that traditional IT administration cannot manage at scale. That gap forces organizations to adopt proper DevOps practices across the entire IT estate, not just within isolated teams running a handful of modern applications.
Platform Engineers Are Replacing Traditional System Administrators
One of Agarwal’s most pointed predictions is a structural shift in IT hiring. As Kubernetes orchestration and container-based deployments become standard, organizations require engineers who can manage infrastructure at scale, design reliable platform abstractions, and automate operational workflows—skills that go well beyond the remit of a conventional system administrator.
This aligns with the broader industry move toward platform engineering as a discipline: dedicated teams that build and maintain internal developer platforms so that application teams can self-serve their infrastructure needs without deep operational expertise. The implication for DevOps is significant—operational responsibility shifts from individuals managing specific servers to teams managing platforms that themselves manage infrastructure.
Key Technologies Driving the Transition
Agarwal highlighted several technologies he expected to see broader enterprise uptake of:
- Docker containers and Kubernetes: Continuing to move from early-adopter use cases into mainstream enterprise workloads, including the containerization of legacy applications that were previously running on-premises.
- Kata Containers: A container runtime that provides hardware-level isolation by running each container inside a lightweight virtual machine. Kata addresses security and multi-tenancy concerns that arise when running containers from different workloads on shared infrastructure.
- Fn Project: An open-source, container-native serverless framework originally developed by Oracle. Agarwal cited frameworks like Fn as part of a broader move toward open-source, standards-based compute runtimes designed to prevent vendor lock-in.
- Managed services: Offloading the operational management of databases, middleware, and infrastructure to cloud providers or their partners—allowing internal teams to focus on application delivery rather than infrastructure maintenance.
Vendor Lock-In Concerns Are Accelerating Open-Source Adoption
A recurring theme in Agarwal’s analysis is the fear of proprietary lock-in. Enterprises are increasingly wary of building critical workloads on cloud services that use non-portable APIs or proprietary runtimes. This concern is actively driving preference for open-source container standards, open orchestration platforms, and cloud-agnostic toolchains.
For DevOps teams, this translates into a practical design requirement: build pipelines, infrastructure-as-code templates, and deployment workflows that are portable across providers. Kubernetes has become the de facto standard precisely because it abstracts away provider-specific infrastructure differences—though the degree of true portability remains a debated point in practice.
Legacy Application Containerization Is the Next Wave
A significant portion of the workload driving cloud-native adoption is not greenfield application development—it is the containerization of existing legacy applications. Organizations are lifting and shifting on-premises workloads into containers as part of broader data center exit strategies, with managed cloud services providing the database and middleware layer those applications depend on.
This matters for DevOps practitioners because containerizing a legacy application is rarely a simple repackaging exercise. It typically surfaces hidden dependencies, hardcoded configuration, and stateful behavior that must be addressed before a container-based deployment is reliable. Teams that have built solid CI/CD pipelines and infrastructure-as-code practices are significantly better positioned to execute these migrations.
Embedded Intelligence, Bots, and Blockchain
Agarwal extended his predictions beyond infrastructure, arguing that application architecture itself is changing. He predicted that the majority of custom-built applications would incorporate some form of embedded machine learning or AI capability, and that conversational interfaces—bots interacting with users rather than traditional graphical UIs—would see a sharp rise in adoption.
He also cited blockchain as an emerging platform for creating immutable transaction records. For DevOps teams, the operational implications of these technologies are non-trivial: ML model pipelines introduce new deployment and versioning requirements, bot infrastructure requires resilient messaging and API management layers, and blockchain nodes add complexity to network and storage provisioning.
The DevOps Forcing Function
Perhaps the most consequential observation in Agarwal’s analysis is that cloud-native technologies are acting as a forcing function for DevOps maturity. Historically, DevOps practices have been adopted unevenly—thriving in pockets of progressive teams while the broader IT organization continues to operate with traditional change management and manual operations processes.
Cloud-native architectures change that dynamic. When applications are distributed across containers orchestrated by Kubernetes, running on a mix of public cloud and on-premises infrastructure, the operational surface area is too large and too dynamic for manual processes to manage reliably. Automation is not optional—it is a prerequisite for keeping the system running. This creates organizational pressure to extend DevOps practices beyond individual teams and into the broader IT operating model.
What This Means for DevOps Teams Today
Agarwal’s predictions from early 2019 have proven directionally accurate. Platform engineering has emerged as a recognized discipline. Kubernetes adoption has expanded significantly into enterprise environments. Managed services consumption has grown. The practical takeaways for DevOps practitioners remain relevant:
- Invest in platform engineering skills. Understanding how to design and operate Kubernetes clusters, service meshes, and internal developer platforms is increasingly a core competency, not a specialization.
- Build for portability. Design pipelines and infrastructure configurations to be cloud-agnostic where possible, particularly if your organization operates across multiple providers.
- Plan for legacy containerization. Containerizing existing applications is a significant engineering effort. Treat it as a migration project with its own discovery, dependency mapping, and testing phases.
- Automate everything operational. At the scale that cloud-native environments operate, manual operational processes are a reliability risk. Invest in infrastructure-as-code, automated testing, and self-healing systems.
- Hire and develop platform engineers proactively. The skill gap between what cloud-native operations requires and what traditional system administration provides is real and growing.
The transition to cloud-native is no longer a question of whether it will happen—it is a question of how prepared your organization will be when it does.