Casa Systems partnered with Google Cloud to make it possible to integrate the company’s cloud-native 5G standalone core with a hyperscaler public cloud. The advantage of this type of integration, according to Casa, is that it makes it possible to deliver ultra-low latency applications even when the control plane and user plane are separated by hundreds of miles.

Casa said its engineers worked closely with engineers at Google Cloud’s ISV/SaaS Centre of Excellence to field test the solution. The field test demonstrated that it’s possible to separate the control plane and user plane of Casa’s cloud-based 5G SA core across hundreds of miles while still delivering a latency of just 10 milliseconds.

Casa said that during the field test it deployed its 5G SA core in multiple locations and placed the control and user plane functions at different locations. In this case, the control plane was located in Google Cloud’s North Virginia Region and the user plane was placed in Casa’s Andover, Massachusetts, facility.

Casa added that there are other advantages to using the hyperscale public cloud with a 5G SA core. For example, this type of integration will also make it possible for service providers and enterprises to provision services that are deployable anywhere —from the network edge to public clouds, private clouds, and carrier networks.

But Casa Systems isn’t the only company working with a hyperscaler to deliver a cloud-native 5G core. Nokia announced earlier this year that it had teamed with Google Cloud to jointly build cloud-native 5G core solutions for service providers and enterprises. And like Casa Systems, Nokia is also working with Google Cloud’s Anthos for Telecom solution, which is a platform Google built specifically for delivering workloads to the network edge on Google Cloud.

Cloud-native networking is gaining traction with telecom providers because it makes it possible for them to develop applications faster and scale them to a much larger number of subscribers than is possible with traditional applications. Cloud native applications also require less management and have lower operational costs.

Although some operators may move to 5G SA without the benefit of a cloud-native architecture, many experts view having a cloud-native network as being critical to 5G and without it, operators won’t be able to take full advantage of 5G standalone networks.

HCL Technologies (HCL), a leading global technology company, and Google Cloud today announced the expansion of their strategic partnership to bring HCL Software’s Digital Experience (DX) and Unica Marketing cloud-native platforms to Google Cloud. The announcement follows the success of the initial Google and HCL Software Commerce partnership announced in June 2020.

The Google Cloud offering provides customers a cost effective and highly scalable, secure and elastic cloud deployment option with global coverage that can support deployment of HCL’s DX, Unica and Commerce cloud-native platforms. DX’s cloud-native capabilities allow customers to deploy world-class, business-critical solutions significantly faster than before. Organizations with the most complex customer marketing data depend on HCL’s integrated cloud-native Unica marketing platform to support their precision marketing at scale. The HCL Commerce cloud-native platform delivers innovative and engaging customer experiences that go beyond the transaction.

“The collaboration between HCL Software and Google Cloud will deliver significant value for customers who want to deploy DX, Unica and Commerce from Google Cloud,” said Darren Oberst, Corporate Vice President and Head of HCL Software. “With the support of our global implementation business partners, we can quickly deliver comprehensive experiences to any audience, putting our clients in the best position to deploy and scale with Google’s Cloud and HCL’s cloud-native solutions.”

HCL DX is used by a wide range of organizations, including financial services firms, healthcare providers and government agencies, to provide a secure and personalized business-critical digital experience that is built cloud-native at scale across their multiple channels both internally and externally. Users of HCL DX on Google Cloud can take advantage of the all-new Digital Asset Manager (DAM) and developer toolkits to drastically improve productivity. When integrated with Google’s Data Cloud and proven artificial intelligence (AI) capabilities, DX solutions provide actionable insights to help organizations deliver more relevant customer experiences.

HCL Unica is used by many of the world’s most recognized financial services firms, healthcare providers, retail, telecom, and government agencies to provide secure and personalized business-critical multi-channel experiences. Point-and-click integrations from Unica Link and over 780 APIs simplify even the most challenging integrations, driving business results quickly when run on Google Cloud. The Unica product roadmap includes integration to many of Google’s market-leading tools.

“Businesses across industries, from healthcare to banking to retail, work with HCL DX and Unica to create stronger online experiences for their customers, employees, and partners,” said Avanish Sahai, Vice President, ISV and Application Partners at Google Cloud. “By bringing DX and Unica to Google Cloud, HCL Software can enrich these solutions with capabilities in AI, ML and analytics, and extend DX and Unica globally on our network. We’re excited to further expand our strategic partnership with HCL and look forward to supporting DX and Unica customers.”

This latest announcement from HCL and Google Cloud expands on a deep partnership between the two companies to help organizations digitally transform. There are now three HCL customer experience products employing Google Cloud as a preferred cloud platform. HCL Commerce has seen solid success through this collaboration since its partnership with Google Cloud was announced in June 2020. Since then, several HCL Commerce customers from around the world have migrated to Google Cloud. With the addition of DX and Unica, HCL Software’s financial services, healthcare and government customers and agencies have the option to move to Google Cloud. In 2019, HCL and Google Cloud announced the launch of HCL’s Google Cloud Business Unit to accelerate enterprise cloud adoption worldwide. To support customers, HCL has established three dedicated Google Cloud Native Labs in New York, London and the New Delhi area. These labs provide business-focused design workshops to engage customers and develop IP and MVPs on Google Cloud across industries effectively and efficiently.

“The HCL Google Cloud Ecosystem enables product collaboration across HCL Software and Google Cloud,” said Sanjay Singh, SVP & Global Head, HCL Google Ecosystem, HCL Technologies. “With the launch of HCL Digital Experience and Unica on Google Cloud, we continue to build on our portfolio of joint offerings to accelerate our customers’ digital transformation and drive a superior customer experience,”

Oracle Cloud’s newly launched VMware service takes an architectural approach that puts the channel front and center in selling, implementation and management, Ross Brown, vice president for go-to-market at Oracle Cloud Infrastructure, told CRN.

The market has been flooded with hyperscalers offering their versions of hosted VMware environments in recent years. But Oracle VMware Cloud Solution is unique in its ability to seamlessly operate alongside all types of workloads while empowering partners with full operational control, said Brown, a former VMware channel chief.

“In cloud, I have to serve all my IT: VMware workloads, VDI, cloud-native stuff. All those things have to work there, and those things are by definition partner integrated and delivered,” Brown said.

[Related: Oracle Cloud Preparing To Introduce Nvidia’s New A100s]

Oracle VMware Cloud Solution launched Thursday in all of Oracle’s global cloud regions, as well as through its on-premises cloud solution, Dedicated Region Cloud@Customer. The service, unveiled before last year’s Oracle OpenWorld conference, had previously been available only to beta customers through a limited release.

Oracle’s approach to delivering a native VMware service was grounded in the belief that hybrid and multi-cloud will become the norm for most enterprises, and the granular workings of hosted VMware environments should be entirely accessible and seamlessly interoperable with other workloads.

In recent years, VMware has forged alliances with the public cloud providers it once competed with, starting with Amazon Web Services and then moving on to Microsoft Azure and Google Cloud Platform.

Oracle didn’t want to emulate any of those plays, Brown said.

Instead, the Redwood Shores, Calif.-based tech giant focused on the question: “How do you build a more performant cloud that actually allows partners to engage on their workloads and go run them?” Brown said.

Microsoft Azure and Google Cloud offer dedicated hardware to run VMware that customers can connect to the rest of their cloud instances. And VMware Cloud on AWS also stands apart from the native AWS environment, Brown said.

“AWS doesn’t offer VMware. VMware offers VMware on AWS. You can build a connection back to your AWS tenancy, but it’s still separate,” he told CRN.

Oracle took a different tack, integrating the full VMware stack—vSphere, NSX network virtualization, vSAN storage virtualization, vRealize management—directly into the same bare-metal clusters that comprise the rest of the customer’s cloud tenancy.

The comprehensive integration of OCI with the VMware Cloud Foundation stack and VMware tools was an endeavor that Oracle product and engineering teams worked on for two years.

“VMware is a pretty detailed infrastructure environment,” Brown said. “It maximizes the hardware. It’s definitely not a lightweight tool, and it operates at a very thin layer.”

That approach, while technically challenging, delivers certain advantages—especially to the channel.

For starters, all VMware and third-party tools that partners currently use to manage on-premises VMware environments will work just the same in Oracle’s cloud.

“They operate identically because we’re running the same physical infrastructure, just as a cloud service,” Brown said.

With granular control over nearly all infrastructure operations, VMware partners can offer a complete catalog of managed services, just as they would if they stood up vSphere in their own data centers. Oracle allows them to create a VMware region and offer their customers shared tenancy, then use the complete set of MSP tools that VMware distributes through its VMware Cloud Provider Program.

“The notion of moving on-premises hardware into a cloud environment, still have everything work the same way, and have all management contracts go along with it, is pretty powerful,” Brown said.

Oracle also is the first cloud to allow customers to select a version of the ESX hypervisor, which is useful for those with apps certified for specific ESX releases.

“If I want to get under the hypervisor and do things with vCloud Director, we’re the only cloud that can do that,” he said.

Oracle’s partnership with VMware reflects its larger philosophy of cloud being an approach, not a place, Brown said.

But Oracle certainly hasn’t yet built a reputation as a VMware provider—the companies are better known for a longstanding rivalry predating their cloud transformations.

That’s another reason Oracle set out to build an offering that empowers the channel, Brown said, as it needs partners to be the trusted advisers that bring the service to enterprise customers.

“I‘m glad to see more native support from Oracle on their customers’ platforms of choice,” said David Klee, founder and chief architect at VMware partner Heraflux.

A native VMware platform on Oracle Cloud will further encourage the channel to migrate Oracle databases out of on-premises data centers and into the cloud, Klee told CRN.

“I‘m eager to see how this cloud platform continues to evolve and expand, and what other service offerings they will add in the future to complement this big shift in their model,” he said.

The product that appears to be stimulating the most customer interest for Oracle VMware Cloud Solution is Dedicated Region Cloud@Customer, Brown said. The on-premises infrastructure unveiled in June offers the same array of services, SLAs and pricing models as Oracle’s public cloud.

On-premises Exadata hardware running cloud-native apps built with Kubernetes and legacy ones built on VMware is a compelling offer to many large Oracle customers, Brown told CRN.

Oracle Executive Chairman and CTO Larry Ellison praised the solution last September in an OpenWorld keynote.

“We have a very important relationship with VMware,” Ellison said. ”The VMware stack you‘re running on-premises, you really can lift and shift it intact to the Oracle Cloud.”

What Red Hat Integration Is

Red Hat launched Red Hat Integration as a consolidated suite of integration and event-processing technologies designed for container-based environments. The suite targets organizations that need to create, extend, and deploy integration services across hybrid and multi-cloud infrastructures without being locked into a single platform or deployment model.

The solution is positioned as agile, distributed, and API-centric, giving development and operations teams a consistent way to connect applications and share data regardless of where those workloads run—on-premises, in a public cloud, or across multiple clouds simultaneously.

Why Enterprise Integration Has Had to Evolve

Enterprise IT integration is not a new problem, but the dominant architectural patterns have shifted dramatically over the past decade. Monolithic middleware platforms and point-to-point ESB (Enterprise Service Bus) topologies have given way to a landscape defined by three core primitives:

• Microservices – independent, loosely coupled services that can be developed, deployed, and scaled separately.
• APIs – the contracts that allow those services (and external systems) to communicate in a standardized way.
• Containers – the packaging model that makes microservices portable and environment-agnostic.

Kubernetes has become the de facto orchestration standard for managing containerized workloads at scale. As organizations migrate to or build on Kubernetes, their integration layer must follow—moving from centralized, server-based middleware to distributed, cloud-native integration patterns.

Key Capabilities of Red Hat Integration

Red Hat Integration bundles several upstream open-source projects and Red Hat-productized components into a single subscription. Core capabilities include:

