IBM has recently announced the beta availability of a new serverless compute service called IBM Cloud Code Engine. The service is a managed serverless platform that runs containerized workloads, for example web apps, micro-services, event-driven functions and batch jobs.

A follow up article describes the use cases and the open source technologies used to build Code Engine, including Knative, the Kubernetes-based platform to deploy and manage serverless workloads, the service mesh Istio, and Tekton, the framework for creating continuous integration and delivery (CI/CD) systems. Cong Nguyen, developer advocate at IBM, tweets:

IBM emphasises the open source layers and the portability of the platform, explaining that while it offers a simplified user experience, developers can still fully customize the Kubernetes data model or reuse existing deployment scripts on Code Engine.

Depending on the load, Code Engine automatically scales the containers, including scaling to zero when no requests are active. A container image is not a prerequisite to use the service: Code Engine can bundle the source-code from a Git repository with a supported runtime environment, what IBM calls a “buildpack”, and generate the container. A guide on how to do it is available in the IBM Cloud Design Engineer Gitbook.

The About IBM Cloud Code Engine covers the main concepts, names and terminology used on the platform. The first tutorial provided by IBM shows how to build a visual recognition platform, using Code Engine and the Cloud CLI.

Harald Uebele, developer advocate at IBM Germany, wrote a detailed article on in his personal blog on how to run containers serverless on Code Engine, highlighting the use cases where the new platform should excel:

While Christophe Boulangé, Cloud Director at BNP Paribas, labels it the “FaaS next-generation” other developers question the advantages against other existing offers: “What is the strongest part of this solution against AWS lambda, or Cloud Functions from GCP?”

The five projects below are among the most widely adopted in the Kubernetes ecosystem. They address key concerns for developers and operations teams alike.

1. Prometheus

Prometheus is an open source systems monitoring and alerting toolkit originally built at SoundCloud. It was the second project to join the Cloud Native Computing Foundation (CNCF), after Kubernetes itself, which reflects how central observability is to cloud-native operations.

Prometheus is built around a time-series data model. It can monitor individual host systems, but its real strength is in monitoring dynamic, service-oriented architectures — exactly the kind of distributed, microservices-based workloads that Kubernetes environments tend to run. Metrics are scraped from instrumented targets on a pull-based model, and a built-in query language (PromQL) lets operators explore and alert on that data in flexible ways.

Prometheus is frequently deployed alongside complementary projects in the observability space:

• Jaeger — distributed tracing for monitoring and troubleshooting microservices-based systems.
• Grafana — a popular dashboarding layer that visualizes Prometheus metrics.
• Istio — a service mesh that provides traffic management, policy enforcement, and telemetry aggregation across microservices.

The modular nature of the Kubernetes ecosystem makes it practical to combine or substitute these tools to meet specific workload requirements, without changing the core platform.

2. Operator Framework

Kubernetes provides flexible primitives for scheduling and lifecycle management, but these general-purpose abstractions do not cover the operational complexity of stateful applications. Standing up a database cluster, for example, often requires components to start in a specific order, managing configuration details, performing backups, and handling version upgrades — none of which Kubernetes handles natively.

Kubernetes Operators solve this problem by encoding the knowledge of an expert administrator directly into software. An Operator is a custom controller that extends the Kubernetes API to manage the full lifecycle of a specific application. A database Operator, for instance, can:

• Install a database cluster at a declared version and member count.
• Monitor the running cluster and detect failures.
• Perform automated backups and recovery.
• Manage rolling upgrades with application-specific logic.

This maps directly to the Site Reliability Engineering (SRE) principle of automating toil — tasks that are repetitive, manual, and automatable — so they no longer need human intervention each time they occur.

The Operator Framework is the open source toolkit for building and running Operators. OperatorHub.io provides a community catalog of ready-made Operators for many common applications, from databases like PostgreSQL and Cassandra to messaging systems and monitoring stacks.

3. Knative