• Apache Camel / Camel K – A lightweight, Kubernetes-native runtime for Camel integration routes. Camel K allows developers to run integration code directly on Kubernetes without writing boilerplate Deployment manifests.
• AMQ Streams (Apache Kafka on Kubernetes) – Red Hat’s productized distribution of the Strimzi project, which provides Kubernetes Operators for deploying and managing Apache Kafka clusters natively.
• AMQ Broker – An enterprise-grade messaging broker based on Apache ActiveMQ Artemis, supporting AMQP, MQTT, STOMP, and other protocols.
• 3scale API Management – Tools for publishing, securing, and analyzing APIs at scale.
• Debezium – An open-source change data capture (CDC) platform that streams database changes as events to downstream consumers.
• Service Registry – A schema and API artifact registry (based on Apicurio) that enforces data contracts between producers and consumers in event-driven systems.

Strimzi: Running Apache Kafka on Kubernetes

One of the most technically significant components highlighted in the launch is the Strimzi project, which underpins AMQ Streams. Strimzi provides a set of Kubernetes Operators that automate the deployment, configuration, and lifecycle management of Apache Kafka clusters on Kubernetes.

Running Kafka on Kubernetes introduces real operational complexity—stateful workloads, persistent storage, inter-broker networking, and rolling upgrades all require careful handling. Strimzi encodes that operational knowledge into Kubernetes Custom Resource Definitions (CRDs) and Operators, allowing teams to manage Kafka clusters declaratively using the same kubectl or GitOps workflows they use for the rest of their platform.

Red Hat is a contributor to the upstream Strimzi project, which is hosted under the Cloud Native Computing Foundation (CNCF) sandbox. AMQ Streams is the supported, enterprise-ready productization of that upstream work.

Integration as a Competitive Differentiator

Beyond the technology stack, the business driver is speed. The ability to rapidly respond to changing market conditions—shipping new features, incorporating user feedback, or connecting a newly acquired system—depends on how quickly integration work can be done. Tightly coupled, centralized integration layers become bottlenecks; distributed, API-driven integration patterns remove them.

Cloud-native integration aligns the integration layer with the same principles that govern modern application architecture:

• Decentralized ownership – individual product teams own and operate their integration routes, reducing dependency on a central middleware team.
• Event-driven architecture – systems react to events in near real-time rather than polling or relying on scheduled batch jobs.
• Self-service API exposure – API management tooling lets teams publish and consume APIs without going through a central gateway bottleneck.
• Observability built in – metrics, tracing, and logging can be emitted from integration components and scraped by the same tools (Prometheus, Jaeger, etc.) used across the rest of the Kubernetes platform.

Deployment Model

Red Hat Integration is designed to run on Red Hat OpenShift, Red Hat’s Kubernetes distribution, but many of the underlying components—Camel K, Strimzi, Debezium—are standard Kubernetes-compatible projects that can run on any conformant cluster. The full productized suite with enterprise support is available as part of a Red Hat subscription.

Organizations evaluating the suite should assess which components they actually need. A team that already runs Apache Kafka may only need Camel K for lightweight integration routing; a team starting from scratch may want the full stack including API management and a service registry for schema governance.

Summary

Red Hat Integration consolidates Apache Camel, Apache Kafka (via Strimzi), change data capture (via Debezium), API management, and schema registry capabilities into a single, Kubernetes-native integration platform. For DevOps and platform engineering teams building or migrating to cloud-native architectures, it represents a shift from centralized middleware toward distributed, operator-managed, event-driven integration—one that aligns more naturally with how modern containerized applications are built and operated.

Overview

Cybersecurity researchers at Intezer disclosed a Linux backdoor, dubbed Doki, that was completely undetected by major antivirus engines at the time of publication. The malware specifically targets Docker servers whose API endpoints are left publicly accessible — a misconfiguration common enough that attackers have built an ongoing automated campaign around it. Affected infrastructure includes cloud-hosted instances on AWS, Azure, and Alibaba Cloud.

What Is the Ngrok Mining Botnet Campaign?

The Doki malware is distributed as part of a broader campaign operated by the Ngrok mining botnet, which had already been active for approximately two years at the time of the Intezer disclosure. The campaign continuously scans the public internet for misconfigured Docker API endpoints. Once a vulnerable host is identified, attackers deploy malicious containers running cryptocurrency miners on the victim’s infrastructure — effectively stealing compute resources for profit.

What Makes Doki Unusual?

Doki stands out for several technical reasons beyond simply being a cryptominer dropper.

Blockchain-Based C2 Domain Generation

Rather than hardcoding command-and-control (C2) server addresses — which defenders can easily block — Doki uses a Domain Generation Algorithm (DGA) tied to the Dogecoin blockchain. It queries the Dogecoin block explorer in real time to derive the current C2 domain dynamically. Combined with the DynDNS service, this makes the C2 infrastructure extremely resilient: even if one domain is taken down, the algorithm generates a new one based on live blockchain data that only the attacker controls by spending Dogecoin.

Short-Lived Payload URLs

Doki crafts unique URLs with very short lifetimes to download payloads during an attack. This limits the window during which defenders or automated systems can retrieve and analyze the payload, complicating incident response and threat intelligence collection.

Cryptographic Network Communication

The malware uses the embedTLS library for encrypted network communication and cryptographic functions, helping it blend in with legitimate TLS traffic and resist inspection.

Evasion Track Record

According to Intezer’s findings, Doki was first uploaded to VirusTotal on January 14, 2020, and had been scanned multiple times since. Despite this, at the time of the July 2020 report it remained undetected by all 61 antivirus engines indexed on VirusTotal — a period of over six months of effective evasion.

Attack Chain: How Docker Hosts Are Compromised

The attack follows a clear progression once a misconfigured Docker API is found:

1. Discovery: The botnet scans the internet for Docker API endpoints that are publicly accessible without authentication.
2. Container deployment: Attackers use the exposed API to create a new malicious container, binding it to the host’s root filesystem (/) using Docker’s volume bind-mount feature.
3. Host escape: Because the container has access to the host’s root directory, the attacker can read and modify any file on the underlying machine — effectively escaping the container isolation boundary.
4. Persistence via cron: The attacker modifies the host machine’s cron configuration (accessible via the bind mount) to execute a downloaded payload every minute, ensuring persistence across container restarts.
5. Lateral scanning: Doki then uses network scanning tools — including zmap, zgrab, and jq — to scan for additional services on the network, specifically targeting ports associated with Redis, Docker, SSH, and HTTP, enabling further spread.

Why This Attack Is Particularly Dangerous

The combination of techniques makes this campaign more severe than a typical cryptojacking incident:

• Full host compromise: By binding containers to the host root, attackers gain capabilities far beyond what a contained environment should allow — including reading secrets, SSH keys, and modifying system binaries.
• Resilient C2: The blockchain-based DGA means that traditional domain blocklists and DNS sinkholes are ineffective against Doki.
• Multi-stage lateral movement: Active network scanning for Redis and SSH means a single compromised Docker host can become a pivot point into the broader internal network.
• Long undetected dwell time: Over six months of antivirus evasion means compromised systems may have been exfiltrating resources or data long before discovery.

Mitigation and Hardening Recommendations

The root cause of this attack is a misconfigured Docker daemon with its API exposed to the public internet. The following steps significantly reduce exposure:

1. Do Not Expose the Docker API to the Internet

By default, the Docker daemon listens on a Unix socket (/var/run/docker.sock), which is local-only. If you have configured Docker to listen on a TCP port (e.g., 2375 or 2376), restrict access using firewall rules so it is reachable only from known internal IP ranges or a VPN.

# Example: block public access to Docker API port with ufw
ufw deny 2375
ufw deny 2376

2. Use TLS Authentication for Remote API Access

If remote Docker API access is genuinely required, configure mutual TLS so that only clients with a valid certificate can connect. Docker’s documentation covers generating CA, server, and client certificates for this purpose.

3. Audit Bind Mounts

Avoid mounting the host root filesystem (/) or sensitive directories (e.g., /etc, /var/spool/cron) into containers. Review all docker run -v or Compose volumes: configurations for overly permissive mounts.

4. Implement Runtime Security Controls

Use runtime security tools (such as Falco, Sysdig, or similar) to detect anomalous behavior inside containers, such as cron modification, unexpected outbound connections, or cryptocurrency miner process signatures.

5. Validate API Parameters Carefully

If your application programmatically calls the Docker API to provision containers, rigorously validate all user-supplied parameters. An attacker who can influence API calls may be able to specify arbitrary bind mounts or privileged flags.

6. Apply Least-Privilege Principles

Run containers as non-root users where possible, use read-only root filesystems (--read-only), drop unnecessary Linux capabilities, and consider enabling user namespaces to limit the blast radius of a container escape.

Broader Context: Docker as a Recurring Attack Surface

The Doki disclosure was not an isolated event. In the same month (July 2020), separate malicious actors were reported targeting exposed Docker API endpoints to deploy images designed to conduct DDoS attacks and mine cryptocurrency. Exposed container APIs have been a consistent target for threat actors since at least 2018, making API access control one of the most critical security concerns for any team running Docker in a cloud environment.

Summary

The Doki malware represents a sophisticated evolution in cloud-targeting threats. Its use of a blockchain-based DGA for C2 resilience, combined with container escape via bind mounts and long antivirus evasion, makes it a serious risk for any organization with misconfigured Docker infrastructure. The defensive posture is straightforward: never expose the Docker daemon to the public internet, restrict access aggressively, audit container configurations for overly permissive mounts, and deploy runtime anomaly detection.

The Storage Problem in Container Environments

As organizations adopt containers for both development and production workloads, a fundamental challenge surfaces: containers are stateless by design. Any data written inside a container is lost when that container stops or is rescheduled to another node. For applications that need to persist data—databases, message queues, user-generated content—this is a serious operational problem.

Two broad approaches address persistent storage for Kubernetes clusters:

• External storage arrays with a Container Storage Interface (CSI) driver – the Kubernetes-standard way to connect traditional SAN or NAS arrays to a cluster.
• Container-native storage (CNS) – software-defined storage that runs inside the cluster itself, virtualizing local drives on each node into a shared, managed storage pool.

This article focuses on the second approach: what CNS is, how it works architecturally, and what distinguishes it from attaching an external array.

Quick Recap: Containers and Kubernetes

Before examining CNS, it helps to understand the environment it serves.

Containers vs. Virtual Machines

Containers are a lightweight compute virtualization technology. Multiple containers run on the same host, sharing the host operating system kernel rather than each carrying a full OS copy (as VMs do under a hypervisor). This shared-kernel model means:

• Container images are significantly smaller than VM images.
• Containers start and stop much faster than VMs.
• More workloads can be packed onto a given host.

Each container bundles its own libraries and dependencies, making it portable across hosts and cloud environments.

Kubernetes as the Orchestration Layer

Kubernetes (K8s) is the dominant open-source platform for orchestrating large numbers of containers. It schedules containers across cluster nodes, handles failure recovery, manages networking, and—via the Container Storage Interface (CSI)—connects external storage to running workloads. Most major infrastructure and storage vendors ship a CSI driver for their products.

What Is Container-Native Storage?

Container-native storage is a software-defined storage (SDS) layer that runs as containers on every node of a Kubernetes cluster. Rather than connecting to an external storage array, CNS virtualizes the raw drives or SSDs already present on each node and aggregates them into a single, cluster-wide storage pool. That pool is then exposed to application pods running in the same cluster.

The architecture is analogous to hyperconverged infrastructure (HCI) in the VM world: compute and storage are co-located on the same nodes, managed through a unified software layer, and scale out together by adding nodes.

Core Capabilities Typically Provided by CNS

• Persistent volumes – block and/or file storage that survives pod restarts and rescheduling.
• Replication – data is mirrored across nodes for fault tolerance.
• Snapshots and clones – point-in-time copies for backup, testing, and CI/CD pipelines.
• Data reduction – deduplication, compression, and thin provisioning to improve capacity efficiency.
• Quality of Service (QoS) – I/O prioritization between workloads.
• Encryption – data-at-rest encryption for compliance and security requirements.
• Multi-cloud portability – pods and their storage volumes can be migrated between on-premises clusters and public cloud environments.

CNS vs. External Storage Arrays with CSI

Neither approach is universally superior. Organizations with large existing SAN investments and separate storage teams may prefer the CSI route. Teams running cloud-native workloads that need hybrid/multicloud mobility often find CNS a better fit.

Notable CNS Products (as of 2020)

At the time of the original article, two prominent CNS products were available. The market has evolved since 2020; treat the details below as a starting point for further research rather than a current product comparison.