Knative brings serverless capabilities to Kubernetes. At its simplest, it allows you to run serverless containers on a Kubernetes cluster without managing the underlying networking, autoscaling, or revision tracking yourself. Developers declare what they want to run; Knative handles the infrastructure concerns.

Knative is organized around two main components:

• Knative Serving — manages deployment, routing, and autoscaling of serverless workloads, including scaling to zero when there is no traffic.
• Knative Eventing — provides an event infrastructure for building event-driven applications, covering the event sources, channels, and subscriptions that most serverless architectures depend on.

A key advantage of Knative over managed serverless offerings from cloud providers is portability. Because Knative runs on Kubernetes, workloads are not tied to any single cloud provider’s proprietary serverless platform. Applications can use portable services deployed via Operators, making it easier to avoid vendor lock-in.

Knative also supports more complex serverless architectures than the original functions-as-a-service model. It accommodates microservices and container-based workloads that are triggered by events but are more stateful or longer-running than a simple Lambda-style function.

Why These Projects Matter

Each of these projects reflects the same underlying principle: Kubernetes deliberately keeps its core small and extensible, and the ecosystem fills the gaps through open source collaboration under the CNCF umbrella. This modular design lets teams assemble a platform that fits their specific workloads rather than accepting a one-size-fits-all solution.

For operations teams, Prometheus and the Operator Framework address the two most pressing operational concerns in a Kubernetes environment: knowing what is happening in production, and automating complex Day-2 operations. For developers, Knative lowers the overhead of building event-driven, scalable applications without requiring deep Kubernetes expertise.

Exploring these projects — and the broader CNCF landscape at cncf.io/projects — is a productive next step for any team looking to mature its Kubernetes platform beyond a basic cluster deployment.

This article is based on reporting originally published at enterprisersproject.com.

A Market in Motion: The Cloud Landscape Heading Into 2020

The cloud computing industry closed out 2019 with a flurry of consolidation and unlikely partnerships. IBM completed its acquisition of Red Hat. VMware reabsorbed Pivotal. Oracle and Microsoft announced high-speed interconnects between Oracle Cloud and Azure. VMware brought its Cloud Foundation to Google Cloud. Frenemies moved closer together, incumbents expanded their reach, and the conventional wisdom about who was winning the cloud wars was due for a serious update.

Analyst firm Forrester Research had predicted in 2018 that enterprises would begin modernizing core business applications with cloud in 2019 — and that transformation had clearly taken hold. As DevOps and platform engineering teams prepared their roadmaps for 2020, several key themes emerged from industry analysts.

Market Size: A $299 Billion Combined Cloud Market

Forecasts at the time projected the combined public cloud market — spanning SaaS (cloud applications), PaaS (development and data platforms), and IaaS (infrastructure services) — to reach approximately $299.4 billion in 2020. That figure represented continued strong growth even as the market began to mature and consolidate. Analysts also noted that the market was on a trajectory toward half a trillion dollars within a few years.

Enterprise adoption was already deep: around 65% of North American enterprises were reported to rely on public cloud platforms, while 66% ran internal private clouds — a sign that hybrid cloud was the dominant real-world architecture, not a transitional state.

Three Key Predictions for 2020

1. IBM and Oracle Retreat to Strengths; Alibaba Challenges Google

The hyperscale public cloud market was seen as firmly dominated by AWS, Microsoft Azure, Google Cloud, and Alibaba Cloud. The prediction was that IBM and Oracle would not exit that market but would strategically retreat to their core competencies rather than compete head-on with the hyperscale leaders.

• IBM was expected to focus on helping enterprises adopt Red Hat’s OpenShift container platform — positioning it as a cloud-agnostic modernization layer that could run on any hyperscaler.
• Oracle was expected to double down on its SaaS products and Autonomous Database, while directing customers toward Azure for general-purpose cloud services such as AI/ML, Kubernetes, IoT, and containers. Analysts also predicted Oracle would ink a high-speed connectivity deal with AWS or Google to serve its existing database customers.
• Alibaba Cloud was projected to generate approximately $4.5 billion in global cloud platform revenue, surpassing Google in global terms — but Google was expected to retain third place in North America due to Alibaba’s limited footprint in that region.

For DevOps teams, this meant an increasingly multi-cloud reality: enterprise workloads would span IBM/Red Hat tooling, Oracle databases, and hyperscaler compute — all requiring coherent CI/CD pipelines, identity federation, and observability strategies.

2. Cloud-Native Development Battles: Service Meshes and Serverless

By late 2019, Kubernetes had won the container orchestration wars. But winning the orchestration layer only opened new battlegrounds. Two areas were predicted to see fierce competition in 2020:

• Service meshes — offering interservice networking, traffic management, observability, and security for microservices architectures. Istio was identified as the leading contender, though no single solution had definitively won.
• Serverless computing — abstracting workloads entirely from infrastructure concerns and enabling event-driven programming models. Knative was seen as a strong open-source foundation for serverless on Kubernetes.

The expectation was that most enterprises would consume both technologies not as standalone open-source projects but as curated components within cloud-native development platforms offered by AWS, Microsoft, Google, VMware/Pivotal, or IBM/Red Hat. The hundreds of competing open-source projects and vendors in the CNCF ecosystem were expected to consolidate around platform distributions rather than survive as independent products.

For platform engineers and SREs, this was a clear signal: evaluate Istio and Knative not in isolation, but as part of the broader platform your organization is standardizing on.

3. Cloud Management Vendors Must Pivot to Security

The Capital One data breach — which exposed more than 100 million customer records from an AWS-hosted workload through a misconfigured web application firewall — put cloud security squarely in the spotlight in 2019. Predictions for 2020 centered on how the industry would respond:

• Hyperscale cloud providers (AWS, Azure, Google Cloud) were expected to accelerate investment in their native security tooling — such as posture management, secrets management, and runtime threat detection.
• Cross-cloud management vendors were expected to buy, build, or acquire security capabilities that went well beyond traditional identity and access management (IAM). The argument was that IAM alone is insufficient in a hybrid cloud environment where misconfiguration, lateral movement, and supply chain risk are primary attack vectors.
• VMware’s acquisition of Carbon Black in 2019 was cited as an early signal of this trend — embedding endpoint and workload security directly into virtualization, cloud management, and container platforms.

For security engineers and DevSecOps practitioners, this predicted shift translated into a clearer mandate: security tooling must be integrated into the platform layer, not bolted on after deployment. Cloud Security Posture Management (CSPM) and runtime protection were expected to become table stakes.

What This Meant for Engineering Teams

Taken together, these predictions pointed toward several practical priorities for DevOps and platform engineering teams entering 2020:

• Plan for multi-cloud by default. No single vendor was expected to dominate across all workload types. Portability through Kubernetes and OpenShift was increasingly the hedge organizations were making.
• Invest in service mesh literacy early. Service meshes introduce real operational complexity. Teams that began evaluating Istio in 2020 would have a head start on the skills needed to run it in production.
• Treat security as a platform concern, not a ticket. The Capital One breach demonstrated that misconfiguration — not just malicious attackers — is a leading cloud risk. Shifting security left and embedding it in platform tooling was becoming a requirement, not a best practice.
• Watch the Oracle-Azure alliance carefully. For teams running Oracle databases alongside Azure services, the high-speed interconnect between the two clouds had real implications for latency, data residency, and architecture decisions.

Source Attribution

The predictions summarized in this article were originally reported by Forbes based on Forrester Research analyst forecasts published in late 2019. Market figures (e.g., the $299.4 billion combined cloud market estimate and Alibaba’s $4.5 billion revenue projection) reflect Forrester’s estimates at the time of publication and should be interpreted as point-in-time forecasts, not verified outcomes.