Red Hat OpenShift Container Storage (OCS)

Red Hat’s OpenShift Container Storage is tightly integrated with the OpenShift Container Platform and can be deployed on bare-metal servers or as VMware virtual machines. OCS is built on two open-source foundations:

• Ceph – Red Hat’s mature software-defined file, block, and object storage solution.
• NooBaa – an object storage operator that exposes S3-compatible APIs, supporting on-premises data as well as data stored in AWS, Google Cloud, or Azure.

OCS delivers file, block, and object storage with enterprise data services, all within a single-vendor Kubernetes stack. Its reliance on Ceph, a widely deployed open-source project, provides a degree of vendor-lock-in mitigation compared to proprietary alternatives.

Portworx Enterprise

Portworx Enterprise provides persistent block and file storage through a container orchestrator, with Kubernetes as the primary target, though it also supported Docker Swarm, Amazon ECS, and others at the time of writing. Beyond local node storage, Portworx could virtualize block storage from SAN arrays or connect to cloud storage volumes across AWS, Google Cloud Platform, Azure, PKS Cloud, and IBM Cloud.

Its feature set included:

• Snapshots and thin provisioning
• Stretched clustering across availability zones
• Disaster recovery and backup modules
• Security and encryption controls
• Data migration tooling
• Automated capacity management

Portworx was founded in 2015 and released its first product in 2016. Despite being a relatively young company at the time, it had built a substantial enterprise customer base by 2020. (Note: Pure Storage acquired Portworx in 2020.)

CNS and the Hyperconverged Analogy

The parallel between CNS for Kubernetes and hyperconverged infrastructure (HCI) for VMware environments is useful for understanding what CNS delivers operationally:

• Flexible scaling – add nodes to increase compute and storage simultaneously.
• Resource efficiency – no separate storage array hardware to provision or maintain.
• Simplified design – one infrastructure type to deploy, monitor, and support.
• Integrated management – storage is managed through Kubernetes-native interfaces (kubectl, Helm, operators) rather than separate storage management consoles.
• Software-defined operation – storage policies are expressed as code, fitting naturally into GitOps and Infrastructure-as-Code workflows.

Key Considerations Before Adopting CNS

CNS is a compelling architecture, but it is not without trade-offs to evaluate:

• Node storage requirements – each node must have local drives (NVMe SSDs are preferred for performance). Nodes with no local storage cannot contribute to the pool.
• Resource overhead – running storage software on the same nodes as application workloads consumes CPU and memory. Right-size node resources accordingly.
• Operational maturity – Kubernetes storage is a specialist area. Teams need to understand persistent volumes, storage classes, and volume lifecycle management.
• Data durability – replication across nodes is the primary data protection mechanism. Replication factor and node failure tolerance must be planned carefully.
• Vendor lock-in – CNS solutions vary in their use of open-source components vs. proprietary formats. Assess migration paths before committing.

Summary

Container-native storage addresses one of Kubernetes’s most significant operational gaps—persistent, managed storage—by embedding a software-defined storage layer directly into the cluster. By virtualizing local node drives into a shared pool, CNS eliminates dependency on external arrays for many workloads, enables hybrid and multicloud portability, and aligns storage management with Kubernetes-native tooling. As the ecosystem has matured since 2020, the range of available CNS solutions has grown; the architectural principles described here remain foundational to evaluating any of them.

How Kubernetes Changed Software Delivery

The widespread adoption of containers and Kubernetes has fundamentally altered how software is packaged, tested, and shipped. But the change has not been a simplification — at least not uniformly.

Greater Complexity Demands Rigorous CI/CD

Tracy Miranda (Continuous Delivery Foundation) emphasises that the move to distributed, cloud-native systems raises the stakes for teams that have not properly invested in CI/CD pipelines:

“In a distributed system, with multiple environments, if you haven’t set up CI/CD you can end up in big trouble if something goes wrong. Things you might have gotten away with before are quite difficult to get away with in a cloud native world. Combine that with the proliferation of new tools in the industry — tools that don’t necessarily interoperate well — and it is very difficult for users to know what is best.”

This complexity was a key driver behind the formation of the Continuous Delivery Foundation (CDF), which aims to foster collaboration, set standards, and help teams navigate an increasingly fragmented tooling landscape.

Containers as the Standard Packaging Format

Clark Boylan (OpenDev) makes a practical observation about how container adoption has changed user expectations and CI/CD workflows:

“Containers have become the expected packaging format for software. Potential users expect prebuilt container images that they can start and immediately begin evaluating your software. From a CI/CD perspective they present a convenient format to ensure the software you tested and is known to work is the same software you deploy into production.”

He also notes that Kubernetes encourages developers to think in terms of composable microservices — but that this shift introduces new testing and integration challenges on the CI side, particularly when multiple services must be tested together.

Microservices Acceleration and the CD Imperative

Priyanka Sharma (GitLab) frames the relationship between microservices and continuous delivery as inseparable:

“Developers can build faster with microservices. However, that is not useful if the code cannot be tested and rolled out quickly as well. So, the age of Kubernetes has ushered in the age of continuous delivery and deployment.”

Identical Deployments Eliminate Last-Minute Production Chaos

Joonas Lehtimäki and Nir Koren both highlight the consistency benefit of containers. Lehtimäki explains:

“If you think about how people deployed software before that, the actual process was slow, and it was hard to keep all systems identical. Containers tackled that issue by packaging all the necessary ingredients to a single package. That made every single deployment identical. Kubernetes then just made it easy to deploy on a bigger scale, solved networking issues, and so on.”

Koren adds a concise operational insight: because the container image is nearly identical between dev and production environments, teams experience far less unplanned chaos after production deployments.

Lehtimäki also cautions that Kubernetes is not the right solution for every workload. For a simple static web application, for example, a managed platform-as-a-service offering may be a better fit than running a full Kubernetes cluster.

Reproducibility Enables Small Teams to Operate at Scale

Christian Uhl highlights how the reproducibility of containers, combined with Kubernetes orchestration, democratises advanced deployment strategies:

“With these technologies, we can perform the same clever deployment strategies with one team of software engineers that needed whole departments of people before. This allows small players to play in the big league — so to speak.”

He also acknowledges a well-known tradeoff: the same abstraction layers that simplify operations can produce exceptionally hard-to-debug problems when things go wrong.

CI/CD Tool Recommendations from Practitioners

When asked which tools they recommend — including lesser-known options — the experts highlighted a mix of mature open-source projects and newer cloud-native entrants.

Jenkins X and Tekton: Cloud-Native CI/CD

Tracy Miranda recommends Jenkins X for teams building modern applications on Kubernetes. Despite sharing a name with the original Jenkins, Jenkins X is architecturally distinct: it is purpose-built for Kubernetes-native workflows.

• Pipeline automation out of the box
• Built-in GitOps for declarative, auditable deployments
• Preview environments so teams can review changes before merging
• Built on Tekton, an open-source cloud-native pipeline engine under the CDF umbrella

Tekton itself is noteworthy as a foundational building block: several other CI/CD tools are built on top of it, and it is worth tracking for teams evaluating the cloud-native CI/CD ecosystem.

GitLab CI/CD

Priyanka Sharma recommends GitLab CI/CD — unsurprisingly, given her role at GitLab, but it remains a widely adopted, fully integrated option for teams that want source control and pipelines under one roof. She also anticipates increasing standardisation coming from the Continuous Delivery Foundation.

Spinnaker for Continuous Delivery

Baruch Sadogursky (JFrog) recommends Spinnaker specifically for continuous delivery and deployment use cases, noting that despite being a mature project it continues to improve. He also flags CircleCI as a tool that has embraced cloud-native conventions — building in the cloud, using containers, and relying on configuration-as-code.

Zuul: Project Gating at Scale

Clark Boylan highlights Zuul as a purpose-built CI/CD tool with a specific strength: project gating — the ability to test complex combinations of changes across multiple repositories before any single change merges.

“As microservices become more prevalent you need to be able to test the combination of many different pieces of software all working in concert. Zuul is able to test these change combinations and does so before a single change merges.”

Zuul is self-hosting (it tests itself), and is used in production by organisations ranging from the OpenStack project to BMW and Volvo — demonstrating that its applicability extends well beyond pure open-source software development.

Key Takeaways for DevOps Engineers

• CI/CD is non-negotiable in cloud-native environments. The distributed nature of Kubernetes-based systems amplifies the risk of skipping or under-investing in automated pipelines.
• Container image parity between dev and prod is one of the most impactful operational improvements teams report after adopting containers.
• Kubernetes is powerful but not universal. Evaluate whether your workload actually benefits from Kubernetes overhead before committing to it.
• The CDF ecosystem is maturing. Projects like Tekton, Jenkins X, and Spinnaker are converging around shared standards — worth tracking for long-term tool selection decisions.
• Multi-repo integration testing is an underappreciated CI challenge in microservices architectures. Tools like Zuul are designed specifically to address it.
• Smaller teams can now run advanced deployment strategies (blue/green, canary, rolling updates) that previously required dedicated operations departments.

This roundtable was originally conducted by JAXenter in early 2020. Tool versions, project statuses, and organisational affiliations may have changed since publication.

It might seem odd to give advice on cloud adoption at this point in the hype cycle. After all, much of the industry considers public cloud a settled area with established practices and success stories. Surely there’s more than enough advice to help newcomers plan and execute their cloud transition?

Despite all the available information, I still see organizations struggling along the way on their cloud journey. Many well-intentioned cloud migration programs sputter and stall in their attempt to turn the promise of on-demand elastic compute into concrete, measurable benefits to their business.

Sure, we have shelves of literature describing how to architect cloud systems “well” and how to securely engineer complex compute environments and network topologies. But there’s still very little information on how to structure your organization, to employ operating models that embrace the potential of extreme virtualization. Finally, I see businesses busily ignoring the lessons of the past and creating fleets of assets that will be, at best, costly to maintain and at worst, unmaintainable.

In their haste to move to the cloud, organizations are accruing technical debt faster than they can pay it down. They’re creating one-off, hard-to-replicate environments and failing to implement even the most basic quality checks on those assets. In the long run, these assets will consume far more in maintenance costs than will ever be saved in moving from an on-premise data center to a public cloud provider.

In this article I’ll try to point out some of the common pitfalls I’ve seen companies make in their move to the cloud and then humbly offer an alternative.

Why is cloud success so elusive?

I’ve seen this pattern play out a number of times over the course of my career. A new technology comes along, it promises to be the future. Industry analysts draw quadrants and select winners and businesses assume that by going with a winner, they can avoid the hard work of learning a new discipline. They assume that by selecting the right IT outsourcing partner and managing the costs closely, the business benefits will naturally accrue. This has never been the case.

Businesses that succeed with new technology do so by adapting their organization, their operating model, and their engineering capabilities to the new paradigm. In many cases they also need to adapt their business model as well.

In the case of cloud, one way this fallacy manifests is in the belief that cloud is simply an alternate form of infrastructure. Cloud becomes the responsibility of the infrastructure or operations division who previously managed data centers and physical networks.

But cloud isn’t just a virtual form of hardware infrastructure. Rather, it’s 100% software.

The same businesses that hand over cloud implementation to an infrastructure or operations team would never dream of handing that same team a major, multi-year software development project. But that’s what cloud implementation is: a major, multidisciplinary, software delivery effort.

Another common pitfall that businesses encounter in their rush to move to the cloud — and which constrains their long-term success — is to become deeply and inextricably entangled with a single cloud vendor.

The three major vendors have achieved relative parity across a fundamental set of services and are competing fiercely to capture a larger portion of the market. Their pricing, the services they offer, and their business practices all encourage cloud customers to consume ever more services and to take greater advantage of the vendor’s unique, differentiating features. These proprietary features are inherently difficult to port from one vendor to another. And single-vendor entanglement also carries risk — primarily by moving control over IT decision-making away from the business and into the hands of the vendor.

The four dimensions of successful cloud adoption

I’ve noticed that the most successful cloud adoption strategies go beyond replatforming and instead incorporate a 360-degree approach to change. You might be lucky enough to lower costs by considering infrastructure alone but to see an impact on top-line revenue, market share, or innovation, your response must be broader. Shifting from on-premise infrastructure to cloud hosting is only the first step. Maximizing the business benefit from a move to cloud requires attention to the following four dimensions:

Technical excellence

Cloud is software and effectively leveraging cloud requires an investment in software engineering capability. Cloud-native engineering is more than simply leveraging a vendor’s services, it requires rethinking some common assumptions about resilience and application design. Infrastructure code demands the same attention to quality as you would apply to customer-facing systems. Successful software delivery efforts should deliver business value early and often. Cloud implementation is no different.

Autonomy with alignment

Moving from a world of physical resources — maintained by specialists and housed in a remote colocation facility — to software-defined network, compute, storage and support is a significant organizational disruption. Delivery teams are now responsible for defining and maintaining their own hosting environments. Security, compliance, strategic alignment, and support responsibilities all shift to the left.

Self-service platforms

Cloud vendors — through their APIs and broad education efforts — have democratized access to hosting environments. This ease of access must be passed along to corporate developers if corporations are expecting to see the step change in productivity that cloud affords. Internal, self-service cloud platforms should be optimized to roll out customer-centric digital products at an accelerating pace.

Vendor choice

Every business needs a multi-cloud strategy. That strategy might be to accept the risk of single-vendor dependency in exchange for developer productivity and favourable pricing. But this must be a deliberate choice rather than a series of unconscious actions. It also pays to be aware of the unique services each vendor offers so that you can choose from a palette of options, rather than being tied to a single vendor for all your needs.

Why Azure’s Computing Power Is Accessible Right Now

Organisations can start realising significant business benefits from Microsoft Azure without waiting until they have fully migrated their data to the cloud. Azure offers a range of high-performance computing capabilities that are simply not cost-viable to replicate in a traditional on-premises environment — chief among them being enterprise-scale artificial intelligence.

A clear example is Azure Databricks, an Apache Spark-based analytics platform capable of running complex machine learning workloads at speeds that would be cost-prohibitive using on-premises infrastructure. Services like this can be provisioned on demand and shut down when no longer needed, meaning organisations pay only for what they consume — eliminating the cost of idle servers.

The Cost Trade-Off: Cloud Compute vs. Data Transfer

It is worth noting that while you do not need to have the bulk of your organisational data permanently in the cloud to begin using Azure’s compute services, there are real costs associated with repeatedly transferring large datasets — potentially terabytes at a time — into Azure for processing. If high-performance computation is to become a regular workload, it makes economic sense to evaluate permanently migrating corporate data to the cloud rather than repeatedly incurring egress and ingress transfer costs.

Driving Innovation with Pre-Built Azure Services

Decision-makers today have a spectrum of options when it comes to building innovative solutions. They can develop capabilities entirely from scratch, or they can accelerate delivery by leveraging Azure’s growing library of pre-built services. Azure Cognitive Services is a particularly compelling example: it exposes pre-trained machine learning models for tasks such as:

• Facial recognition
• Text sentiment analysis
• Speech-to-text transcription
• Image classification and object detection

The significance here is accessibility. A developer with no background in deep neural networks can integrate a production-grade facial recognition capability into a standard business application by consuming an Azure Cognitive Services API. Organisations do not need to recruit large teams of AI researchers or data scientists to begin delivering value — they can build on models that Microsoft has already trained and validated.

A Real-World Example: Automating Insurance Call Centre Workflows

A practical illustration of this approach comes from the insurance sector. An insurance client needed a way to automatically prioritise call centre emails from customers whose tone indicated frustration or urgency. Altron Karabina worked with the client and Microsoft to deploy a solution using Azure Cognitive Services combined with Robotic Process Automation (RPA). The workflow operates as follows:

1. Incoming emails are analysed automatically as they arrive.
2. The sentiment analysis model estimates the probability that the customer is highly dissatisfied, based on the language and tone of the email content.
3. High-priority emails are flagged and routed accordingly, allowing agents to respond to the most urgent cases first.

The same client also needed to classify insurance claims that included photographic attachments. Using Azure Cognitive Services Image Recognition, the system could identify images of damaged vehicles attached to claims and automatically route those claims through the appropriate vehicle claims workflow — reducing manual triage effort significantly.

Starting Small: Experimentation Without Full Migration

Organisations that are not yet ready to commit to a full cloud migration can still begin experimenting with Azure’s high-performance capabilities at a modest scale. Azure Databricks, for example, can be used at an individual or team level to explore data analysis tasks — the platform scales from small exploratory workloads right through to complex enterprise pipelines.

This flexibility is one of cloud computing’s defining strengths: the same underlying infrastructure that handles a single developer’s exploratory analysis can scale to support an organisation’s most demanding production workloads. Starting small provides a low-risk way to build internal competency, validate use cases, and build the business case for broader cloud adoption.

Key Azure Services to Know

The Bottom Line for DevOps and Engineering Teams

The practical takeaway for engineering and DevOps teams is this: Azure lowers the barrier to delivering AI-powered features significantly. You no longer need to build and maintain custom ML infrastructure to integrate capabilities such as sentiment analysis or image recognition into your applications. Pre-built, API-accessible services reduce both time-to-delivery and the specialist skill requirements for your team.

The pay-per-use model also changes the economics of experimentation. Running a proof-of-concept on Azure Databricks costs a fraction of what provisioning equivalent on-premises compute hardware would require. Teams can validate ideas quickly, fail cheaply, and scale successful projects with confidence.

As AI workloads become an increasingly standard part of enterprise application development, the organisations that invest time now in understanding and experimenting with these services will be far better positioned to compete.

Kubernetes as Infrastructure: A Platform in Search of Developers

Over the last several years, Kubernetes has grown from a nascent open source project into a cornerstone of enterprise IT conversations. But look closely at those conversations and a pattern emerges: they are overwhelmingly focused on Kubernetes as an infrastructure platform.

Teams talk about network policies and load balancing, persistent storage and standards such as the Container Storage Interface (CSI), cluster provisioning and cloud provider integrations. These are legitimate and necessary topics—without solving them, Kubernetes cannot reliably run production workloads at scale. But solving infrastructure challenges alone does not make Kubernetes a compelling platform for the application developers who ultimately create business value on top of it.

Why the Application Layer Matters More Than the Infrastructure Layer

The business value of a platform like Kubernetes is not measured by how elegantly it is operated. Running Kubernetes is a means to an end—the end being applications that serve users and generate value. As responsibilities including testing, packaging, and security continue to shift left toward development teams, the pressure on Kubernetes to become genuinely developer-friendly grows correspondingly.

Kubernetes’ API-first design was an early strength. It attracted systems-oriented engineers who were comfortable reasoning about controllers, reconciliation loops, and declarative state. But the core primitives that underpin Kubernetes—ReplicaSet, Service, Ingress, PersistentVolumeClaim—remain relatively low-level compared to the abstractions offered by competing application platforms.

This low-level nature produces a real-world verbosity problem. Deploying even a modest application often requires authoring a Deployment manifest, a Service manifest, an Ingress manifest, possibly a CronJob, ConfigMaps, Secrets, and more—spread across multiple files, each with its own API version and schema considerations. For developers who simply want to ship software, this overhead is a genuine barrier.

Community-Led Efforts to Improve the Developer Experience

The cloud-native community has recognized the problem and is responding. Several coordinated efforts are underway to raise the abstraction level and reduce friction for developers working with Kubernetes.

CNCF SIG App Delivery

A Special Interest Group (SIG) dedicated to Application Delivery was established under the Cloud Native Computing Foundation (CNCF). SIG App Delivery focuses on the full lifecycle of cloud-native applications—developing, distributing, deploying, managing, and securing them. Its formation signals that the CNCF itself acknowledges the gap between Kubernetes as infrastructure and Kubernetes as an application platform.

The "Ruby on Rails Moment" for Kubernetes

At KubeCon + CloudNativeCon in San Diego, Bryan Liles—senior staff engineer at VMware at the time—used his keynote to call for Kubernetes to have its "Ruby on Rails moment." The analogy is instructive: Ruby on Rails transformed web development not by introducing new capabilities, but by applying the principle of convention over configuration. It made the right path the easy path. Liles argued Kubernetes needs an equivalent inflection point—one that lowers the cognitive cost of building and deploying applications without sacrificing power.

Tools Raising the Abstraction Level

Beyond community working groups and keynote aspirations, concrete tooling has emerged to address the developer experience gap. Below are several noteworthy examples.

Knative

Knative builds on top of Kubernetes and adds higher-level abstractions for common application patterns, particularly around serving and eventing. Its CLI tool, kn, illustrates the intended experience well: deploying an application can be reduced to specifying a name and a container image—a dramatic simplification compared to authoring raw Kubernetes manifests. Knative does require additional cluster-side components, which means it is best suited for environments where operators can manage that overhead centrally.

Kapp (part of the Carvel toolchain)

Kapp is a client-side tool that treats a collection of Kubernetes resources as a single, named application. It provides straightforward commands for deploying, listing, and deleting applications as coherent units, rather than managing individual resources in isolation. Crucially, Kapp requires no server-side components installed in the cluster, which lowers adoption friction and makes it easier to layer on top of existing environments. The underlying resources remain standard Kubernetes objects, preserving compatibility with the broader ecosystem.

Kapp is part of the broader Carvel toolchain (formerly known as k14s), a modular set of tools for templating, packaging, and deploying Kubernetes applications in a composable way.

Configuration Languages: ytt and CUE

Two tools tackling the verbosity of Kubernetes configuration from a different angle are ytt and CUE. Both aim to replace or augment raw YAML with more expressive, data-centric languages that allow templating and validation without sacrificing structure. Rather than bolting a general-purpose templating engine onto YAML (as Helm’s approach involves), they treat configuration as data that can be programmatically reasoned about—reducing duplication and improving correctness.

Other Notable Projects

• Rio (from Rancher): An application deployment engine for Kubernetes that provides higher-level abstractions for routing, scaling, and CI/CD integration.
• Open Application Model (OAM): A specification developed collaboratively—with Microsoft among the contributors—that separates application definition from operational concerns, allowing developers and operators to work from clearly delineated interfaces.

What a True Application Phase Would Look Like

For Kubernetes to fully enter its application phase, a few shifts need to take hold:

• Sensible defaults: Developers should not need to understand every infrastructure primitive to deploy a working application. Conventions should handle the common case, with escape hatches for advanced use.
• Application-centric tooling: CLI tools, dashboards, and APIs should speak the language of applications—deploy, scale, roll back, observe—not just of resources like Deployments and ReplicaSets.
• Reduced manifest verbosity: Configuration should express intent concisely. Higher-level languages and abstractions reduce the surface area for errors and the time spent on boilerplate.
• Developer-operator separation of concerns: Models like OAM explicitly delineate what developers control (application components and their traits) from what operators control (runtime environment and infrastructure). This boundary is essential for Kubernetes to serve both audiences well.

The Road Ahead

Progress on making Kubernetes a stronger application platform has been slower than some in the community anticipated—a sentiment that surfaced as far back as the earliest KubeCon Europe events. But the trajectory has shifted noticeably. The emergence of dedicated SIGs, widely discussed keynote themes, and a growing ecosystem of developer-focused tooling all point toward a maturing understanding of what Kubernetes needs to become.

The infrastructure foundations are solid. The next meaningful wave of Kubernetes adoption will be driven not by platform engineers tuning controllers, but by application developers who expect the platform to get out of their way. The tools and community energy to support that transition are increasingly in place.

Whether any single tool or standard delivers the definitive "Rails moment" for Kubernetes remains to be seen. But the direction of travel is clear, and the ecosystem is moving with real momentum.

Overview

WSO2 released version 3.1 of its open source API Manager platform in April 2020, targeting three broad themes: expanded support for modern deployment architectures (Kubernetes, microservices, and serverless), stronger API security, and an improved developer experience. The release ships under the Apache License 2.0 and is backed by the WSO2 Subscription service.

WSO2 API Manager is positioned as a full-lifecycle API management platform covering API creation, publishing, consumption, and monitoring. Version 3.1 ships alongside a matching release of WSO2 API Microgateway, its cloud-native, decentralized gateway component aimed at microservices deployments.

WSO2 API Microgateway 3.1

The Microgateway is a lightweight, developer-centric API gateway designed for decentralized deployments alongside microservices. It integrates with WSO2 API Manager for centralized management while running independently at the edge — in Kubernetes clusters, containerized environments, service meshes, and hybrid deployments. WSO2 states it can boot in under one second.

Key additions in version 3.1 include:

• gRPC support: The Microgateway can now expose managed gRPC endpoints, making it suitable for microservices and mobile backends that use the gRPC remote procedure call protocol.
• Runtime language choice: Developers can select either Java or Ballerina (WSO2’s open source networking-oriented language) as the runtime for the Microgateway.
• Improved observability: Enhanced message tracing capabilities give operators better visibility into traffic flowing through the gateway.
• Strengthened authentication: New options include API key-based authentication, combined authentication schemas, and support for multiple JWT issuers.

Extended Support for Kubernetes, Containers, and Serverless

Kubernetes API Operator

WSO2 introduced native Kubernetes support via a Kubernetes API Operator in 2019 — treating API management configuration as a first-class Kubernetes resource. Version 3.1 extends that operator with:

• Support for multiple Docker registries: Docker Hub, Amazon ECR, Google Container Registry, Quay.io, and generic HTTP/HTTPS registries.
• The ability to expose multiple Swagger/OpenAPI definitions as a single API.
• Automatic microgateway deployment from a Swagger definition — intended to reduce time-to-deployment for microservices to minutes.
• Deployment and management of KNative (serverless) applications.
• API management applied to microservices running inside an Istio service mesh.
• Java interceptors for mediation logic when exposing APIs.
• API exposure via a Kubernetes Ingress controller to provide a single ingress point for API traffic.

AWS Lambda Integration

WSO2 API Manager 3.1 adds native AWS Lambda integration, allowing developers to front Lambda functions with managed API endpoints. The integration supports two credential models for invoking Lambda functions:

• Stored AWS credentials configured in the API Manager.
• Temporary credentials supplied by an AWS IAM role.

This makes it straightforward to apply API management policies — rate limiting, security, analytics — to serverless backends without changing the Lambda function itself.

Expanded API Security

API Security Audit Integration with 42Crunch

WSO2 partnered with 42Crunch to develop an open source extension that integrates the 42Crunch API Security Audit tool directly into WSO2 API Manager. The integration scores an API’s OpenAPI/Swagger definition across three dimensions:

• OpenAPI format compliance
• Security posture
• Data validation coverage

The audit report identifies specific lines in the API definition where issues exist, explains how each vulnerability could be exploited, and links to remediation guidance. Developers can edit the API definition using the built-in Swagger Editor inside WSO2 API Manager and immediately re-run the audit to verify the fix.

Enhanced JWT Authentication

WSO2 API Manager has supported JSON Web Tokens (JWT) for OAuth 2.0-secured APIs since an earlier release. Version 3.1 adds three enhancements:

• Backend JWT separation: The backend JWT is decoupled from the client JWT, preventing user information from being forwarded to backend services without explicit consent.
• User claims in backend JWTs: Developers can embed user claims into the JWT passed to the backend service, enabling user-context-aware logic inside the API implementation.
• Multiple JWT issuers: The API gateway can now validate tokens issued by multiple identity providers, allowing organizations to bring their own JWTs from external systems.

These enhancements are particularly relevant for hybrid and distributed API gateway deployments, where reducing round-trips to a central token validation service improves both scalability and operational cost.

Improved Developer Experience

AI-Powered API Recommendations

The API Store (developer portal) in WSO2 API Manager 3.1 gains an AI-powered recommendation engine. Rather than relying solely on keyword search, the system analyses developer behaviour and the application under development to surface APIs that are likely to be relevant — reducing discovery time for developers exploring a large API catalogue.

API Categories

API providers can assign a category to each API from a predefined list managed by the portal administrator. The developer portal then groups APIs by category, providing an alternative to tag-based browsing. Providers no longer need to follow tag naming conventions — they simply select the appropriate category. If no suitable category exists, providers can request that the administrator create one.

API Mocking

Building on the existing API prototyping feature, API mocking in version 3.1 allows developers to define mock response payloads for each response code and content type directly in the API definition. The inline script for payload generation is generated automatically from example values or response schemas in the OpenAPI definition. This lets API testers interact with a realistic simulated API before the actual backend is ready — without requiring a subscription.

Availability and Licensing

WSO2 API Manager 3.1 and WSO2 API Microgateway 3.1 are available as open source software under the Apache License 2.0. Enterprise support is available through WSO2 Subscription, which includes:

• WSO2 Update — continuous delivery of bug fixes, security patches, and performance improvements.
• WSO2 Support — 24×7 technical support.
• Flexible hosting: cloud, on-premises, or hybrid, under unified pricing.

About WSO2

Founded in 2005 and headquartered in Mountain View, CA, WSO2 provides an open source, API-first integration platform. At the time of this release, the company employed over 600 staff across offices in Australia, Brazil, Germany, Sri Lanka, the UK, and the US, and reported that its integration technologies processed over 6 trillion transactions annually for enterprise customers worldwide.

Source: GlobeNewswire press release, April 7, 2020.

What Is the AWS Migration Acceleration Program for Windows?

Amazon Web Services (AWS) announced the general availability of its Migration Acceleration Program (MAP) for Windows in April 2020. First previewed at AWS re:Invent 2019, MAP for Windows is a structured program designed to help organizations plan, execute, and optimize large-scale migrations and modernizations of Windows workloads running on AWS.

The program bundles prescriptive guidance, expert consulting support, purpose-built tools, training resources, and AWS service credits into a single offering. Its stated goals are to reduce both the risk and the total cost of migrating Windows environments to the cloud, and to help customers lower licensing expenses by adopting cloud-native and open-source technologies where appropriate.

The Three Phases of MAP for Windows

MAP for Windows follows a three-phase framework that takes customers from initial assessment through to active migration and modernization:

1. Migration Readiness Assessment (MRA): An evaluation of the customer’s existing Windows environment, identifying readiness gaps, dependencies, and potential risks before any migration work begins.
2. Mobilization Phase: A remediation stage focused on closing the gaps uncovered during the assessment. This phase establishes the migration foundation—landing zones, governance frameworks, and operational runbooks—needed to migrate safely at scale.
3. Migrate/Modernize Phase: The active migration and, where applicable, modernization of Windows workloads. This phase is carried out with support from Amazon Partner Network (APN) members and the AWS Professional Services (ProServe) team.

Why AWS Launched MAP for Windows

The timing of MAP for Windows reflects a broader competitive dynamic in the enterprise cloud market. At re:Invent 2019, AWS CEO Andy Jassy publicly criticized Microsoft’s licensing practices, arguing that Microsoft was limiting how businesses can deploy Windows and SQL Server in the cloud using their existing on-premises licenses. Jassy’s comments were directed not at Azure specifically, but at Microsoft licensing policies that constrain customers’ cloud portability options.

MAP for Windows positions AWS as a destination for customers who want to escape restrictive licensing arrangements. By including service credits and guidance on adopting open-source alternatives, the program offers a financial incentive alongside the technical support.

AWS Windows Workload Market Position

In the blog post announcing general availability, AWS cited IDC research claiming that AWS hosts nearly twice as many Windows Server instances in the cloud as Microsoft Azure. This statistic was used to reinforce AWS’s argument that it is the de facto cloud for enterprise Windows workloads, not just for Linux or cloud-native applications.

Key Benefits at a Glance

• Prescriptive guidance: Documented migration patterns and best practices tailored to Windows Server and SQL Server workloads.
• Expert support: Access to AWS ProServe consultants and vetted APN partners with Windows migration competencies.
• Tooling: Integration with AWS migration tools such as AWS Application Migration Service (MGN) and AWS Database Migration Service (DMS).
• Training: Role-specific training resources for the teams executing the migration.
• Service credits: Financial incentives to offset migration costs and encourage adoption of AWS-native services.
• Licensing cost reduction: Pathways to reduce Windows and SQL Server licensing spend by moving to cloud-native or open-source equivalents where feasible.

Who Should Consider MAP for Windows?

MAP for Windows is aimed primarily at enterprise customers with significant Windows Server or SQL Server footprints on-premises who are planning a large-scale cloud migration. It is particularly relevant for organizations that:

• Are evaluating or already committed to AWS as their primary cloud provider.
• Want structured, low-risk migration methodology rather than ad-hoc lift-and-shift approaches.
• Are concerned about Microsoft licensing costs in the cloud and want to explore alternatives.
• Need access to vetted migration partners and professional services support.

Further Resources

For more information on MAP for Windows, visit the official AWS MAP for Windows page. Customers interested in enrolling should contact their AWS account team or an APN partner with the Windows migration competency.

Why Monolithic Testing Assumptions No Longer Hold

For most of the past two decades, the Continuous Integration/Continuous Delivery (CI/CD) pipeline was the canonical place to validate software changes. This worked well when applications were largely monolithic. The scope of change was bounded, the desired end-state was well-defined, and automated tests in the pipeline could verify it before anything reached users.

Microservices architectures break that assumption. When an application is composed of dozens or hundreds of independent services, the pipeline cannot build and test all of them simultaneously. At any given moment, some services are being rewritten, some are deploying, and others are already running in production—each at a different version. The concept of a single, stable “desired state” for the whole system becomes difficult to define, let alone test for.

This is not just a tooling problem. It is a fundamental shift in where change validation has to happen.

Production as the Only Place Where the Full System Exists

In a microservices environment, the production environment is often the only place where all services are running together in their current state. Pre-production environments are expensive to keep fully representative, and they typically lag behind the real thing. This makes production the most realistic—sometimes the only realistic—environment for certain classes of testing.

That does not mean shipping untested code and hoping for the best. It means combining several disciplines:

• Observability: Instrumenting services so that failures surface quickly and can be understood in context, not just detected.
• Progressive delivery: Techniques such as feature flags, canary deployments, and traffic shadowing limit blast radius when something goes wrong.
• Fast rollback: The ability to revert or re-route traffic quickly reduces the cost of a failure that does reach users.
• Small, frequent changes: Deploying smaller increments makes it easier to isolate the cause of a regression and reduces the risk of any single deployment.

With the right combination of these practices, production testing is not reckless—it is disciplined risk management applied to an environment that cannot be fully replicated elsewhere.

Observing State vs. Validating Change

Two complementary philosophies are converging here, and it helps to keep them distinct.

Observability: Understanding What Is Happening Now

Tools and vendors in the observability space—such as Honeycomb—argue that in sufficiently complex distributed systems, most failures result from the convergence of multiple simultaneous conditions rather than a single identifiable bug. Traditional monitoring, which checks for known failure modes, cannot catch these emergent problems. Observability tooling instead gives engineers the ability to ask arbitrary questions of their running system and understand its internal state from its external outputs.

This is observing state: understanding what the system is doing right now. It is powerful, but it does not by itself tell you whether a specific change you just deployed is safe.

CI/CD: Validating Change as It Moves Through the System

CI/CD pipelines are built to validate change: each commit triggers a sequence of builds, automated tests, and deployment steps that provide confidence before code reaches users. Rob Zuber, CTO of CircleCI, described this distinction in an eBook published in early 2020, arguing that the CI/CD tool is well-positioned at the center of the delivery stack precisely because it understands change—what changed, when, and what the test results were.

According to Zuber, CircleCI itself uses its own CI/CD platform alongside complementary tools for crash reporting, observability, and centralised logging. No single tool covers the full picture; the CI/CD system acts as the anchor that ties change context to the operational data coming from observability tools.

Putting Change and State Together

The mature position, reflected in both the observability camp and the CI/CD camp, is that neither approach alone is sufficient. Effective quality management for cloud-native applications requires:

1. Good coding and review practices to prevent avoidable defects from entering the pipeline at all.
2. Source control management that gives every change a clear audit trail.
3. Automated testing in CI/CD to catch regressions before deployment.
4. Progressive delivery mechanisms to limit exposure when untested interactions emerge in production.
5. Observability in production to detect and diagnose problems that only manifest under real traffic and real data.
6. Fast incident response and rollback to contain blast radius.

These are not competing approaches. They are layers of a single strategy, each addressing the risks the others cannot fully cover.

What This Means for DevOps Teams

If your organisation is moving toward microservices or cloud-native architectures, the testing strategy that served you well with monoliths will develop gaps. Some practical steps worth evaluating:

• Audit your pre-production environments. How representative are they of production? Where are the gaps, and what risks do those gaps create?
• Invest in distributed tracing and structured logging. These are the foundation of meaningful observability in a microservices environment.
• Adopt feature flags. Decoupling deployment from feature release gives you a fast, low-risk lever when something goes wrong in production.
• Make deployments smaller and more frequent. Counter-intuitively, deploying more often—in smaller increments—reduces the risk of each individual deployment and makes problems easier to isolate.
• Instrument your CI/CD pipeline to emit change context. When your observability tooling can correlate a spike in errors with a specific deployment, mean time to resolution drops significantly.

Conclusion

Testing in production is no longer a euphemism for negligence. For teams operating distributed, cloud-native systems, it is an acknowledgement that production is the only environment where the full system—with its real dependencies, real data volumes, and real user behaviour—can be observed. The goal is not to skip testing; it is to extend testing into the environment where the most important unknowns actually live, with the observability and delivery engineering discipline to do so safely.

Cloud-native development is transforming every part of the software delivery lifecycle. Testing is one of the most consequential areas of that transformation, and teams that adapt their quality strategy accordingly will be better positioned to move fast without accumulating unmanageable risk.

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.

What Is Rook?

Rook (think chess piece, not bird) is an open-source, cloud-native storage orchestrator that runs inside a Kubernetes cluster. Its core proposition is simple but powerful: take the same principles of containerisation and declarative orchestration that Kubernetes applies to compute workloads, and apply them to storage.

Rather than treating storage as an external dependency bolted onto a cluster, Rook provisions, manages, and heals storage resources from within the cluster itself. The result is software-defined, containerised storage that is portable, programmable, and tightly integrated with Kubernetes primitives such as PersistentVolumeClaims (PVCs) and StorageClasses.

At the time the original source was written, Rook had reached version 1.2 and had graduated to incubating-project status within the Cloud Native Computing Foundation (CNCF).

Why Containerise Storage?

The defining benefit of containerisation is abstraction: decoupling an application from the specific hardware it runs on. Kubernetes extends this by letting teams deploy, scale, and manage workloads dynamically across on-premises infrastructure and cloud environments.

Storage has historically lagged behind this model. Compute could be ephemeral and portable; storage remained tied to specific hardware, arrays, or cloud-provider APIs. Rook closes that gap by treating storage backends as Kubernetes-native resources, managed through the same declarative YAML manifests, operators, and automation pipelines already familiar to platform teams.

Supported Storage Backends

Rook acts as an orchestration layer over multiple storage providers. Its primary and most mature integration is with Ceph, the open-source software-defined storage project (maintained by Red Hat, which was acquired by IBM in 2019). Ceph supports block, file, and object storage, making it a versatile backend for a wide range of workloads.

Beyond Ceph, Rook (at the time of original publication) also supported or was developing support for:

• EdgeFS – A globally distributed file system built on object storage, with file, block, and S3-compatible access methods.
• NFS – Network File System server access for traditional file-sharing use cases.
• MinIO – An S3-compatible, high-performance object storage server.
• Apache Cassandra – NoSQL database managed as a data service.
• CockroachDB – Distributed, cloud-native SQL database.
• YugabyteDB – Distributed SQL database designed for cloud-native environments.

It is worth noting that Rook is not designed to front commercial storage arrays or cloud-provider storage services. Its value lies in the orchestration intelligence it provides — replacing the role of a proprietary storage controller with open-source, Kubernetes-native management.

How Rook Works Inside Kubernetes

Rook’s architecture centres on a Kubernetes Operator. The operator continuously monitors the state of storage resources within the cluster and reconciles actual state with the desired state declared by the administrator. Key automated tasks include:

• Scheduling and deployment of storage pods across cluster nodes.
• Bootstrapping and configuration of storage clusters (for example, a Ceph cluster).
• Scaling storage capacity as demand grows.
• Load balancing across storage nodes.
• Disaster recovery and healing — detecting and replacing failed or corrupted disks automatically.
• Lifecycle management — cloning, maintenance, and decommissioning of storage resources.

From a developer and platform-engineer perspective, Rook integrates with standard Kubernetes storage constructs. Storage is exposed via StorageClasses, and applications consume it through PersistentVolumeClaims — the same workflow used with any Kubernetes storage provider. Bootstrapping a Rook-managed Ceph cluster can begin with a small number of kubectl apply commands, after which the operator takes over ongoing management.

Deployment Models: Hyper-Converged and Hyper-Scale

Rook supports two primary architectural models:

• Hyper-converged – Storage and compute run on the same cluster nodes. This suits environments where you want to minimise infrastructure footprint and manage everything through a single Kubernetes cluster.
• Hyper-scale – Storage scales independently across many nodes, appropriate for large-scale workloads with significant or unpredictable storage demand.

Benefits of Using Rook

For teams already committed to containerisation and Kubernetes, Rook offers several concrete operational advantages:

• Programmable storage – Developers and platform engineers define storage requirements in code, enabling storage-as-code workflows.
• Horizontal and vertical scaling – Add capacity by adding nodes or disks; the operator handles redistribution.
• Automated volume provisioning – Pods receive persistent volumes quickly and automatically without manual storage administrator intervention.
• Self-healing – Failed disks are detected and replaced automatically, reducing operational toil.
• Portability – In principle, workloads and their storage can be moved between on-premises clusters and cloud environments, though storage-backend compatibility remains a practical constraint.
• Unified operational model – Teams use the same Kubernetes tooling (kubectl, Helm, GitOps pipelines) to manage both compute and storage.

Limitations and Considerations

Rook is a compelling approach, but there are genuine limitations to weigh before adopting it:

• Maturity and production readiness – At the time the original source was written, Rook had production users but remained in early stages. Some storage backends were more mature than others. Always check the current CNCF project status and backend-specific stability before deploying to production.
• Incomplete storage-type support – Not all storage backends were fully supported, and coverage of commercial arrays and cloud-provider storage was not a project goal.
• Operational complexity – Rook simplifies day-2 operations significantly, but initial setup — particularly for Ceph clusters — has a non-trivial learning curve. Teams unfamiliar with distributed storage systems should invest in training.
• Not a replacement for all storage use cases – Workloads requiring very high I/O performance, specific compliance guarantees, or deep integration with vendor hardware may still be better served by dedicated storage solutions.

Rook’s Position in the Cloud-Native Ecosystem

Rook’s inclusion as a CNCF incubating project reflects a broader industry recognition that storage must become a first-class citizen in cloud-native architectures, not an afterthought. Its operator model aligns closely with Kubernetes patterns that the industry has standardised on, making it easier to extend and maintain over time.

For organisations investing heavily in Kubernetes — whether on-premises, in the cloud, or in hybrid configurations — Rook represents a logical next step: completing the containerisation story by bringing storage under the same declarative, automated, and programmable management model applied to everything else in the stack.

Getting Started

The official Rook documentation at rook.io is the authoritative source for current installation instructions, supported backends, and version-specific guidance. The quickstart guides for Ceph are a practical starting point for most teams. As with any infrastructure component, test thoroughly in a non-production environment before rolling out to production workloads.

Original source summary: Computer Weekly. Published on bestdevops.com, March 2020.

Overview

Amdocs (NASDAQ: DOX), a leading provider of software and services to communications and media companies, announced in February 2020 that Bell Canada — Canada’s largest communications company — had successfully implemented RevenueONE, a core component of Amdocs’ cloud-native customer experience suite CES20, running on Amdocs Microservices360. The deployment builds on a long-standing managed services relationship between the two companies and marks a significant step in Bell’s ongoing digital transformation strategy.

What Was Implemented and Why

Bell’s implementation centered on two key Amdocs technologies:

• RevenueONE: A billing and revenue management building block within the CES20 suite, designed to simplify retail engagement and support complex product and pricing models for communications service providers (CSPs).
• Microservices360: Amdocs’ core microservices platform that, combined with DevOps and Site Reliability Engineering (SRE) practices, is intended to shorten the code-to-production cycle and accelerate time-to-market for new products and services.

The goal was to give Bell both the technical agility to adapt to rapidly changing business conditions and the operational tooling to continuously deliver improvements to its digital retail experience for customers.

DevOps and CI/CD at the Core

A defining aspect of this implementation is its emphasis on DevOps culture and continuous integration/continuous delivery (CI/CD) methodology. Communications service providers like Bell are increasingly expected to behave like software companies — shipping features rapidly, recovering from failures quickly, and scaling infrastructure on demand.

Microservices360 is designed to serve as the enabling engine for exactly this kind of transformation:

• Microservices architecture: Breaking monolithic BSS/OSS systems into independently deployable services reduces the blast radius of changes and allows teams to deploy components on their own release cadence.
• CI/CD pipelines: Automated build, test, and deployment workflows reduce manual handoffs and enable frequent, lower-risk releases.
• Site Reliability Engineering (SRE): Applying SRE principles helps balance the pace of feature delivery against system reliability — a critical concern for a national carrier like Bell.
• Cloud-native design: CES20’s open, modular component model means Bell can adopt new capabilities incrementally without requiring a full platform replacement.

Industry Context: CSPs Transforming to DevOps Organizations

Telecommunications companies have historically operated large, tightly coupled BSS (Business Support Systems) and OSS (Operations Support Systems) stacks that are difficult and slow to modify. As competition from digital-native players intensifies and customer expectations rise — particularly in the lead-up to 5G service rollouts — CSPs like Bell face pressure to modernize at speed.

Adopting a cloud-native, microservices-based architecture directly addresses several of the most common pain points:

• IT velocity: Independent services can be updated without taking down the entire platform.
• Business agility: New product configurations, pricing models, and customer journeys can be launched faster.
• Scalability: Cloud-native workloads can scale horizontally to handle peak demand without over-provisioning permanent infrastructure.
• Vendor flexibility: Open, modular designs reduce lock-in and allow best-of-breed integrations.

Quotes from Key Stakeholders

“As the pace of digital transformation continues to accelerate, it’s critical to adopt cloud-native, microservices-based technologies and DevOps best practices and tools. Together with Amdocs, we are rapidly developing and deploying new capabilities to support Bell’s customer service leadership in a new era of integrated digital communications.”

— Saad Saade, Vice President of IT Delivery, Customer Experience, Bell Canada

“The ability to use open, modular components to enrich existing IT capabilities is a fundamental design principle of CES20 aimed at improving business agility and ensuring focus on areas of greatest business opportunity.”

— Anthony Goonetilleke, Group President, Amdocs Media, Network & Technology

Key Takeaways for DevOps Engineers

This implementation illustrates several broader principles relevant to DevOps practitioners working in or adjacent to the telecommunications industry:

1. Modernization doesn’t require a big bang. Bell extended an existing managed services relationship incrementally, adopting cloud-native capabilities as modular additions rather than replacing everything at once.
2. Platform and practice go together. Microservices360 is presented not just as infrastructure but as a combined platform-plus-methodology that bundles DevOps and SRE practices alongside the tooling.
3. SRE is becoming standard in telecoms. The explicit mention of Site Reliability Engineering alongside DevOps signals that reliability engineering is now expected even in traditionally operations-heavy industries.
4. CI/CD is the mechanism, not the goal. The pipeline exists to serve a business outcome — faster product launches and a better customer retail experience — not as an end in itself.

About Amdocs

Amdocs is a software and services company focused on the communications and media sector. As of fiscal year 2019, the company reported revenue of $4.1 billion and employed approximately 25,000 people serving customers in over 85 countries. Amdocs is listed on the NASDAQ Global Select Market (ticker: DOX). More information is available at www.amdocs.com.

This article is based on a press release issued by Amdocs on February 4, 2020, distributed via GlobeNewswire. Financial figures and employee counts reflect conditions at the time of the original announcement.

Software Is Now Critical Infrastructure

From the smartphone in your pocket to the power grid serving an entire city, virtually every system people rely on daily runs on layers of complex software. That dependency is not shrinking—it is accelerating. As the volume of data generated globally continues to expand at an extraordinary rate, the pressure on software teams to ship reliable code quickly has never been higher.

This is precisely the environment that made DevOps indispensable. DevOps—the cultural and technical movement that breaks down silos between development and operations teams—was originally adopted as a competitive differentiator. It is now a survival requirement for any organization that builds or depends on software.

What Happens When Software Updates Go Wrong

The consequences of poor software delivery practices are not abstract. Several high-profile incidents illustrate how much is at stake:

• Power grid outages: A faulty software update contributed to widespread power outages affecting the San Francisco Bay Area when utility provider Pacific Gas and Electric (PG&E) pushed a problematic release.
• Aviation safety failures: The Boeing 737 Max crashes, linked in part to a software defect in flight-control sensor logic, resulted in the loss of more than 150 lives—demonstrating that software quality failures can have fatal consequences.
• Consumer device failures: A software patch released by Google rendered Google Home and Nest Hub devices inoperable for users across the world.

These examples share a common thread: insufficient testing, release management, or rollback capability at the point of deployment. A mature DevOps practice—with automated testing pipelines, staged rollouts, and rapid rollback mechanisms—directly addresses each of these failure points.

The Business Case for DevOps Culture

DevOps is not only about preventing disasters. Organizations that invest in a genuine DevOps culture gain concrete competitive advantages:

• Faster time to market: Shorter release cycles allow teams to test ideas with real users and iterate based on feedback, rather than betting on long development cycles.
• Greater reliability: Continuous integration and continuous delivery (CI/CD) pipelines catch defects earlier, reducing the cost and impact of bugs.
• Scalability: Containerized, cloud-native architectures—exemplified by platforms like Kubernetes—let organizations scale individual services independently rather than over-provisioning monolithic systems.
• Developer productivity: Removing friction from the build, test, and release process allows engineers to focus on building features rather than managing manual handoffs.

Large-scale acquisitions have reflected the market’s confidence in DevOps tooling and culture. IBM’s acquisition of Red Hat and Microsoft’s acquisition of GitHub are frequently cited examples of enterprise-level investment in the open-source and developer tooling ecosystems that underpin DevOps workflows.

Continuous Delivery and the Move Toward Liquid Software

The concept of Liquid Software—a term associated with JFrog and others in the binary management space—describes a future state where software updates flow continuously and invisibly to end users, much like a utility. Rather than scheduled releases, software is updated in real time with no user-visible downtime or manual intervention.

This vision extends CI/CD pipelines to their logical conclusion: fully automated, policy-driven delivery of verified binaries directly to production and to edge devices. Achieving this requires not just tooling, but a cultural shift in how development, security, and operations teams collaborate.

DevOps at Scale: Containers and Multi-Cloud

Containers have become the default packaging format for modern applications. Google has cited running over two billion containers per week across its infrastructure, spanning services from Gmail to YouTube to Search. While that scale is unusual, the underlying pattern—containerized microservices deployed and orchestrated automatically—is now common across organizations of all sizes.

Alongside containerization, multi-cloud strategy has become a practical reality. Organizations routinely run workloads across a mix of on-premises infrastructure and multiple public cloud providers. Platforms such as Google Anthos, and similar offerings from other vendors, reflect the market demand for portability and flexibility—avoiding lock-in while preserving the ability to optimize cost and performance across environments.

Effective DevOps in a multi-cloud environment requires:

• Infrastructure-as-code practices that are cloud-agnostic or portable
• Centralized artifact management so binaries are built once and promoted across environments
• Unified observability across all deployment targets
• Security policies enforced at the pipeline level, not applied manually per environment

Building a Developer-First Culture

Technology choices alone do not create a DevOps organization. The cultural dimension—how teams communicate, how work is structured, and who owns quality—is equally critical.

A Developer First mindset means that the tools, workflows, and organizational policies are designed around reducing friction for engineers, rather than imposing process overhead that slows delivery. This includes:

• Self-service infrastructure provisioning so developers are not blocked waiting for operations teams
• Automated security scanning integrated into CI pipelines (DevSecOps), rather than a separate sign-off gate
• Postmortems and blameless retrospectives that treat failures as system problems, not individual errors
• Communities of practice that allow engineers to share knowledge across teams and learn from peers

Educational institutions have also contributed to this shift. Computer science programs that incorporate full-stack development and DevOps practices graduate engineers who arrive in the workforce already fluent in CI/CD, version control, and cloud-native architectures. This has raised the baseline expectation for how software teams operate.

DevOps Is Expanding Beyond Technology Sectors

While DevOps originated in software product companies, the practices are increasingly relevant to any organization that depends on software to deliver services—which, at this point, means virtually every industry.

Healthcare organizations use software to manage patient records, diagnostic equipment, and clinical workflows. Financial institutions run trading platforms, fraud detection systems, and customer-facing applications. Government agencies deliver public services digitally. In each case, the reliability, speed, and security of software delivery directly affects outcomes for real people.

Organizations in these sectors that adopt cloud-native architectures and DevOps practices gain the same benefits as technology companies: faster iteration, greater resilience, and the ability to respond to changing requirements without long release cycles.

The Talent Dimension

Demand for DevOps engineering skills remains strong. The role spans a broad set of competencies: CI/CD pipeline design, infrastructure automation, container orchestration, cloud architecture, observability, and security. Engineers who combine these skills with an understanding of software delivery culture are positioned well for senior engineering and leadership roles.

For organizations, the implication is that hiring and retaining DevOps-capable engineers requires more than a competitive salary. It requires an environment where those engineers can practice what they know—with modern tooling, meaningful ownership, and a culture that values quality and speed equally.

Key Takeaways

• Software failures in critical infrastructure—power, aviation, consumer devices—demonstrate the real cost of poor release practices.
• DevOps culture accelerates delivery while improving reliability when implemented genuinely, not just as a rebranding of existing processes.
• Containerization and multi-cloud strategies are now standard architecture patterns, not emerging trends.
• The Liquid Software vision—continuous, invisible updates—is the logical destination of a mature CI/CD practice.
• DevOps is expanding into healthcare, finance, government, and other sectors as software becomes central to every industry’s operations.
• Cultural change—developer-first mindset, blameless postmortems, shared ownership of quality—is as important as tooling.

Organizations that treat DevOps as a checkbox exercise rarely see the expected results. Those that invest in the cultural foundation—not just the pipeline tooling—are the ones that consistently ship better software, faster, and with greater confidence in its reliability.

The Cloud Journey: From Colocation Replacement to Serverless Innovation

Looking back at a decade of innovation in both private and public cloud—led by Amazon, Microsoft, Google, and IBM—one of the most significant emerging trends is the accelerating shift toward serverless computing and the appliance model. This shift is not just a technology upgrade; it represents a fundamental change in how organizations conceive, build, and validate new products.

In cloud computing’s early days, most enterprises treated the cloud as a simple substitute for colocation facilities or on-premises data centers. The incremental benefits were real but modest: capital expenditure moved to an operational model, and managed services meant cloud providers handled software updates and OS patching. Companies running Microsoft workloads, for instance, could offload the burden of periodic Windows Server updates to the provider.

The Rise of Platform as a Service (PaaS)

As cloud matured, organizations graduated from simple infrastructure lift-and-shift to Platform as a Service (PaaS). PaaS delivers computing resources and software tools over the internet, allowing teams to scale capacity up or down on demand. This model reduces up-front investment and frees engineering teams to focus on building applications rather than managing hardware.

To accelerate this PaaS transition, major public cloud providers began investing heavily—through internal development and acquisitions—in pre-built serverless components with unit functionality baked in. These ready-made building blocks changed the economics of experimentation fundamentally.

Why Serverless Components Democratize AI Innovation

Before serverless cloud platforms offered pre-packaged AI capabilities, meaningful experimentation with machine learning or computer vision required substantial capital: dedicated hardware, licensed software, specialized staff, and months of setup time. Only large enterprises with deep pockets could afford to run AI experiments at scale.

Serverless cloud changes this equation in several concrete ways:

• Lower barrier to entry: Startups and small teams inside larger organizations can access cloud-hosted, pre-packaged AI models—covering areas like computer vision, natural language processing, and anomaly detection—without building those capabilities from scratch.
• Faster iteration cycles: Because the foundational algorithms already exist, teams spend time applying and tuning them rather than re-implementing them.
• Reduced sunk cost: If a product concept fails market validation, the cost of abandonment is a fraction of what it would have been with on-premises hardware and custom-built tooling.
• Built-in scalability: Serverless infrastructure scales automatically with demand, so a prototype can be stress-tested under realistic load without provisioning separate environments.

Practical Example: AI-Powered Drive-Through Kiosks

Consider a company that manufactures kiosks and digital signage for fast-food chains. Traditionally, every customer approaching a drive-through sees the same static menu. An AI-powered kiosk could personalize recommendations based on contextual signals: current weather conditions, time of day, and customer demographic data derived from anonymized visual recognition.

Building this kind of system from scratch even five years ago would have required assembling multiple custom software modules:

1. Proximity detection software to identify when a customer is within range of the kiosk.
2. A weather data integration layer to pull real-time conditions.
3. A computer vision module to perform demographic inference from camera input.
4. A recommendation engine to tie the above signals together and surface relevant menu items.

That effort would demand significant budget, a large cross-functional team, and months of development before a single real-world test could occur—with no guarantee the underlying concept would resonate with customers or perform as intended.

With today’s serverless cloud platforms from Microsoft Azure, AWS, and Google Cloud, all of those components exist as managed services. A single developer can wire together face-recognition APIs, edge sensors, weather service integrations, and a recommendation layer in days rather than months. A minimum viable product becomes achievable in three to five months, enabling rapid pilot deployments at select locations, real customer feedback loops, and iterative refinement—all at dramatically lower risk.

Real-World Application: AI in Legal E-Discovery

The original article describes a first-person account from an organization building a cloud-native legal e-discovery product. As the product gained market traction, the team wanted to deepen their investment in cognitive analytics to help litigation attorneys surface patterns in large document sets—identifying relevant case documents faster and reducing the time spent on manual review.

In a pre-serverless world, this kind of data science initiative would have required substantial investment in on-premises hardware and machine learning infrastructure before a single experiment could run. Instead, their data science team was able to:

• Brainstorm and evaluate specific algorithms suited to the problem—such as document clustering and TF-IDF (Term Frequency–Inverse Document Frequency), a standard natural language processing technique for identifying the most significant keywords in a document corpus.
• Spin up machine learning environments rapidly using serverless cloud components, rather than provisioning and configuring hardware.
• Build on existing base algorithms rather than implementing them from scratch, accelerating iteration.
• Run controlled experiments with internal teams and external customer groups before promoting any solution to production.

This level of agility—running multiple experimental tracks in parallel, validating with real users, and pivoting quickly based on results—would have been operationally and financially prohibitive without serverless cloud infrastructure.

Key Takeaways for DevOps and Engineering Teams

The serverless shift has practical implications for how DevOps teams structure AI experimentation and delivery pipelines:

• Prototype first, infrastructure later: Use managed AI services to validate a concept’s technical and market viability before committing to custom infrastructure.
• Treat serverless components as dependencies, not replacements: Pre-built AI services accelerate development but still require integration work, security review, and ongoing cost management.
• Design for iteration: Serverless architectures naturally support blue-green or canary deployments. Build feedback loops into prototypes from the start to gather meaningful signal quickly.
• Monitor costs actively: Serverless eliminates up-front hardware costs but can accumulate usage-based charges at scale. Cost observability should be part of any MVP deployment.
• Evaluate vendor lock-in consciously: Pre-packaged AI services from AWS, Azure, or GCP vary in portability. Teams should assess abstraction strategies (such as wrapping vendor calls behind internal APIs) early in the project lifecycle.

Conclusion

Serverless cloud computing has fundamentally redistributed access to AI-driven innovation. The building blocks—vision APIs, NLP services, edge computing primitives, pre-trained models—already exist in the major cloud platforms. The competitive advantage no longer lies in who can afford to build those capabilities, but in who can apply them most creatively and validate ideas most quickly.

For DevOps and engineering teams, this means adopting a growth mindset: treating each prototype as a learning opportunity, leveraging managed services to compress the feedback loop, and reserving custom development for the capabilities that genuinely differentiate your product in the market.

Narrow AI vs. Cognitive Computing: What’s the Difference?

When engineers and product teams talk about AI today, they usually mean narrow AI — systems trained to solve a specific, well-defined problem. A model that identifies tumors in radiology scans is extraordinarily capable at that task, but it cannot be repurposed to answer customer-service queries or optimize a supply chain without being rebuilt from scratch.

Cognitive computing — sometimes framed under the broader term artificial general intelligence (AGI) — takes a different approach. The goal is to build systems that can:

• Make sense of complex, multi-variable situations
• Interpret vague, incomplete, or contradictory data
• Learn continuously from past outcomes
• Apply learned understanding to novel future scenarios

In practice, current cognitive systems sit somewhere between narrow AI and true AGI. They combine multiple AI disciplines — natural language processing (NLP), computer vision, machine learning, knowledge graphs — into platforms that can reason across domains rather than excelling at only one.

Market Context: Why Cognitive Services Are Growing Fast

Enterprise adoption of cognitive services has accelerated sharply. Organizations are deploying these capabilities to extract deeper insights from data, personalize user experiences, and streamline operations through intelligent process automation. As competitive pressure intensifies, cognitive capabilities are increasingly cited as a differentiator — those who invest early will be better positioned to deliver dramatically improved customer experiences before competitors catch up.

The compute intensity of cognitive workloads is precisely why cloud infrastructure has become the default delivery model. Training and inference at scale require elastic, on-demand resources that on-premises data centers struggle to provide cost-effectively.

The Leading Cloud Cognitive Platforms

The four dominant cloud providers each offer modular cognitive service catalogs. While their capabilities overlap significantly, each has distinct strengths:

By exposing these capabilities as API-driven, pay-per-use services, cloud providers have democratized cognitive computing — making capabilities that once required large research teams accessible to organizations of almost any size.

Building a Business Case First

The sheer breadth of available cognitive services — image analysis, video analysis, NLP, translation, sentiment analysis, speech recognition, recommendation engines — can make choosing a starting point feel overwhelming. The antidote is simple: anchor every cognitive initiative to a concrete business outcome before evaluating technology options.

Good questions to ask at the outset include:

• Which customer pain points or internal inefficiencies would benefit most from intelligent automation or deeper insight?
• What data do we already have, and is it in a form that cognitive services can consume?
• What does success look like — and how will we measure it?
• What is the minimum viable cognitive capability needed to demonstrate value quickly?

Starting with a focused use case — for example, reducing call-center volume with an NLP-powered virtual agent, or improving defect detection with computer vision — allows teams to learn fast and build organizational confidence before scaling.

Assessing Your Organization’s Digital Readiness

Cloud-native cognitive services are not a plug-and-play addition. They build on existing digital maturity. Your path to operationalizing cognitive capabilities depends heavily on your starting point:

Organizations Already Cloud-Native

Teams comfortable designing, building, and deploying applications in cloud-native environments — using containers, microservices, CI/CD pipelines, and infrastructure-as-code — are well placed to integrate cognitive APIs quickly. The architectural patterns are already established; adding a cognitive service is primarily an integration and data-quality challenge.

Organizations Mid-Way Through Digital Transformation

If your organization is still migrating from monolithic architectures to microservices, or is in the early stages of adopting DevOps practices, cognitive services are still within reach — but the sequencing matters. Shoring up CI/CD automation, improving test coverage, and establishing a reliable deployment pipeline will make cognitive integration significantly smoother.

Organizations Early in Cloud Adoption

Cloud-based cognitive resources are available regardless of where you sit on the maturity curve, but teams should expect a longer runway. Foundational investments in cloud infrastructure, data engineering, and DevOps tooling are prerequisites, not optional extras.

Technical Prerequisites: What DevOps Teams Should Prioritize

Several engineering capabilities are especially important when preparing an environment for cloud-native cognitive workloads:

1. High Levels of Automation

Cognitive services — especially those involving real-time predictive analytics — generate outputs at a speed and volume that manual processes cannot handle. Teams that rely on significant manual intervention in their build, test, or deployment workflows will lack the bandwidth to respond effectively. Investing in automated testing, automated deployment, and intelligent monitoring is a prerequisite, not an afterthought.

2. Robust, Scalable Test Environments

Cognitive systems introduce new testing challenges: model drift, non-deterministic outputs, bias detection, and data-pipeline integrity all require dedicated testing strategies. A mature test environment — ideally one that uses AI-assisted test optimization to prioritize what needs attention — is essential for confident deployments.

3. Clean, Accessible Data Pipelines

Cognitive services are only as good as the data fed into them. Inconsistent, siloed, or poorly governed data is among the most common reasons cognitive initiatives stall. Establishing clear data ownership, data quality standards, and reliable ingestion pipelines before deploying cognitive models reduces costly rework downstream.

4. Microservices Architecture

Cognitive capabilities are best delivered as modular, independently deployable services. A microservices architecture makes it practical to upgrade individual cognitive components — swapping one NLP provider for another, for example — without disrupting the broader system.

5. Continuous Integration and Deployment for ML Models

MLOps — the discipline of applying DevOps principles to machine learning model development and deployment — is increasingly central to cognitive service delivery. Teams should plan for model versioning, automated retraining triggers, and rollback mechanisms as standard parts of the delivery pipeline.

Choosing the Right Cognitive Services Combination

Given the overlap in offerings between major providers, vendor selection should be driven by factors beyond headline capabilities:

• Existing cloud commitments: Organizations with significant Azure spend may find Azure Cognitive Services easier to integrate and negotiate on pricing.
• Specific model quality: Benchmark the services relevant to your use case — NLP accuracy varies meaningfully across providers for different languages and domains.
• Data residency and compliance: Understand where data is processed and stored, particularly for regulated industries.
• Pricing model fit: Pay-per-API-call models suit low-volume or experimental workloads; committed-use discounts matter at scale.
• Ecosystem and tooling: Consider SDK quality, documentation, support tiers, and available pre-built connectors for your existing stack.

It is worth evaluating specialist vendors and well-funded start-ups alongside the hyperscalers. In some domains — healthcare NLP or industrial computer vision, for example — purpose-built providers may outperform general-purpose cloud APIs significantly.

Summary: Getting Started

Cognitive computing is not a single technology but a constellation of AI capabilities that, combined, allow systems to reason, learn, and adapt in ways narrow AI cannot. For DevOps and platform engineering teams, the practical journey looks like this:

1. Identify a concrete business problem where cognitive capabilities offer measurable improvement over current approaches.
2. Audit your digital maturity — CI/CD pipeline health, test automation coverage, data pipeline quality, and cloud-native architecture readiness.
3. Close foundational gaps first — automate testing, establish data governance, and adopt microservices where needed.
4. Evaluate and prototype with the cognitive APIs most relevant to your use case across two or three providers.
5. Build MLOps practices in from the start — model versioning, monitoring, and automated retraining are not optional extras.
6. Measure outcomes against the original business case and iterate before scaling.

Organizations that invest in this foundational work now will be significantly better placed to compound cognitive capabilities over time — building progressively more sophisticated user experiences and operational efficiencies as the technology matures.

What Is a Container Registry?

A container registry is a centralized repository for storing, organizing, and distributing container images. Think of it as a version-controlled artifact store specifically designed for container images. A registry lets teams:

• Publish images produced during the build process
• Store multiple versions of an image alongside its metadata
• Locate and download specific image versions at deployment time
• Manage access to images across teams, environments, and pipelines

Unlike a simple file store, a registry understands the layered structure of container images, supports tagging and versioning, and integrates natively with container runtimes and orchestration platforms. Consumers — whether human developers or automated CI/CD pipelines — can pull a specific version of an image exactly as it was published, ensuring reproducibility across environments.

Public Registries: Docker Hub and Its Trade-offs

Docker Hub is the most widely known public container registry and a convenient starting point for pulling community-maintained base images. However, using Docker Hub — or any fully public registry — as the primary store for your organization’s images comes with meaningful risks:

• No moderation by default: Public registries allow any user to publish images. Without a curation or approval layer, it is difficult to verify that a third-party image does not contain malicious or vulnerable software.
• Exposure of sensitive content: Application images often embed configuration, credentials, or proprietary code. Pushing those to a public registry exposes them to the internet.
• Rate limiting and availability: Public registries can impose pull-rate limits that disrupt CI/CD pipelines, especially at scale.
• Supply chain risk: Depending on community-maintained images without scanning them introduces software supply chain risk into your deployments.

Security Considerations with Kubernetes

Kubernetes adds another dimension to container image security. Clusters routinely pull images from registries to run workloads, which means a compromised or malicious image can spread quickly across an environment. Security is consistently cited as one of the top challenges for Kubernetes operators, spanning image provenance, network policy, secrets management, and runtime threat detection. A controlled, private registry is one of the most effective first steps toward reducing the container security attack surface in Kubernetes environments.

Why Organizations Need a Private Container Registry

A private container registry — whether self-hosted or provided by a third-party vendor — addresses the shortcomings of purely public options. Key reasons organizations adopt private registries include:

1. Image Security and Access Control

Private registries support role-based access control (RBAC), letting you define exactly which teams or automated systems can push or pull specific images. This prevents unauthorized access to proprietary images and limits blast radius if credentials are compromised.

2. Vulnerability Scanning

Many private registries integrate vulnerability scanning directly into the push workflow. Images are scanned for known CVEs before they are made available to downstream consumers, creating a security checkpoint inside the delivery pipeline rather than relying on ad-hoc scanning.

3. Developer Productivity

Container registries integrate with the tools developers already use: CLI clients, IDE plugins, CI/CD platforms, and Kubernetes admission controllers. Developers can push images directly from a local build environment and have those images immediately available to staging or production pipelines. This tight integration reduces friction in the image lifecycle and keeps teams focused on shipping software rather than managing infrastructure.

4. Centralized Image Lifecycle Management

A private registry gives operations teams a single pane of glass for all container images across the organization. Retention policies, garbage collection, audit logs, and promotion workflows (e.g., from a dev registry to a production registry) can all be managed centrally, reducing drift and improving auditability.

5. Protection of Proprietary Assets

Enterprise application images frequently contain compiled proprietary code, licensed dependencies, or embedded configuration. Keeping those images in a private registry ensures they are never inadvertently exposed publicly and remain subject to your organization’s data governance policies.

Choosing Between Self-Hosted and Managed Registries

Organizations typically evaluate two approaches:

• Managed registries (cloud provider or SaaS): Options include Amazon ECR, Google Artifact Registry, Azure Container Registry, and JFrog Artifactory Cloud. These reduce operational overhead and integrate natively with the surrounding cloud ecosystem.
• Self-hosted registries: Projects like Harbor (CNCF graduated) and the Docker Distribution registry can be run on-premises or in a private cloud, giving teams full control over data residency and configuration at the cost of additional operational responsibility.

The right choice depends on your compliance requirements, existing cloud footprint, team capacity, and cost model.

Container Registries and the CI/CD Pipeline

A container registry is most valuable when it is a first-class citizen of your CI/CD pipeline. A typical integration pattern looks like this:

1. Build: The CI system builds a container image from source code and a Dockerfile.
2. Scan: The image is scanned for vulnerabilities before being pushed.
3. Push: The CI system authenticates to the private registry and pushes the image, tagged with a build number, Git commit SHA, or semantic version.
4. Promote: Upon passing automated tests, the image is promoted (re-tagged or copied) to a production-ready repository within the registry.
5. Deploy: Kubernetes or another runtime pulls the specific image version from the registry during deployment.

This workflow ensures that every artifact deployed to production has a traceable, immutable history and has passed defined quality gates.

Summary

Container registries are not optional infrastructure in a mature DevOps practice — they are a prerequisite for secure, reproducible, and efficient container-based software delivery. Public registries like Docker Hub are useful for consuming community base images, but organizations that build and ship their own containerized software need a private registry with access controls, vulnerability scanning, and deep CI/CD integration. Investing in the right registry solution early pays dividends in security posture, developer experience, and operational reliability as container workloads scale.