As cloud adoption continues to transform the modern enterprise, organisations consume the cloud differently as they extend the scope and scale of their digital business strategies. They have the option to pick and choose from various hybrid cloud infrastructures and services. But using disparate services and solutions—such as multi-cloud, hybrid environments, software as a service (SaaS) and platform as a service (PaaS), plus various applications and endpoints—introduces implementation, management and security challenges to the cloud computing landscape. And because of the proliferation of multi-cloud, many enterprises maintain heterogeneous cloud environments, with tools and systems from various platforms differing significantly. All of this makes building and managing a consistent security strategy increasingly difficult.

Organisations need to have a security strategy that includes visibility and control across all kinds of cloud infrastructures. This enables them to keep applications and devices secure and connected, from the remote user to the data centre to the cloud. And because each organisation is unique, there are a variety of cloud security options available to meet all of their demands. But beware. Without careful planning, these options can quickly lead to vendor and solution sprawl that introduces another layer of complexity to an already complicated problem.

Application-layer security
The proliferation of BYOD and IoT, especially as workers have become more dispersed and remote, creates a unique level of security complexity at the application level. Business-critical applications, built on a variety of cloud infrastructures, need to adhere to the security policies of an organisation, keeping users, the network, data and workloads all secure. An advanced application-layer security protocol can detect security vulnerabilities before they become a problem. But it not only needs to span the distributed—and evolving—network; it also needs to provide a single source of truth to simplify management and policy enforcement.

Network security
Of course, applications are only part of the equation. Equally important is keeping the network itself secure. Organisations with hybrid cloud infrastructures and multi-cloud environments require secure network connectivity across all locations and endpoints, and even between applications residing within the same cloud or data centre. These cannot operate in isolation.

Security solutions protecting these critical points of interaction need to be able to see each other, share policies and threat intelligence, and participate in a coordinated response to any sort of threat. This, again, can be especially challenging for enterprises faced with skills and resource gaps, particularly when operating remotely from home while attempting to manage multiple cloud instances and networks simultaneously.

Securing the public cloud
Public cloud offers an open system where stored data and critical business applications can be made available to workers, whether local or remote, as well as to the public via the internet. Public, private and hybrid clouds all require consistent security postures to protect users, devices, applications and networks, while high-speed VPN connections protect data. However, public clouds—especially multi-cloud environments—pose a special challenge because each runs its own unique system of rules and protocols. Security policies need to be consistent and enforced across all environments and should be managed with single-pane-of-glass controls.

This means that security solutions deployed on multiple public cloud platforms not only need to function as native solutions but also interoperate in spite of their functional differences. This requires tools designed to operate seamlessly in and across all major public cloud environments, enabling a single, holistic security fabric that can span the most highly distributed and dynamic environments.

Security solutions, and security teams, also need to understand the shared-responsibility model. While needing to trust public cloud providers to protect the network, storage and computing layers, they need to understand—and deploy—security solutions designed to secure anything that they produce, deploy or store in the public cloud. Best-in-breed cloud security solutions incorporate native cloud integrations with all major public cloud providers to ensure privacy and confidentiality.

Hybrid cloud security
Hybrid cloud environments provide for greater flexibility, with a combination of private cloud services, a public cloud and on-premises infrastructure—all orchestrated to work together as seamlessly as possible. However, a hybrid cloud that uses on-premises data centres and public cloud platforms requires rigorous security management.

An effective security solution purpose-built for a hybrid cloud infrastructure should include:

Auto-scale capabilities for network security and capacity
Centralised management for automatic provisioning
Site-to-site VPN connectivity to migrate workloads
Segmentation of persistent connections to deliver end-to-end security
Full transparency and control for compliance governance
Platform security
Finally, and maybe most importantly, is the implementation of a consistent security platform. Platform security provides the architecture, tools and processes needed to secure an entire cloud computing ecosystem. It provides consistent security and connectivity solutions combined with single-pane-of-glass visibility across the ecosystem, enabling organisations to maintain consistent security policies across the entire infrastructure to effectively manage risk at less cost, while easing the burden on security teams.

Securing all types of clouds
Protecting an organisation’s systems and assets in the cloud should be a primary priority, wherever they reside. Making this possible starts by ensuring that multi-cloud and hybrid networks are able to see and talk to each other for quick detection and resolution of security incidents. Regardless of which combinations of cloud your organisation chooses to consume, security needs to be natively deployed and be able to adapt to and protect all of these environments.

VMware last week unveiled VMware Cloud to help customers unlock the power of multi-cloud and deliver modern applications at the speed of business.

VMware Cloud boosts developer productivity by enabling them to build and deploy to any cloud. The platform enables IT to modernize infrastructure and operations with better economics and less risk.

With the launch of VMware Cloud, VMware also announced new offerings that bring a more integrated experience to customers. These offerings include:

– VMware Cloud Universal: a flexible subscription that simplifies the purchase and consumption of VMware multi-cloud infrastructure and management services.

– VMware Cloud Console: a single monitoring and management environment for VMware Cloud infrastructure regardless of where it’s deployed.

– VMware App Navigator: a new offering for assessing and prioritizing app transformation initiatives across an entire application estate based on the value of each app.

With VMware Cloud, customers can deploy apps to VMware Cloud Foundation running in Amazon Web Services (AWS), Azure, Google Cloud, IBM Cloud, and Oracle Cloud; on VMware Cloud on Dell EMC; and across hundreds of VMware Cloud Verified partners.

VMware Cloud is a distributed, multi-cloud platform that enables organizations to accelerate application modernization across the data center, edge, and any cloud. It provides distinctive advantages to both developers and IT operators who are often forced to make tradeoffs. VMware Cloud boosts developer productivity by enabling them to build and deploy to any cloud. The platform enables IT to modernize infrastructure and operations with better economics and less risk. With the launch of VMware Cloud, VMware is announcing new offerings that bring a more integrated experience to customers. These offerings include:

+ VMware Cloud Universal: a flexible subscription that simplifies the purchase and consumption of VMware multi-cloud infrastructure and management services.

+ VMware Cloud Console:a single monitoring and management environment for VMware Cloud infrastructure regardless of where it’s deployed.

+ VMware App Navigator: a new offering for assessing and prioritizing app transformation initiatives across an entire application estate based on the value of each app.

“We are on the cusp of the next evolution of cloud and apps. Architectures are becoming distributed and increasingly multi-cloud, while modern applications will soon outnumber traditional apps. The challenge for any CIO is to take advantage of this new innovation without introducing more complexity and risk,” said Raghu Raghuram, chief operating officer, products and cloud services, VMware. “VMware Cloud is the only cloud solution today that customers can use in the data center and on any cloud, accelerating their modernization journey with speed, simplicity, and better security. With VMware Cloud Universal, customers make a single purchase and gain the ability to deploy apps across any environment, then move them as business or application requirements change.”

Modular, Multi-Cloud Services for All Applications, Everywhere

Application initiatives are driving better business outcomes, an elevated customer experience, innovative digital services, and the anywhere workforce. VMware research shows that 90% of app initiatives are focused on modernization(1), and 80% of organizations today deploy applications in a distributed model across data center, cloud, and edge.

VMware Cloud is the platform for both on-premises and cloud with unified security and operations, supporting traditional and modern applications; connecting to all native cloud services; and meeting the requirements of both developers and IT operators. With VMware Cloud, customers gain the simplicity of a single cloud operating model for their multi-cloud reality, and gain portability to help minimize to help address the challenges of single cloud silos. VMware Cloud customers can realize substantive benefits including as much as 80 percent better developer productivity with VMware Tanzu Application Service (3), 59 percent lower operational costs(4), and 46% faster cloud migration.

With VMware Cloud, customers can deploy apps to VMware Cloud Foundation running in AWS, Azure, Google Cloud, IBM Cloud, and Oracle Cloud; on VMware Cloud on Dell EMC; and across hundreds of VMware Cloud Verified partners. VMware Marketplace provides customers access to thousands of validated third party and open-source developer solutions. VMware Cloud customers can also deploy andoperate across native public clouds, and give developers access to allnative cloud services.

As enterprises ramp up their adoption of modern architectures that embrace microservices, containers and Kubernetes, application deployment strategies are being re-evaluated. Organizations operating and serving customers globally or regionally need to think about how best to make their applications available, responsive and high-performing no matter where the end user (or end device) lives.

But in an environment where enterprises operate both on-premises and in the cloud (and perhaps multiple clouds), operating Kubernetes clusters across multiple environments brings about a new set of deployment challenges. Consider the following:

A cloud gaming company develops and operates an interactive online service for customers in Asia. One cloud provider is selected with multiple regions across Asia and the provider’s managed Kubernetes service is being leveraged. Multiple Kubernetes clusters actually run in several regions to best serve its end users.

The company decides to expand its operations to Europe. The company’s IT operations team needs to evaluate European cloud providers since their Asian cloud provider doesn’t serve Europe. To complicate matters, certain European countries have geo-specific privacy and compliance laws that mandate the company store customer data in the country of residence. The company now finds itself needing several different public cloud providers. Because each cloud provider tends to offer a homegrown managed Kubernetes service, the company has to unify and simplify its Kubernetes deployment strategy to deal with multiple clouds and multiple distributions.

The company’s expansion to Europe is paying off and it has decided to acquire a rival gaming company. The acquired company operates its gaming platform in four data centers around the world and also leverages several different public cloud providers. The acquired company has decided to spin up upstream Kubernetes in all locations and has invested in an internal platform to manage and operate Kubernetes everywhere. How will the merged company manage and operate Kubernetes across clouds and data centers, including multiple Kubernetes distributions, going forward?

Challenges of Managing Diverse Clusters, Environments
Kubernetes cluster management is complex for a single cluster. Extended to multiple clusters and multiple distros, effective management may be unattainable for all but the most sophisticated SRE/Ops teams with deep expertise. To unify management and operations across clouds and distro, a Kubernetes management platform is required that should provide:

Complete visibility and governance across a company’s fleet of Kubernetes clusters, regardless of distribution. The IT or SRE/Ops team must be able to quickly figure out where a given service is running at present, which app is experiencing restarts in a given cluster, which apps have been upgraded across the fleet in the last month and much more.
On-demand cluster bring-up and customization in any cloud environment or on-premises. In addition to simply bringing up Kubernetes, SRE/Ops teams are responsible for ensuring that a given cluster is customized appropriately and conforms to the business’ security/compliance requirements and can be easily upgraded as needed.
Continuous deployment capabilities are required across the entire cluster fleet without requiring multiple deployment tools. SRE/Ops teams need access to deployment tools that work across any cluster type, in any environment, and do not require scripting/coding investments that traditionally fall on DevOps teams.
While it is possible to internally build a platform that provides these functions, this effort requires stitching together dozens of open source tools. It also requires hiring and training hard-to-find people to build and debug the platform, and then ongoing maintenance and upgrades as clusters morph and expand. The process can take multiple quarters and require an ongoing investment in people, resources and infrastructure. Still, many companies initially go down this road, only to get mired in the complexity after several months of effort.

Turnkey Solutions for Kubernetes
Is there an easier, faster and more cost-effective way? Turnkey management platforms are emerging as viable alternatives to building in-house Kubernetes platforms. These platforms can be implemented quickly and bring up enterprise-grade, production-ready clusters in minutes. Beyond saving time and resources, these platforms provide:

Global, cross-cloud, single-pane-of-glass management for centralized provisioning, monitoring and problem resolution.
Cluster blueprinting/templating enables enterprises to seamlessly add their own customized clusterwide services to create a reusable blueprint for easy replication in multiple environments.
Out-of-the-box enterprise tntegrations for registry, logging, monitoring, security, etc., to reduce development and ongoing maintenance costs.
Containerized application lifecycle management to automate and simplify the deployment, scaling, upgrading and operation of applications across multi-region, multi-cloud and hybrid environments.
When compared with roll-your-own solutions, turnkey Kubernetes management platforms are less expensive to implement, far faster to deploy and require much lower administrative costs. So when thinking about how to manage a growing collection of multi-cloud, multi-distribution clusters, DevOps and SRE/Ops teams should take a look at these platforms as an alternative to the pain of building and maintaining one on their own.

Microsoft Expands Hybrid and Multi-Cloud Capabilities at Ignite 2020

At its Ignite 2020 virtual conference, Microsoft announced a broad set of updates to its Azure hybrid and edge portfolio. The announcements spanned security improvements, new Kubernetes support, edge hardware, and IoT integrations — reinforcing Microsoft’s long-standing strategy of making Azure hybrid by design, capable of running workloads across on-premises data centers, multiple public clouds, and edge devices.

Azure Arc: Managing Infrastructure Across Any Cloud

Azure Arc, launched at Ignite 2019, allows enterprises to project Azure management and services onto any infrastructure — including AWS, Google Cloud, and on-premises servers. At Ignite 2020, Microsoft announced two significant updates:

• Azure Arc enabled data services (preview): Extends Azure data capabilities — such as Azure SQL Managed Instance and PostgreSQL Hyperscale — to any Kubernetes cluster, regardless of where it runs.
• Azure Arc enabled servers (generally available): Organizations can now manage Windows and Linux machines hosted outside of Azure using the same Azure control plane used for native Azure VMs, including policy enforcement, inventory, and update management.

Earlier in 2020, Azure Arc also gained support for Kubernetes, enabling teams to attach and configure Kubernetes clusters running anywhere and apply GitOps-based configuration management.

Azure Stack: On-Premises Cloud for Compliance and Disconnected Scenarios

Azure Stack — Microsoft’s family of products for running Azure services in customer-owned data centers — has been available for more than three years. It is aimed at organizations with regulatory requirements that prevent certain data from leaving their facilities, or that need to operate in disconnected or partially connected environments.

At Ignite 2020, Microsoft announced two new capabilities for Azure Stack:

• Azure Kubernetes Service (AKS) on Azure Stack HCI (preview): Enables customers to deploy and manage containerized applications at scale on Azure Stack HCI infrastructure, using the same AKS tooling and experience available in the public cloud.
• Azure Stack Hub with GPU support (generally available): Customers can now run compute-intensive machine learning workloads in disconnected or partially connected environments using NVIDIA V100 Tensor Core GPUs. A less compute-intensive option using the NVIDIA T4 Tensor Core GPU is also available, enabling GPU sharing across workloads.

New Edge Capabilities: Devices, Data, and IoT

Microsoft also announced a set of new edge offerings designed to bring compute and AI capabilities closer to IoT devices and remote locations:

Azure SQL Edge — Generally Available

Azure SQL Edge brings Microsoft’s SQL data engine to IoT gateways and edge devices. It is optimized for IoT scenarios, supporting time-series data streaming, and can run in connected or disconnected states. Its general availability makes it a production-ready option for organizations looking to process and query data at the edge before forwarding it to the cloud.

New Azure Stack Edge Hardware

Microsoft announced two new rugged Azure Stack Edge devices suited for challenging field environments:

• Azure Stack Edge Pro R: A ruggedized device powered by an NVIDIA T4 GPU, designed for machine learning inferencing and quick insights at the edge in harsh environments.
• Azure Stack Edge Mini R: A lightweight, portable device intended for highly mobile or space-constrained deployments.

In addition, the Azure Stack Edge Pro series with GPU support became available, enabling customers to run visualization, inferencing, and machine learning workloads at the edge using the NVIDIA T4 Tensor Core GPU.

AT&T and Microsoft: Cellular Connectivity for Azure Sphere

Microsoft and AT&T announced a partnership to help enterprise customers connect industrial machines and equipment to the cloud securely. Using Azure Sphere guardian devices — which are designed to add connectivity and security to existing, often legacy, equipment — customers can route traffic through AT&T’s cellular network. This removes the dependency on local Wi-Fi infrastructure, which is often impractical or unavailable in industrial and manufacturing settings.

What This Means for DevOps and Platform Engineers

These announcements collectively reflect a consistent Microsoft strategy: converge cloud, on-premises, and edge environments under a single management and developer experience. For DevOps and platform engineering teams, the practical implications are significant:

• Unified control plane: Azure Arc enables policy, RBAC, and observability across heterogeneous environments — reducing the operational overhead of managing multi-cloud and hybrid setups.
• Kubernetes everywhere: AKS on Azure Stack HCI means the same container orchestration workflows apply on-premises as in the cloud, simplifying CI/CD pipelines for regulated industries.
• Edge ML pipelines: GPU-equipped edge devices and Azure SQL Edge make it feasible to push machine learning inference workloads to remote locations with limited or no connectivity.
• IoT security at scale: Azure Sphere with cellular connectivity addresses the longstanding challenge of securely connecting legacy industrial equipment without relying on shared enterprise Wi-Fi.

For teams evaluating hybrid cloud architectures, these Ignite 2020 announcements mark a meaningful maturation of Microsoft’s multi-cloud and edge story — moving several key capabilities from preview to general availability and extending the ecosystem to new hardware and partner integrations.

The Cloud Label Problem

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

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

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

Where Cloud Migration Actually Stands

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

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

Digital Transformation ≠ Wholesale Cloud Migration

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

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

Digital Distress Is a Real Competitive Risk

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

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

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

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

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

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

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

What the Forrester/IBM Research Found

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

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

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

Principles for a Workable Hybrid and Multi-Cloud Strategy

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

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

Conclusion

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

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

DevOps Adoption Is Accelerating — And Reshaping Org Charts

The boundaries between development, security, and operations teams are eroding. According to GitLab’s Global DevSecOps Survey, rising DevOps adoption is changing not just toolchains but job functions — blurring traditional role definitions across the entire software delivery lifecycle.

GitLab CEO and co-founder Sid Sijbrandij acknowledged the momentum while noting that significant work remains: “DevOps practitioners are working with faster release times, continuous integration and deployment, and progress towards shifting test and security left. That said, there is still significant work to be done, particularly in the areas of testing and security.”

Developers Are Taking On Operations Responsibilities — Partially

One of the survey’s clearest signals is how the developer role is expanding into traditionally ops-owned territory — but incompletely:

• 35% of developers say they define and/or create the infrastructure their application runs on.
• Yet only 14% say they monitor and respond to that same infrastructure — a task still largely owned by operations.
• More than 18% of developers instrument code for production monitoring.
• 12% serve as an escalation point during incidents.

This gap — where developers build infrastructure but rarely own its operational health — points to a structural ambiguity that can create blind spots in both reliability and security.

CI/CD Adoption Is Real, But Uneven

The survey confirms what many practitioners report anecdotally: DevOps tooling is delivering measurable speed improvements, but adoption of its more advanced practices remains fragmented.

• 83% of developers report releasing code more quickly after adopting DevOps.
• 38% said their DevOps implementation includes CI/CD.
• 29% include test automation in their DevOps practice.
• 16% have extended their practice to DevSecOps.
• Nearly 9% are working in multi-cloud environments.

While 60% of companies deploy multiple times per day, once a day, or once every few days, the maturity of their testing and security practices often lags that cadence.

Testing Is a Persistent Weak Link

Despite the industry-wide push toward continuous testing, the survey reveals a significant gap between deployment velocity and test coverage:

• Only 12% of respondents claim to have full test automation.
• Over 42% say testing happens too late in the development lifecycle.
• More than 42% of security respondents agree that testing occurs too late — consistent with the previous year’s findings.

Fast release cycles without proportionally mature test automation create compounding risk: bugs and vulnerabilities that could be caught early instead surface in production.

Security Ownership: Everyone — and No One

Perhaps the most operationally significant finding is the lack of consensus around who owns application security. The data reveals a fragmented picture:

• More than 25% of developers feel they are solely responsible for security.
• 23% of testers and 21% of operations professionals report the same feeling.
• On the security side, 33% of security team members say they “own” security.
• 29% of security professionals believe everyone should share responsibility equally.

When ownership is distributed this unevenly — and without clear process — accountability gaps emerge. Security teams consistently report that developers are not finding sufficient bugs in early development stages, and are slow to prioritize fixing those that are found. This pattern repeated from the previous year’s survey.

Security Teams See Ongoing Friction

Security professionals responding to the survey flagged three recurring pain points in their collaboration with development teams:

• 36% said it was hard to understand, process, and fix discovered vulnerabilities.
• 31% found prioritizing vulnerability remediation difficult.
• 42%+ reiterated that testing and security checks occur too late in the lifecycle.

GitLab Vice President of Security Johnathan Hunt framed the core challenge: “Although there is an industry-wide push to shift left, our research shows that greater clarity is needed on how teams’ daily responsibilities are changing, because it impacts the entire organisation’s security proficiency. Security teams need to implement concrete processes for the adoption of new tools and deployments in order to increase development efficiency and security capabilities.”

What This Means for DevSecOps Teams

The survey data points to a set of practical challenges that teams at any DevOps maturity level should address:

1. Define security ownership explicitly. Informal shared ownership — where everyone feels responsible but no one is accountable — is not a strategy. Document who owns vulnerability triage, remediation timelines, and sign-off at each pipeline stage.
2. Automate security checks in the pipeline. With only 16% reporting DevSecOps implementations, most teams have room to integrate SAST, DAST, dependency scanning, and container scanning into existing CI/CD workflows rather than treating them as post-deployment steps.
3. Invest in test automation incrementally. Moving from near-zero automation to full automation is rarely achievable in a single effort. Target the highest-risk code paths first and build coverage over time.
4. Align on role changes proactively. As developers take on infrastructure creation and monitoring responsibilities, update job expectations, training, and on-call rotation policies accordingly — before incidents expose the gap.

About the Survey

GitLab’s Global DevSecOps Survey gathered responses from more than 3,650 software professionals across 21 countries. The survey covers developer, operations, security, and testing roles, making it one of the broader cross-functional datasets available on DevOps and DevSecOps adoption trends.

Original reporting via itbrief.co.nz.

Overview: An Open, Provider-Agnostic Hybrid Cloud Stack

Red Hat — acquired by IBM in 2019 but operating with significant autonomy — used its 2020 Summit to articulate a sharp and detailed strategy for leading the hybrid cloud market. The company’s thesis is straightforward: customers need an infrastructure stack that is open-source, consistent across environments, and invisible to application developers. Rather than locking customers into any single provider’s tooling, Red Hat bets that a vendor-neutral, community-driven platform will win enterprise adoption at scale.

Red Hat Summit 2020 was held as a virtual event due to the COVID-19 pandemic. Keynotes and panel discussions featured newly appointed CEO Paul Cormier alongside a wide roster of product and engineering leaders who walked through each layer of the company’s cloud strategy.

Layer 1: Red Hat Enterprise Linux as the Foundation

Red Hat Enterprise Linux (RHEL) remains the company’s flagship product and the base on which everything else is built. At Summit 2020, Red Hat made RHEL 8.2 generally available, adding enhanced monitoring capabilities and improved container support.

CEO Paul Cormier framed RHEL’s historical significance during his keynote panel: “Linux started an innovation cycle that continues in full force today” — through virtualization, cloud computing, containers, Kubernetes, and now edge computing.

Stephanie Chiras, Vice President and General Manager for RHEL, reinforced that point: “Linux provides the foundation upon which all this innovation is based.”

Gunnar Hellekson, Senior Director of Product Management and Strategy, noted that RHEL’s defining market advantage is operational consistency — the ability to deploy workloads reliably across on-premises data centers, multiple public clouds, and edge environments. That consistency, he argued, compounds in value as it propagates up through higher-order products in the Red Hat portfolio.

Tim Cramer, Vice President for Software Engineering, acknowledged a productive internal tension: OpenShift’s rapid growth is placing significant pressure on the RHEL roadmap, driving the operating system to evolve faster to support container-native and cloud-native workloads.

Layer 2: OpenShift as the Cloud-Era Platform

While RHEL built Red Hat’s reputation, OpenShift — the company’s enterprise Kubernetes platform — is the product Red Hat is betting on for long-term cloud dominance. At Summit 2020, Red Hat announced OpenShift 4.4 with a set of capabilities targeted at both near-term enterprise needs and emerging workloads.

Key OpenShift 4.4 Capabilities

• Kubernetes 1.17 implementation — bringing the platform in line with the upstream project.
• Advanced Cluster Management — simplifying administration of large, distributed Kubernetes deployments.
• Policy-based management — enabling dynamic scaling in environments that must respond rapidly to changing demand.
• OpenShift Virtualization — described by Matt Hicks, Executive Vice President for Products and Technologies, as the release’s “revolution.”

OpenShift Virtualization integrates the KubeVirt open-source project, allowing virtual machines (VMs) to be imported and run natively inside OpenShift alongside Kubernetes-managed containers. This removes a long-standing architectural divide: teams no longer have to choose between their existing VM-based infrastructure and a modern container platform. Hicks argued this bridges legacy infrastructure and cloud-native operations, reduces licensing overhead, and creates new pathways for industries — such as telecommunications preparing 5G deployments — that cannot immediately abandon their existing VM estates.

Layer 3: Open Hybrid Cloud as the Competitive Differentiator

Red Hat CTO Chris Wright described the hybrid cloud landscape as having expanded far beyond simple on-premises/public-cloud combinations. Infrastructure now spans data centers, multiple public clouds, and distributed edge nodes. Red Hat’s open-source portfolio — built on years of Linux, virtualization, and container development — positions the company to serve all of those environments with a consistent platform.

Wright also pointed to the next frontier: reducing the cognitive overhead on developers working in hybrid environments. New paradigms such as serverless computing and event-driven architectures are central to that goal, allowing teams to focus on application logic rather than infrastructure provisioning and management.

CEO Cormier was direct about what differentiates Red Hat: “This is what open, hybrid cloud is.” Kubernetes-centered innovation, he argued, has created the industry’s largest hybrid cloud ecosystem and placed Red Hat at its center.

Layer 4: Multi-Cloud as the Natural Evolution

Joe Fernandes, Vice President and General Manager for Core Cloud Platforms, noted that most Red Hat customers have already adopted hybrid infrastructure or are actively moving toward it. But the journey does not stop there — customers “then tend to move to a multi-cloud strategy.”

Mike Evans, Vice President for Technical Business Development, described the current environment as an “amalgamation of hybrid cloud, multi-cloud, and cloud-to-cloud” activity — with the expectation that complexity will increase rather than decrease.

Red Hat has cultivated deep partnerships with Amazon Web Services, Microsoft Azure, Google Cloud, and parent company IBM to support this multi-cloud reality. Evans also highlighted a notable industry trend: hyperscalers are themselves beginning to offer services that run on competitors’ clouds — Google’s Anthos and Microsoft’s Azure Stack being prominent examples. In effect, the large cloud providers are building their own cross-cloud hybrid strategies, which Evans argued validates Red Hat’s long-standing multi-cloud position.

Layer 5: Edge Computing as an Extension of Hybrid Cloud

CTO Wright acknowledged that “edge” is a broad and sometimes loosely defined concept, but framed it simply: putting computing closer to users and the data they need. CEO Cormier echoed that definition.

Joe Fitzgerald, Vice President and General Manager of Red Hat’s Management Business Unit, noted that edge workloads span multiple tiers — from cloud-adjacent aggregation nodes down to devices at the network perimeter. Red Hat’s focus, he said, is on the customer’s physical premises: the servers, gateways, and other hardware that organizations place at the edge of their networks.

The telecommunications industry is a particularly important edge use case. Verizon’s 5G buildout was highlighted during Cormier’s Summit keynote as an example of the scale and complexity involved. Fitzgerald described the technical challenge: managing a vast, geographically distributed computing infrastructure with enough speed and consistency to deliver next-generation network services.

Red Hat’s response involves extending real-time capabilities into the RHEL portfolio and OpenShift, enabling policy-based, automated management of distributed edge systems from a single consistent platform. As Fitzgerald summarized: “It’s all about speed and automation.”

The Kubernetes Maturity Curve

Five years after Google open-sourced Kubernetes, Brian Gracely, Senior Director for Product Strategy for OpenShift, argued the technology is entering a third generation of enterprise use cases. The first wave required deeply technical operations teams willing to navigate immature tooling without vendor support. The second wave brought broader enterprise adoption as the tooling stabilized. The third wave — now underway — is about making Kubernetes accessible to developers who are not infrastructure specialists at all.

Clayton Coleman, a Red Hat Solutions Architect for Containerized Application Infrastructure, framed the new challenges clearly: AI, machine learning, big data, and edge computing are the next frontiers. These workloads require domain experts — data scientists, ML engineers — who need to run complex infrastructure without becoming Kubernetes administrators.

The design goal for Red Hat’s Kubernetes platform, Coleman said, is maximum empathy for administrators and developers alike: clear guardrails, automated operators, and an ecosystem that puts teams on a well-defined path to production success. “We try to make it so Kubernetes is the easiest place to build and run applications,” he said.

VMs, Containers, and the VMware Comparison

Ashesh Badani, Senior Vice President for Cloud Platforms, addressed a question Red Hat executives frequently face: how does the company’s container strategy compare to VMware’s? Badani drew several distinctions:

• Kubernetes experience: Red Hat has shipped Kubernetes-based platforms for five years with a large installed customer base; VMware’s Kubernetes efforts, Badani argued, are comparatively nascent.
• Standards alignment: Red Hat’s platform is built on a Cloud Native Computing Foundation (CNCF) standardized Kubernetes stack. Badani characterized VMware as still deciding among multiple Kubernetes stacks, some of which are proprietary.
• Hybrid cloud architecture: Red Hat’s approach uses a consistent open stack across environments; VMware’s, Badani said, incorporates proprietary infrastructure per public cloud.
• VM and container convergence: Red Hat takes a cloud-native approach via KubeVirt and OpenShift Virtualization; Badani characterized the alternative as wrapping proprietary APIs around an existing virtualization platform.
• Open-source community: Red Hat has participated in open-source communities for over two decades, Badani noted, calling that depth of community engagement a genuine differentiator.

Note: These comparisons represent Red Hat’s own characterization of the competitive landscape as presented at its Summit. VMware’s perspective is not represented here.

Developer-First Infrastructure

A consistent theme across every layer of Red Hat’s strategy is that infrastructure should be invisible to the developers who use it. Fernandes stated it plainly: “Developers should be shielded from where those applications are running.”

Red Hat’s model — build once, package as a container, deploy anywhere — enables application teams to write code without caring whether it ultimately runs on-premises, on AWS, on Azure, or on Google Cloud. Administrators handle placement decisions; developers focus on the application.

This abstraction is especially important for specialized workloads. CTO Wright described how machine learning environments typically require hardware acceleration at the OS level, with OpenShift providing the abstraction layer that makes those accelerated resources accessible to data scientists without requiring them to understand the underlying infrastructure.

Cloud Provider Partnerships and Joint Engineering

Mike Farris, Vice President for Strategy, Products and Technologies, noted that Red Hat has focused not only on maturing its technology but on deepening its cloud provider partnerships. Even though the major hyperscalers offer their own container services, Evans said they recognize OpenShift as a platform their joint enterprise customers specifically request — particularly for migrating mission-critical applications or developing cloud-native workloads.

Enterprise customers are pressing cloud providers to offer jointly managed and, in some cases, jointly engineered solutions based on OpenShift — a dynamic already visible in Azure Red Hat OpenShift, a service co-engineered and co-supported by Microsoft and Red Hat. Farris indicated that similar deeper partnerships with other cloud providers were expected to follow.

COVID-19 Impact and Customer Support Measures

Cormier noted that the pandemic had limited operational impact on Red Hat’s engineering and product development, partly because a significant portion of the company’s engineers and developers already worked remotely before the crisis. “We’re going full force on the road map and product line we planned from the beginning,” he said.

Go-to-market activities requiring direct customer engagement proved more challenging to adapt. Red Hat responded with several customer-facing measures:

• Extended product life cycles — giving customers more time before being required to upgrade, reducing upgrade pressure during an already disruptive period.
• Reduced Technical Account Management costs — cutting prices for new customers by half.
• Free training programs — offered to furloughed workers and job seekers looking to build cloud and open-source skills.

Summary: The Five Pillars of Red Hat’s Hybrid Cloud Strategy

1. RHEL as the universal foundation — operational consistency across every environment.
2. OpenShift as the cloud-era platform — Kubernetes plus VM convergence, abstracted for developers.
3. Open hybrid cloud — vendor-neutral, standards-based, bridging data center and cloud.
4. Multi-cloud by design — deep partnerships with all major hyperscalers; provider-agnostic by architecture.
5. Edge as hybrid cloud’s frontier — automated, policy-driven management of distributed infrastructure at scale.

Red Hat’s strategy depends on a coherent bet: that enterprise customers will prefer an open, consistent platform that works everywhere over any single provider’s proprietary stack. Whether the market ultimately rewards that approach will depend on execution — and on whether the open-source community continues to rally around the technologies Red Hat is building on.

What Is Docker Monitoring?

Docker is an open-source platform that uses OS-level virtualization to package and distribute applications as containers. Containers are lightweight, portable, and self-contained execution environments — but they also introduce new operational complexity. Unlike traditional virtual machines, containers are ephemeral and numerous, which makes tracking their runtime state, resource consumption, and failure modes far more challenging.

Docker monitoring encompasses the tools and practices used to collect metrics, logs, and traces from running containers and the hosts they run on. Effective monitoring ensures that containerized workloads remain performant, healthy, and available — and that problems are detected and resolved before they affect end users.

Key Metrics to Monitor in Docker Environments

• CPU usage per container: Identify containers consuming disproportionate compute resources.
• Memory usage and limits: Detect out-of-memory conditions before containers are killed.
• Network I/O: Track bytes sent and received per container to spot traffic anomalies.
• Disk I/O: Monitor read/write throughput, especially for stateful workloads.
• Container restart counts: Frequent restarts are a strong signal of instability or misconfiguration.
• Image and layer pull times: Slow image pulls can delay deployment pipelines.
• Orchestrator-level health: When running under Kubernetes or Docker Swarm, cluster-level metrics matter as much as per-container metrics.

Leading Docker Monitoring Vendors

The Docker monitoring market includes both dedicated observability platforms and broader APM (Application Performance Monitoring) solutions that have added container support. Prominent vendors in this space include:

• Datadog — Deep container and Kubernetes integration with out-of-the-box dashboards and anomaly detection.
• Dynatrace — AI-driven full-stack observability with automatic container discovery.
• New Relic — Unified observability platform covering infrastructure, APM, and logs for containerized environments.
• AppDynamics (Cisco) — Enterprise APM with container-aware topology mapping.
• Sysdig — Container-native security and monitoring built on the open-source Falco engine.
• Splunk — Log aggregation and analytics platform with strong Docker log collection support.
• Microsoft Azure Monitor — Native monitoring for containers running on Azure Kubernetes Service (AKS) and elsewhere.
• IBM Instana — Automated container performance management with continuous discovery.
• Broadcom (formerly CA Technologies) — Enterprise monitoring with container visibility.
• BMC Software — IT operations management including container environment support.
• ITRS Group — Real-time monitoring solutions targeting financial services and enterprise operations.

Open-source alternatives — such as Prometheus combined with Grafana, cAdvisor, and Loki — have also become dominant in teams that prefer self-hosted, vendor-neutral stacks.

Market Drivers

1. Preventing System Outages in Containerized Production Environments

As organizations move business-critical workloads into containers, the cost of undetected container failures rises sharply. A single unhealthy container can cascade into service degradation across an entire microservices application. This creates strong demand for proactive monitoring tooling that can alert on anomalies before they cause outages.

2. Accelerating Application Development and Testing Cycles

Containers are central to CI/CD pipelines. Monitoring tooling that integrates with build and test infrastructure enables teams to catch performance regressions early — not just in production, but during staging and testing. This shifts performance management left in the development lifecycle.

3. Rising Adoption of Multi-Cloud and Hybrid Infrastructure

Enterprises increasingly run workloads across multiple cloud providers and on-premises data centers. Docker containers are a portable unit of deployment that eases multi-cloud strategies, but they also require monitoring tools capable of providing a unified view across heterogeneous environments.

Market Trends

Container Performance Impact Remains Underquantified

Despite rapid container adoption, many organizations have not yet established clear baselines or SLOs (Service Level Objectives) for container performance. Business impact — in terms of revenue, conversion, or user experience — is rarely tied directly to container-level metrics. Vendors are beginning to address this gap by linking infrastructure telemetry to business outcomes through APM and real user monitoring integrations.

Growth of Kubernetes as the Default Orchestration Layer

Kubernetes has become the dominant container orchestration platform. Most Docker monitoring tools now treat Kubernetes as a first-class target, offering namespace-level visibility, pod health tracking, and integration with Kubernetes events and audit logs. Monitoring the orchestrator itself — not just individual containers — is now a standard expectation.

Shift Toward Unified Observability

The industry is converging on the three pillars of observability — metrics, logs, and traces — as a unified discipline rather than three separate tooling categories. Major vendors now offer platforms that correlate container metrics with distributed traces and log streams in a single interface, reducing context switching for on-call engineers.

Restraints and Challenges

Security Complexity in Container Monitoring

Monitoring agents that run inside containers or require elevated host privileges introduce their own attack surface. Container security monitoring — tracking image vulnerabilities, runtime anomalies, and network policy violations — adds further complexity. Teams must balance observability depth with the principle of least privilege.

Skills Gap

Effective container monitoring requires expertise across networking, storage, orchestration, and application performance domains simultaneously. The shortage of engineers with deep container operations experience remains a barrier to effective monitoring implementation, particularly in smaller organizations.

Tooling Sprawl and Alert Fatigue

Container environments generate orders of magnitude more telemetry data than equivalent VM-based deployments. Without thoughtful configuration, monitoring stacks quickly generate overwhelming alert volumes. Effective Docker monitoring requires deliberate signal-to-noise tuning, intelligent alerting thresholds, and anomaly-detection capabilities to remain actionable.

Deployment Models

Docker monitoring solutions are available in two primary deployment models:

• SaaS / Cloud-hosted: The vendor operates the monitoring backend. Agents or exporters run alongside containers and ship telemetry to the vendor’s platform. Examples include Datadog, New Relic, and Dynatrace SaaS. This model reduces operational overhead but involves sending potentially sensitive telemetry data off-premises.
• On-premises / Self-hosted: The entire monitoring stack runs within the organization’s own infrastructure. Prometheus, Grafana, Loki, and Thanos are common components of self-hosted stacks. This model offers full data control but requires the team to operate and scale the monitoring infrastructure itself.

Industry Verticals Driving Adoption

Docker monitoring solutions are deployed across a wide range of industries, each with distinct requirements:

• IT and Telecom: High-throughput, low-latency requirements demand fine-grained container performance visibility.
• E-commerce and Retail: Variable traffic and peak-load events make auto-scaling and performance baselining critical.
• Healthcare and Life Sciences: Compliance and data residency requirements influence both tooling selection and deployment model.
• Media and Entertainment: Streaming workloads require continuous availability monitoring and rapid incident response.
• Financial Services: Strict SLA requirements and audit trail needs drive demand for real-time, high-fidelity monitoring.

Choosing the Right Docker Monitoring Approach

When evaluating Docker monitoring tools, consider the following criteria:

• Integration depth: Does the tool natively understand Docker and Kubernetes constructs, or does it treat containers as generic hosts?
• Data retention and cardinality: High-cardinality container labels can be expensive to store; understand the cost model before committing.
• Alerting and on-call workflows: Look for PagerDuty, Opsgenie, or Slack integrations and support for escalation policies.
• Distributed tracing support: OpenTelemetry compatibility is increasingly important for vendor-neutral instrumentation.
• Security monitoring: Runtime threat detection (e.g., Falco-based rules) may be a requirement depending on your compliance posture.
• Total cost of ownership: SaaS platforms charge per host or per data volume; self-hosted stacks require engineering time to operate.

Summary

The Docker monitoring market reflects the broader maturation of container-based infrastructure. As containers move from development convenience to production necessity, the tooling supporting them has grown more capable, more integrated, and more competitively contested. DevOps teams evaluating monitoring platforms should look beyond feature lists to consider data ownership, cost at scale, and the operational burden of running the monitoring stack itself. Whether choosing a commercial SaaS platform or building on open-source foundations, the goal remains the same: actionable visibility into containerized workloads before problems reach production users.

New Relic AI: AIOps Reaches General Availability

New Relic, a leading cloud-based observability company, announced the general availability of New Relic AI, its AIOps (Artificial Intelligence for IT Operations) platform. The product is positioned as a core pillar of the broader New Relic One observability platform, extending its capabilities beyond traditional Application Performance Monitoring (APM) and infrastructure monitoring into AI-driven incident intelligence.

Background: The SignifAI Acquisition

The foundation of New Relic AI traces back to February 2019, when New Relic acquired SignifAI, a Silicon Valley-based startup headquartered in Sunnyvale, California, with additional offices in Tel Aviv. SignifAI specialized in applying AI and machine learning to IT operations — precisely the capability New Relic needed to enter the AIOps space. The acquisition allowed New Relic to integrate intelligent, ML-powered operations directly into its observability stack.

What Is New Relic AI?

New Relic AI is described as an open incident correlation and intelligence solution that is source-agnostic and data-agnostic. It integrates deeply with the New Relic One platform and is designed to help IT and DevOps teams detect anomalies, correlate incidents, and reduce the volume of noisy alerts that routinely overwhelm operations teams.

Key capabilities include:

• Anomaly detection: Evaluates telemetry data from disparate sources to surface outliers in patterns before they become critical incidents.
• Incident correlation: Automatically groups related alerts and events to reduce duplicate notifications and alert fatigue.
• Multi-signal ingestion: Ingests and analyzes alerts, logs, metrics, and deployment events from multiple data types simultaneously.
• Contextual insights: Provides an intelligent summary of each incident alongside a live view of ingested data, enabling faster diagnosis and prioritization.
• User feedback tuning: Allows operators to tune correlation rules based on feedback, improving accuracy over time.

The Role of NRDB (New Relic Database)

New Relic AI is powered by NRDB (New Relic Database), a purpose-built, distributed time-series database designed to store telemetry data — metrics, events, logs, and traces — from a wide variety of sources in a uniform format. NRDB is engineered for high-performance querying, making it well-suited for the real-time analysis that AIOps requires. Machine learning algorithms run against data stored in NRDB to identify patterns, detect anomalies, and derive context-based insights.

Reducing Alert Fatigue: What New Relic Claims

Alert fatigue is a well-documented problem in DevOps and IT operations: too many alerts, too many false positives, and too little context lead to slower incident response and missed issues. New Relic AI addresses this by correlating alerts across data sources to filter signal from noise automatically.

According to New Relic, early access customers reported seeing automatic reductions in alert noise of up to 50 percent through incident correlation. This figure is a vendor-reported claim from early access users and has not been independently verified.

Integrations: Works With Your Existing Stack

A notable differentiator for New Relic AI is its broad integration ecosystem. Rather than requiring teams to rip and replace existing tooling, the platform is designed to augment and connect with commonly used monitoring, alerting, and collaboration tools. Supported integrations at launch included:

• Monitoring & observability: Splunk, Prometheus, Grafana, Amazon CloudWatch, Google Cloud’s Stackdriver (now Google Cloud Operations Suite)
• Incident management & on-call: PagerDuty, OpsGenie, VictorOps
• IT service management: ServiceNow
• Collaboration: Slack

By integrating with both public cloud monitoring platforms and third-party tooling, New Relic AI positions itself as a correlating intelligence layer that sits above existing data sources rather than replacing them.

New Relic’s Broader Strategic Shift

New Relic began as an Application Performance Monitoring (APM) company but has progressively expanded its scope. The consolidation of APM and infrastructure monitoring into the unified New Relic One platform was a pivotal step, and New Relic AI represents the next layer — bringing machine learning and AI-driven intelligence to the data already flowing through that platform.

The company’s stated goal is to move beyond reactive monitoring toward proactive, AI-assisted operations — a requirement increasingly driven by the complexity of cloud-native, hybrid, and multi-cloud environments.

The AIOps Market Consolidation

New Relic’s move into AIOps mirrors a broader consolidation trend across the industry. Around the same period, several notable acquisitions reshaped the AIOps and observability landscape:

• Splunk acquired SignalFx
• LogicMonitor acquired Unomaly
• ServiceNow acquired Loom Systems
• VMware acquired Voyance
• New Relic acquired SignifAI

This pattern reflects an industry-wide recognition that observability data alone is not enough — operations teams need intelligent correlation and context to act quickly at scale. AIOps has emerged as the discipline that bridges raw telemetry with actionable incident intelligence.

Summary

New Relic AI’s general availability marks a significant step in New Relic’s evolution from an APM vendor to a full-stack observability and AIOps provider. For DevOps and IT operations teams managing complex, distributed systems, the platform offers a way to centralize alert correlation, reduce noise, and surface actionable insights faster — without abandoning existing monitoring tooling. As multi-cloud and cloud-native architectures continue to grow in complexity, AI-assisted operations platforms like New Relic AI are likely to become a standard part of the enterprise DevOps toolkit.

The Hybrid and Multi-Cloud Reality for Public Sector Organizations

Cloud computing has become the default platform for digital innovation, and a growing number of organizations — including government departments and public-sector bodies — are deploying some form of hybrid cloud or multi-cloud architecture. However, cloud adoption in the public sector comes with a distinct set of challenges that go beyond typical enterprise concerns.

Chief among these challenges are:

• Organizational silos that prevent cohesive IT strategy across departments
• Risk-averse institutional culture that slows adoption of new infrastructure models
• Rising IT complexity introduced by managing multiple cloud providers and on-premises environments simultaneously
• Secure application delivery requirements that must meet regulatory and compliance standards specific to government operations

These factors together create friction that can prevent public-sector organizations from realizing the full efficiency and citizen-service improvements that cloud infrastructure promises.

The Core Problem: Inconsistent Networking and Security Across Clouds

One of the most significant operational pain points in multi-cloud environments is that networking and security are implemented differently by each cloud provider. AWS, Azure, Google Cloud, and private data centers each have their own native tools, APIs, and policy frameworks. When organizations try to enforce consistent security policies across these environments, the result is often:

• Higher management overhead and operational cost
• Reduced visibility into network traffic and security events
• Increased risk of misconfiguration due to platform-specific tooling
• Slower response to threats because there is no unified control plane

For government organizations in particular — which must maintain service continuity even during emergencies — this fragmentation represents a serious risk to both security posture and operational resilience.

Breaking Down Network Silos: The Case for Consistent Policy Across Clouds

The solution discussed at the webinar centers on replacing siloed, per-cloud networking infrastructure with a unified approach that delivers consistent networking and security for applications regardless of where they run — on-premises, in a public cloud, or across multiple clouds.

Rather than managing separate firewall rules, network segments, and access policies for each environment, IT teams can benefit from:

• Global security policies that apply uniformly across virtual networks, cloud regions, and providers
• Precise micro-segmentation to control lateral movement within and between cloud environments
• Centralized visibility and control over network traffic without requiring agents or hardware at every perimeter
• Support for containerized and microservices-based workloads, which have unique east-west traffic patterns that traditional perimeter security cannot adequately address

This approach is particularly important during periods of disruption — such as a public health emergency — when IT teams must rapidly scale services or enable remote work while maintaining security guarantees.

VMware’s Approach: NSX Cloud, NSX Data Center, and Cloud Foundation

At the April 2020 webinar, Vivek Lodha, Senior Network and Security Specialist at VMware India, presented VMware’s portfolio of solutions aimed at addressing these challenges for government organizations accelerating hybrid cloud adoption.

VMware NSX Data Center

VMware NSX Data Center provides network virtualization and security for the software-defined data center. It enables IT administrators to programmatically create, snapshot, delete, and restore complex network topologies in seconds. Key capabilities relevant to public-sector use cases include micro-segmentation for zero-trust security inside the data center and policy-based automation for network provisioning.

VMware NSX Cloud

VMware NSX Cloud extends consistent networking and security policy to workloads running natively in public clouds. Instead of reconfiguring security rules each time a workload moves to a new cloud environment, NSX Cloud enforces the same policy framework across AWS and Azure (and potentially other supported clouds), reducing both complexity and the chance of policy gaps that attackers could exploit.

VMware Cloud Foundation

VMware Cloud Foundation (VCF) integrates compute, storage, networking, and cloud management into a unified hybrid cloud platform. For public-sector organizations, VCF can provide the standardized infrastructure foundation needed to run both traditional enterprise applications and modern container-based workloads with consistent operational tooling.

Why This Matters for Government IT Leaders

Government IT infrastructure must deliver citizen-centric services reliably, securely, and at scale. As Ankush Kumar, Consulting Editor at Tech Observer, highlighted during the webinar’s opening, agility in government IT is not merely a technology objective — it directly affects the quality and speed of public services delivered to citizens.

For IT leaders in the public sector, the practical takeaway is this: adopting a consistent networking and security framework is not an optional optimization. It is a prerequisite for:

• Achieving meaningful business continuity during crises
• Controlling operational expenditure as cloud footprints grow
• Meeting compliance and audit requirements across multi-cloud deployments
• Enabling development teams to adopt microservices and containers without creating ungoverned network paths

Key Takeaways

• Hybrid and multi-cloud adoption in the public sector is accelerating, but inconsistent networking and security across clouds adds cost and risk.
• Breaking down administrative network silos requires a platform that enforces consistent policy across on-premises data centers and public clouds.
• VMware NSX Data Center, NSX Cloud, and Cloud Foundation together offer a path toward unified network visibility and security for government workloads.
• Container and microservices environments require security models that go beyond traditional perimeter-based approaches.
• A consistent networking and security architecture is foundational to business continuity planning, not a post-adoption concern.

This article is based on a summary of a webinar held on April 17, 2020. For the most current VMware product capabilities and version details, refer to VMware’s official documentation.

Several management strategies have emerged to address this complexity. The most common can be grouped into three broad categories: Cloud Management Platforms (CMPs), Infrastructure as Code (IaC), and cloud-native abstraction. Each represents a different point on the spectrum between high-level abstraction and low-level, hands-on control—and each suits a different organizational profile.

1. Cloud Management Platforms (CMPs)

CMPs sit at the highest level of abstraction. Rather than interacting directly with the APIs and tooling of individual cloud providers, administrators use a single unified interface to manage resources across AWS, Azure, Google Cloud, and other providers simultaneously.

How CMPs Work

CMPs work by placing an abstraction layer on top of native cloud services. Because major public cloud offerings overlap significantly in functionality—compute instances, object storage, managed databases, identity services—a well-designed CMP can expose a common interface that hides provider-specific differences from the operator.

Security Advantages

• Unified IAM policies: A CMP allows teams to define and enforce Identity and Access Management (IAM) rules once and apply them consistently across all cloud environments, reducing the risk of policy drift.
• Centralized visibility: Security events and resource states from multiple clouds appear in a single pane of glass, making anomaly detection easier.
• Reduced operator error: Abstracting away provider-specific quirks reduces the chance that an administrator will misconfigure a resource on an unfamiliar platform.

Drawbacks

• Reduced granularity: Abstraction means that provider-specific features or fine-grained controls may not be accessible through the CMP.
• Performance overhead: Requests routed through an abstraction layer can be slower than direct cloud API calls.
• Vendor lock-in risk: Depending heavily on a CMP can create its own form of lock-in if the platform is discontinued or changes pricing.

CMPs are a strong fit for small-to-medium businesses, or any organization that needs consistent governance across a complex multi-cloud estate without the staffing to manage each cloud natively.

2. Infrastructure as Code (IaC)

IaC takes a different philosophical approach: instead of managing infrastructure through a GUI or a unified control plane, operators define their infrastructure in machine-readable configuration files and manage those files with standard software engineering practices—version control, code review, automated testing, and CI/CD pipelines.

Tools such as Terraform, Pulumi, and AWS CloudFormation are common examples. In a multi-cloud context, tools like Terraform are particularly relevant because they support multiple providers through a plugin model, enabling a single codebase to describe resources across AWS, Azure, and GCP simultaneously.

Security Advantages

• Auditability: Because infrastructure definitions live in source control, every change is tracked, reviewable, and reversible.
• Policy as code: Security policies can be encoded directly into IaC modules and enforced via tools like Open Policy Agent (OPA) or Checkov, catching misconfigurations before deployment.
• Consistency and repeatability: Environments built from the same code are identical, eliminating configuration drift between staging and production.
• Integration with SaaS security tooling: Many security vendors offer integrations that scan IaC templates for known vulnerability patterns prior to deployment.

Drawbacks

• Skill requirements: Writing reliable, idempotent IaC across multiple cloud providers demands deep knowledge of both the tooling and the underlying cloud platforms.
• Drift and state management: If someone makes a manual change to a cloud resource outside of the IaC workflow, the code and the real infrastructure diverge—a significant security risk.
• Ongoing maintenance: As cloud providers update their APIs and services, IaC modules must be kept current to remain accurate and secure.

IaC occupies a middle ground: it provides more granular control than a CMP while remaining less operationally demanding than purely cloud-native management. It is particularly powerful when embedded into a mature DevOps pipeline.

3. Cloud-Native Abstraction

The cloud-native approach means managing each cloud environment using the native tools that the cloud provider supplies—AWS CLI and CloudWatch, Azure Monitor and Azure Policy, Google Cloud Console and Cloud Logging, and so on. For container workloads, this often includes Kubernetes and its ecosystem of operators and controllers running directly on the cloud platform.

Security Advantages

• Maximum control: Native tools expose every capability and configuration option the provider offers, with no abstraction-layer limitations.
• Performance: No intermediary means faster execution of management operations and tighter integration with provider-specific security services (e.g., AWS GuardDuty, Azure Defender).
• First-mover access: New provider security features are available immediately without waiting for a CMP or IaC provider to add support.

Drawbacks

• Operational complexity: Managing IAM policies, network configurations, and security groups independently across three or more clouds is labor-intensive and error-prone.
• Skill breadth required: Teams need deep expertise in each provider’s tooling and security model simultaneously.
• No unified view: Without an aggregation layer, correlating security events across clouds requires custom tooling or a SIEM.

Cloud-native management is best suited to organizations with the engineering headcount and expertise to dedicate specialists to each cloud platform, or those whose workloads are genuinely cloud-specific and cannot benefit from abstraction.

Choosing the Right Approach

No single approach is universally correct. The right choice depends on your organization’s size, engineering maturity, cloud footprint, and risk tolerance. The table below summarizes the key trade-offs:

Practical Recommendations

• Start with your team’s skills. The best approach is one your team can operate reliably. A poorly implemented cloud-native strategy is more dangerous than a well-implemented CMP.
• Consider a hybrid. Many organizations combine IaC for provisioning with cloud-native tools for runtime monitoring and incident response. This layered model captures benefits from multiple approaches.
• Invest in policy guardrails regardless of approach. Whether you use a CMP, IaC, or native tools, encoding security policies as code and enforcing them automatically is the most reliable way to prevent misconfiguration at scale.
• Plan for drift. Any approach that involves human operators will eventually produce configuration drift. Build automated compliance scanning (e.g., AWS Config, Azure Policy, or a third-party CSPM tool) into your workflow from the start.

Is a New Approach Needed?

The three approaches described above each address the same underlying problem—the operational and security complexity of multi-cloud environments—from different angles. None is a complete solution on its own. The industry trend is moving toward converged platforms that combine the policy-enforcement capabilities of CMPs, the auditability of IaC, and the depth of cloud-native tooling into a single workflow. Cloud Security Posture Management (CSPM) tools and Cloud-Native Application Protection Platforms (CNAPPs) represent early steps in this direction.

For now, the most pragmatic path is a deliberate combination: use IaC to define and version your infrastructure, enforce security policies automatically at the code level, and layer in cloud-native monitoring for runtime visibility—with a CMP or CSPM tool providing the unified view that ties it all together.

Originally sourced from devops.com. Rewritten and expanded for technical accuracy.

What Does a Cloud Architect Actually Need to Know?

Cloud architect is one of the most in-demand roles in modern IT, but the required skill set is broad and continues to shift. The specific technologies you need will depend on your organization’s cloud stack, but a strong foundation across networking, security, software development, and communication will serve you in almost any environment. Certification programmes through platforms like edX, the Linux Foundation, and major cloud vendors can help fill gaps — both free and paid options exist.

Below are ten skills consistently cited as essential for cloud architects, drawing on input from practitioners and hiring managers in the field.

1. Network Engineering and Administration

Many cloud architects start out as network or systems administrators. According to Dan Kohn, former executive director of the Cloud Native Computing Foundation (CNCF), the most common entry path is through system administration:

“The most typical background is someone who is familiar with system administration, who knows how to provision individual servers and then moves up and begins thinking in terms of fleets of servers instead.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Hands-on experience deploying and operating different network types — including software-defined networking (SDN) — is foundational. Understanding how traffic flows, how to design resilient topologies, and how to troubleshoot at scale translates directly to cloud architecture work.

2. Containers: Kubernetes and Docker

Containers have become a core building block of modern cloud infrastructure. Docker provides the container runtime and image format, while Kubernetes has emerged as the dominant platform for orchestrating containerised workloads at scale. Proficiency in both is now close to a baseline expectation for cloud architect roles rather than a differentiator.

The CNCF maintains a landscape of cloud-native projects, and the Kubernetes.io site lists educational resources for getting up to speed. Docker’s official documentation is similarly comprehensive for learning container fundamentals.

3. Programming Languages

Cloud architects are not always expected to be full-time software developers, but being able to read, write, and debug code is critical. Widely useful languages in cloud contexts include:

• Python — dominant in automation, scripting, and infrastructure-as-code tooling
• Java — prevalent in enterprise application back-ends running on cloud infrastructure
• Go — the language in which Docker and Kubernetes are written; increasingly valued for cloud-native tooling
• C# — relevant in Microsoft Azure-heavy environments
• Perl — still present in legacy automation and operations scripting

Kohn specifically recommends familiarity with Go given how central it is to the Kubernetes ecosystem.

4. Security

Security is no longer a bolt-on concern — it is a core architectural responsibility. As regulatory requirements such as GDPR, HIPAA, and SOC 2 tighten, cloud architects are expected to design with security built in from the start, even in organisations that also employ a dedicated cloud security architect.

Key areas to develop include:

• Identity and access management (IAM) — controlling who can access what, across services and accounts
• Network security — firewalls, security groups, private networking, zero-trust models
• Data encryption — at rest and in transit
• Compliance and privacy regulations — understanding the rules that govern where and how data is stored
• Shared responsibility models — knowing what the cloud provider secures versus what you own

5. Multi-Cloud and Hybrid Cloud Architecture

Most large enterprises do not run a single cloud provider. Acquisitions, regulatory requirements, cost optimisation, and vendor risk management all push organisations toward multi-cloud or hybrid cloud strategies. Kohn makes a direct case for breadth over specialism:

“There’s a huge level of interest and demand for multi-cloud and hybrid cloud. I would really encourage people to have at least a passing familiarity with the other major clouds. And the reality is bigger enterprises tend to have acquisitions, so you wind up with a multi-cloud strategy almost by default, whether you’re planning to or not.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

While deep expertise in one platform (AWS, Azure, or Google Cloud) is valuable, architects who can reason across providers and design portable, cloud-agnostic solutions are increasingly sought after.

6. Data Storage

Data storage in cloud environments spans a wider surface than traditional on-premises storage. Cloud architects need to understand:

• Object storage (e.g., S3-compatible buckets), block storage, and file storage — and when to use each
• Capacity planning and cost optimisation for storage at scale
• Data lifecycle management, tiering, and archival
• Data security, encryption, and access control at the storage layer
• On-premises storage hardware, particularly relevant for hybrid cloud designs

7. Communication Skills

Cloud architects routinely need to explain complex infrastructure decisions to non-technical stakeholders — executives, finance teams, legal, and end users. Jim Johnson, senior VP at Robert Half Technology, puts it plainly:

“Being able to articulate to a CIO the impact [of the cloud] … communication is a key piece of that. And so to cultivate that, you need to talk to the users about what you’re providing. [You need to] check for understanding and make sure that you’re not talking over or talking under those individuals… about how well your services or your current environment are supporting them.”

Jim Johnson, Senior VP, Robert Half Technology

Practical communication skills include writing clear architecture decision records (ADRs), presenting trade-offs concisely in diagrams and documents, and running effective stakeholder meetings.

8. Teamwork and Leadership

Cloud architects frequently serve as technical leads or principal engineers on multi-disciplinary teams. The role requires the ability to:

• Facilitate technical decision-making without steamrolling contributors
• Delegate effectively and trust team members to execute
• Manage competing priorities and resolve disagreements constructively
• Mentor junior engineers and help grow the team’s overall capability

Johnson advises developing leadership skills early and deliberately, not waiting until you are in a senior role to start practising them.

9. Flexibility and Continuous Learning

Cloud technology evolves faster than most engineering disciplines. Tools, services, and best practices that were cutting-edge two years ago can become obsolete or superseded. Kohn is direct about this reality:

“The specific skill sets in need are going to evolve over time. I think there are tons and tons of opportunities in the cloud. And it is an ongoing effort. It’s not going to stay static.”

Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Building habits around staying current — following project release notes, attending community events, experimenting in personal lab environments, and earning updated certifications — is as important as any specific technical skill.

10. Business Acumen

Cloud architecture decisions have direct financial consequences. Choosing the wrong instance type, region, or storage class can meaningfully affect an organisation’s operating costs. Architects who understand how business value is created and measured can make better trade-offs and advocate more effectively for investment.

Johnson recommends supplementing technical education with formal or informal business training:

“Part of that might be a minor in business, or maybe even accounting to understand how the financials and numbers help drive businesses as well. But [it should be] anything that gives you that exposure to what it takes to drive business, create a business, and run a business, with that technology understanding.”

Jim Johnson, Senior VP, Robert Half Technology

FinOps practices — optimising cloud spend and aligning it to business outcomes — are an increasingly valued specialism that sits squarely at the intersection of cloud architecture and business acumen.

Building Your Cloud Architect Skill Set

No single engineer will be an expert in all ten of these areas simultaneously. The most effective approach is to build genuine depth in two or three domains — typically networking, a specific cloud platform, and security — while maintaining working knowledge across the rest. Pair that foundation with deliberate investment in communication and leadership skills, and you will be well positioned for a cloud architect career as the role continues to evolve.

1. Network Engineering and Administration

Most cloud architects come from a network or systems administration background. Dan Kohn described the common career path this way:

“The most typical background is someone who is familiar with system administration, who knows how to provision individual servers and then moves up and begins thinking in terms of fleets of servers instead.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Solid knowledge of deploying and operating different network types — including software-defined networking (SDN) — is fundamental. Understanding how traffic flows, how to design fault-tolerant topologies, and how to troubleshoot connectivity problems at scale gives cloud architects the grounding to make sound infrastructure decisions.

2. Kubernetes and Docker

Containers have become a standard building block of modern cloud infrastructure. Docker provides the container runtime and image format, while Kubernetes handles orchestration — scheduling, scaling, self-healing, and service discovery across clusters. Demand for Kubernetes expertise has grown sharply in recent years, making it one of the most marketable skills a cloud architect can hold.

Practical competencies to develop include:

• Writing Dockerfiles and building optimized container images
• Deploying and managing Kubernetes clusters (self-managed and managed services such as EKS, GKE, and AKS)
• Configuring Kubernetes networking, storage, RBAC, and namespaces
• Using Helm for application packaging and deployment
• Monitoring cluster health and setting up autoscaling policies

3. Programming Languages

Cloud architects do not need to be full-time software developers, but being comfortable with at least one or two languages is essential for scripting automation, reviewing infrastructure-as-code, and understanding cloud-native applications. Widely applicable languages include:

• Python — the de facto scripting language for cloud automation, SDK integration, and data pipelines
• Java — heavily used in enterprise microservices
• Go — the language in which Docker and Kubernetes themselves are written; increasingly relevant for cloud tooling
• C# — important in Azure-heavy environments
• Bash / PowerShell — essential for day-to-day automation and CI/CD pipeline scripting

Dan Kohn specifically recommends Go for architects who want to contribute to or deeply understand the Kubernetes ecosystem.

4. Cloud Security

Security has shifted from a bolt-on concern to a foundational design requirement. As data privacy regulations expand globally, cloud architects are expected to build security into every layer of the stack rather than leaving it to a separate team. Key areas include:

• Identity and Access Management (IAM) — least-privilege policies, role-based access, service accounts
• Network security — security groups, VPC design, private endpoints, zero-trust architectures
• Data encryption — at rest and in transit, key management services
• Compliance awareness — familiarity with frameworks such as GDPR, HIPAA, SOC 2, and PCI-DSS as they apply to cloud workloads
• Vulnerability management — container image scanning, dependency auditing, and patch management at scale

5. Multi-Cloud and Hybrid Cloud Architecture

While deep expertise in a single cloud platform (AWS, Azure, or GCP) is valuable, limiting yourself to one provider is increasingly a career risk. Large enterprises often end up with a multi-cloud environment not by design but by acquisition — each acquired company brings its own cloud infrastructure.

“There’s a huge level of interest and demand for multi-cloud and hybrid cloud. I would really encourage people to have at least a passing familiarity with the other major clouds. The reality with bigger enterprises is that you tend to have acquisitions, so you wind up with a multi-cloud strategy almost by default, whether you’re planning to or not.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Architects should understand how to design portable workloads, manage cross-cloud networking and identity federation, and apply governance policies consistently across providers. Tools such as Terraform, Crossplane, and cloud-agnostic monitoring solutions support this approach.

6. Data Storage and Management

Data is at the heart of cloud architecture. Architects need to match storage solutions to workload requirements — balancing cost, latency, durability, and compliance. Core knowledge areas include:

• Object storage (S3-compatible buckets), block storage, and file storage — and when to use each
• Database selection: relational, NoSQL, time-series, and data warehouse options
• Capacity planning and cost optimization (storage tiers, lifecycle policies)
• Data residency and sovereignty requirements for regulated industries
• Backup, replication, and disaster recovery strategies

For architects working with on-premises or hybrid clouds, familiarity with physical storage hardware and SAN/NAS concepts also remains relevant.

7. Communication Skills

Cloud architects routinely translate complex technical concepts for non-technical stakeholders — executives, product owners, compliance officers, and end users. Jim Johnson of Robert Half Technology emphasized why this matters:

“Being able to articulate to a CIO the impact of the cloud… communication is a key piece of that. You need to talk to the users about what you’re providing, check for understanding, and make sure that you’re not talking over or talking under those individuals about how well your services or your current environment are supporting them.”

— Jim Johnson, Senior VP, Robert Half Technology

Practical communication skills for cloud architects include writing clear architecture decision records (ADRs), presenting infrastructure proposals to leadership, and facilitating incident retrospectives across teams.

8. Teamwork and Leadership

Cloud architects rarely work alone. They coordinate with application developers, security engineers, operations teams, and business stakeholders simultaneously. Leadership responsibilities often include:

• Setting technical direction and establishing architectural standards
• Mentoring junior engineers and reviewing infrastructure designs
• Facilitating alignment between teams with competing priorities
• Managing conflict diplomatically when architectural trade-offs are contested

Jim Johnson advises candidates to cultivate leadership skills early — through team projects, open-source contributions, or community involvement — rather than waiting until a formal management role presents itself.

9. Flexibility and Continuous Learning

The cloud landscape changes faster than almost any other area of technology. New managed services, architectural patterns, and compliance requirements appear regularly. Dan Kohn put it plainly:

“The specific skill sets in need are going to evolve over time. There are tons and tons of opportunities in the cloud. And it is an ongoing effort. It’s not going to stay static.”

— Dan Kohn, former Executive Director, Cloud Native Computing Foundation

Staying current means following release notes for the cloud platforms you use, participating in community forums (CNCF Slack, cloud provider communities), pursuing relevant certifications, and experimenting with new services in sandbox environments. The ability to learn a new tool or pattern quickly is itself a core professional competency.

10. Business Acumen

Cloud architecture increasingly intersects with business strategy. Architects advise on make-vs-buy decisions, cloud cost optimization, vendor contracts, and digital transformation roadmaps. Jim Johnson recommended that engineers — especially those still in school — supplement their technical education with business coursework:

“Part of that might be a minor in business, or maybe even accounting to understand how the financials and numbers help drive businesses as well. But anything that gives you that exposure to what it takes to drive business, create a business, and run a business, with that technology understanding.”

— Jim Johnson, Senior VP, Robert Half Technology

Practical business skills for cloud architects include understanding total cost of ownership (TCO) modeling, building business cases for infrastructure investment, and communicating the financial impact of architectural choices — not just their technical merits.

Certifications and Learning Resources

Formal certification can validate your skills and accelerate hiring. Widely recognized cloud architect certifications include:

• AWS Certified Solutions Architect (Associate and Professional)
• Google Professional Cloud Architect
• Microsoft Azure Solutions Architect Expert
• Certified Kubernetes Administrator (CKA) — offered by the Linux Foundation via CNCF
• Certified Kubernetes Application Developer (CKAD)

Free and low-cost learning is available through edX, Coursera, the Linux Foundation’s training portal, and the official documentation for Kubernetes and each major cloud provider. Many certification exams include a proctored testing fee, but preparation materials are often freely available.

Putting It All Together

No single architect will be an expert in every area on day one. The practical approach is to build deep expertise in two or three areas — such as Kubernetes, security, and multi-cloud networking — while maintaining working knowledge across the rest. As your role evolves, so will the balance of skills you rely on most. The cloud architect who stays curious, communicates clearly, and understands the business impact of their technical decisions will remain in demand regardless of which specific tools dominate the market in any given year.

Original source: SDxCentral

Open Source at a Crossroads

Open source has shaped software development for decades. Foundations like the Apache Software Foundation have shepherded projects that now underpin applications used by billions of people worldwide. But as cloud computing matured and enterprise adoption deepened, the open source movement entered a period of structural tension heading into 2020. Questions around licensing, sustainability, tooling complexity, and community governance all demanded attention.

Here are four predictions — written at the close of 2019 — that capture the key forces shaping open source at that moment, along with context that remains relevant for DevOps practitioners today.

Prediction 1: The Tension Between Cloud Providers and Open Source Projects Won’t Go Away

In 2019, several high-profile open source companies — including Confluent, Elastic, and MongoDB — revised their software licenses specifically to prevent cloud providers from commercialising their projects without contributing back to the community. The moves sparked significant debate: Were these changes philosophically consistent with open source principles? Would they discourage community involvement? Would they ultimately harm or protect the projects themselves?

The practical impact of those licensing shifts was still unclear at the time of writing. Some cloud providers responded by forking older, permissively licensed versions of the software — effectively sidestepping the new restrictions while leaving the upstream project without a revenue share. Others chose to partner with open source vendors as a competitive differentiator.

The likely outcome going into 2020 was uneven: some projects would grow despite restrictive licenses because their value proposition was strong enough. Others would find that tighter licensing dampened adoption, particularly in cloud-native contexts where developers expect low-friction access to tooling. The core conflict — between the open source ethos of free use and the commercial reality of cloud monetisation — was not going to resolve itself quickly.

Why This Still Matters

The Business Source License (BSL), Server Side Public License (SSPL), and similar instruments remain contentious in the DevOps community. Engineering teams evaluating open source components should always review license terms carefully, especially when deploying on managed cloud services, to understand whether usage restrictions apply.

Prediction 2: Kubernetes Growth Would Drive Demand for Better Open Source Tooling

By the end of 2019, Kubernetes had become the de facto standard for container orchestration. Its adoption was growing rapidly, yet it consistently outpaced the broader industry’s ability to operationalise it effectively. Kubernetes is architecturally complex — managing networking, storage, scheduling, and workload lifecycle across potentially multi-cloud clusters — and integration with existing IT operations tooling was a known friction point.

The prediction was that Kubernetes Operators — software extensions that encode operational knowledge for managing stateful or complex applications — would become increasingly important. Operators allow teams to automate tasks like database provisioning, backup, failover, and scaling using Kubernetes-native patterns. Without a growing ecosystem of well-maintained Operators, running complex workloads (particularly stateful ones) on Kubernetes would remain difficult to scale reliably.

From an open source perspective, the development and sharing of Operators within communities was identified as critical infrastructure — as important as application drivers or client libraries for enabling real-world adoption.

Practical Implication for DevOps Teams

When evaluating whether a data store or messaging system is suitable for a Kubernetes-based architecture, check whether a production-grade Operator exists and is actively maintained by the upstream project or a reputable contributor. Poorly maintained Operators can introduce operational risk that negates the benefits of containerised deployment.

Prediction 3: The Commercial Role in Open Source Communities Would Become More Transparent

There is a persistent myth that open source contributions are broadly distributed across independent volunteers. In reality, the majority of meaningful contributions to most major open source projects come from developers employed by, or directly sponsored by, companies with a strategic interest in those projects. This dynamic was expected to become more visible — and more openly discussed — in 2020.

Companies like Confluent (Kafka), DataStax (Apache Cassandra), Red Hat (Linux, Kubernetes), and Canonical (Ubuntu/Linux) invest heavily in engineering, documentation, and community management for projects they depend on commercially. That investment funds the health of those projects — but it also creates questions about governance and direction.

The healthier model, as described in the original article, involves formal governance structures that separate commercial interests from community decision-making. Apache Cassandra’s introduction of the Cassandra Enhancement Process (CEP) was cited as a constructive example: it formalises how major features are proposed, discussed, and approved, ensuring that contributors from organisations like Netflix, Apple, Instagram, and Uber — not just DataStax — have a structured voice in the project’s direction.

Beyond governance, documentation was highlighted as an underinvested area where companies can meaningfully contribute. Good documentation lowers the barrier to adoption and reduces the support burden on core maintainers.

What to Look for When Evaluating an Open Source Project

• Is there a defined governance model (foundation, steering committee, or formal RFC/CEP process)?
• Are contributions coming from multiple organisations, or is the project de facto controlled by a single vendor?
• Is documentation actively maintained and versioned alongside code releases?
• Are release decisions made transparently, with public discussion and documented rationale?

Prediction 4: Microservices Architecture Would Accelerate Open Source Adoption — Including for Databases

The microservices pattern — breaking applications into small, independently deployable services — continued to grow in 2019 and was expected to accelerate further. As services became more granular and specialised, teams needed equally specialised open source components to back them: lightweight message queues, purpose-built data stores, and well-defined APIs that could be consumed without tight coupling.

An important nuance in the original prediction: while event streaming (consuming data as it flows through a system) is valuable, it is not sufficient for all use cases. Some application functions require direct, low-latency access to stored data — a role better suited to database technology than to stream processing alone. As microservices proliferated, this was expected to drive broader adoption of open source databases designed for horizontal scalability and high availability.

The underlying logic holds: when a service needs to scale independently, its data layer must scale with it. Monolithic relational databases become bottlenecks in this model, which is why distributed open source databases have grown in relevance alongside the microservices pattern.

The Bigger Picture: Open Source and Cloud Are Inseparable — But Not Without Friction

The through-line across all four predictions is that cloud computing and open source are deeply intertwined, but that relationship is not frictionless. Cloud providers benefit enormously from open source software. Open source projects benefit from cloud-scale deployment. But the commercial and governance structures required to sustain that relationship were — and continue to be — works in progress.

For DevOps engineers, the practical takeaways are straightforward: understand the licenses of the tools you depend on, evaluate whether the Kubernetes tooling ecosystem around those tools is mature, prefer projects with transparent governance, and choose components whose data models and scaling characteristics align with a microservices architecture.

Original analysis by Patrick McFadin, VP Developer Relations, DataStax. First published on IDG Connect, December 2019.

Setting the Scene: Kubernetes Takes Center Stage

As 2019 drew to a close, Kubernetes had already cemented its position as the de facto container orchestration platform for modern cloud infrastructure. Cloud and infrastructure monitoring company Datadog, in a survey of thousands of its customers, found that 45 percent were actively using Kubernetes. VMware’s announcement that it planned to transition its enterprise virtualization platform to one built around Kubernetes only reinforced this reality. IBM’s $34 billion acquisition of Red Hat — and its subsequent commitment to integrating OpenShift, Red Hat’s Kubernetes distribution, into a new multi-cloud strategy — signaled that enterprise software giants were all-in on the technology.

Against this backdrop, six senior technology leaders looked ahead to 2020 and shared their predictions across four major themes: competitive multi-cloud and hybrid cloud strategy, the limits and maturation of Kubernetes, workload repatriation, and the growing importance of unified data management.

Prediction 1: Hybrid Becomes the New Multi-Cloud

Lee James, CTO EMEA, Rackspace

Despite the undisputed growth of multi-cloud adoption, James argued that many enterprises were simultaneously maintaining investment in private cloud infrastructure — driven by security requirements, existing data center leasing arrangements, or because on-premises simply performed better for specific workloads. He noted that even the UK Government was revisiting its “cloud first” policy in favor of a “cloud right” approach, acknowledging that public cloud is not universally the correct answer.

The major hyperscalers had already responded to this reality. Azure Arc, Google Cloud Anthos, and AWS Outposts were all designed to extend public cloud capabilities into private data centers — blurring the line between public and private infrastructure.

James predicted that 2020 would see intense competition between the three largest cloud providers — AWS, Microsoft Azure, and Google Cloud — along with VMware, as they each worked to position Kubernetes as the key to unlocking hybrid and multi-cloud for enterprise customers. For end users, the decision would ultimately come down to which platform delivered the best fit and the best value.

Prediction 2: Kubernetes Matures — and Its Limits Become Clearer

Stephan Fabel, Director of Product, Canonical

Fabel offered a more nuanced view. While Kubernetes had become integral to modern cloud infrastructure and many organizations were doubling down on it — restructuring DevOps teams around it, experimenting with serverless workloads, and automating data orchestration — he cautioned that a more critical perspective was emerging.

As Kubernetes moved from experimental deployments into production at scale, teams were increasingly encountering real operational challenges: security vulnerabilities, unplanned downtime, and the specialist skills required to manage clusters effectively. Fabel predicted that 2020 would see some organizations question whether Kubernetes was the right tool for every workload, and that the community would mature accordingly — either bringing in specialist vendors or being more selective about where Kubernetes was applied.

Fabel also addressed cloud repatriation — the trend of moving workloads back from public cloud to on-premises infrastructure. He argued this would not represent a wholesale retreat from the cloud, but rather a deliberate hybrid strategy. As organizations scaled, the economics of public cloud became harder to justify for stable, predictable workloads, making on-premises infrastructure more cost-effective. Public cloud providers, he predicted, would respond by reaching deeper into customer data centers to capture this hybrid demand.

Prediction 3: Organizations Need a Single, Standard Kubernetes Strategy

Michael Cote, Director of Marketing, Pivotal

With Kubernetes already the leading platform for containerized and cloud-native applications, Cote argued that the next challenge for enterprises was not adoption, but standardization. Organizations running multiple parallel Kubernetes initiatives — different teams using different distributions or managed services — would waste resources and slow down their broader cloud-native strategy.

His prescription was pragmatic:

1. Choose a Kubernetes distribution or managed service and commit to it as the organizational standard.
2. Identify a small set of high-value applications to migrate first.
3. Run a genuine Proof of Concept (PoC) — deploying real applications, not just test workloads — to validate the platform choice across the full development-to-production lifecycle.
4. Evaluate results honestly: if the PoC succeeds, expand adoption; if it fails, diagnose the cause and iterate — potentially with a different platform.

Cote predicted that the bulk of the work in 2020 would be application modernization: identifying legacy workloads that could realistically be migrated to the chosen Kubernetes platform and executing those migrations in a structured, measured way.

Prediction 4: Every Application Will Become Mission-Critical

Dave Russell, VP of Enterprise Strategy, Veeam

Russell’s prediction focused on the changing nature of application availability expectations. As businesses become wholly dependent on digital infrastructure, the traditional distinction between mission-critical and non-mission-critical applications becomes increasingly difficult to maintain. The 2019 Veeam Cloud Data Management Report indicated that IT decision-makers said their organizations could tolerate a maximum of two hours of downtime for mission-critical applications — but Russell argued that in practice, almost no application can afford to be unavailable for that long.

He predicted that Infrastructure as Code (IaC) would continue to move into mainstream adoption, enabling organizations to define infrastructure declaratively and deploy it consistently across multiple storage environments and locations — reducing both provisioning time and human error. Software-defined approaches, including IaC and cloud-native architectures, were presented not just as cost-saving measures but as essential tools for delivering the agility and scalability that always-on applications demand.

Prediction 5: Companies Will Step Back from All-In Cloud Strategies

Patrick O’Keeffe, VP of Development Engineering, Quest

O’Keeffe described a recognizable pattern playing out in many enterprises: lift and shift infrastructure VMs to the cloud, discover that costs have increased rather than decreased, move some workloads back to on-premises, and then selectively build new applications using cloud-native PaaS and DBaaS services with more favorable cost profiles.

After a year of aggressive cloud migration, he predicted that 2020 would be a year of re-evaluation. Organizations that had committed fully to a single cloud provider would reconsider that approach after experiencing high costs and reduced flexibility. The likely outcome was a move toward either multi-cloud or hybrid cloud:

• Hybrid cloud allows organizations to run some workloads on a public cloud provider (AWS, Azure, or GCP) while keeping sensitive or mission-critical data on-premises.
• Multi-cloud gives individual teams or business units the flexibility to use the cloud service best suited to their specific needs, rather than being locked into a single vendor.

Prediction 6: Customers Will Demand Unified Management Layers Across Clouds

Gijsbert Janssen van Doorn, Technology Evangelist, Zerto

Janssen van Doorn’s prediction was focused on operational visibility. While hybrid and multi-cloud adoption was already underway, he argued that 2020 would mark a shift in what customers demanded from those environments: not just the underlying infrastructure, but a unified management layer sitting above it.

Many organizations had already deployed backup-in-the-cloud and Disaster Recovery as a Service (DRaaS) solutions, but these often operated in silos. What they now needed was a single pane of glass providing visibility into cost across all cloud environments, knowledge of where data resided at any given time, confirmation that workloads were protected, and the ability to move workloads between clouds as requirements changed.

Key Themes Across All Predictions

Looking across all six predictions, several consistent themes emerge that were relevant both heading into 2020 and continue to shape cloud strategy today:

• Kubernetes consolidation: The platform had won the container orchestration wars, but the next challenge was standardizing on a single organizational approach rather than allowing fragmented adoption.
• Hybrid and multi-cloud as the default: Pure public cloud strategies were giving way to more nuanced approaches that combined public cloud, private infrastructure, and managed services based on workload requirements.
• The maturation of cloud economics: Organizations were becoming more sophisticated about understanding when cloud made financial sense and when on-premises or hybrid architectures delivered better value.
• Software-defined operations: IaC, cloud-native architectures, and unified management platforms were all seen as essential for operating at the scale and availability that modern applications demand.
• Data visibility and protection: As infrastructure spread across multiple clouds and on-premises environments, knowing where data lived and ensuring it was protected became a central operational concern.

These predictions, made at the close of 2019, reflect a cloud industry that was moving rapidly from early experimentation to enterprise-scale production deployment — and grappling with the operational, financial, and organizational complexity that comes with it.

As APIs have grown in popularity, however, they have also become a prime target for attackers. The fundamental problem is that nearly every business now operates online with APIs that exist both inside and outside the corporate firewall. The traditional model of placing a secure perimeter around IT assets no longer holds. Security strategy must evolve to match the reality of distributed, multi-cloud architectures.

Enterprises should think of each API as a potential point of business leverage — and a possible point of vulnerability.

The following five techniques help organizations use modern, API-based development to fuel their businesses while maintaining a strong security posture across every point of interaction.

1. Balance Protection with Ease of Access

The most restrictive security policy — locking everything down — is also the least useful. APIs exist to provide access to valuable information and functionality: customer data, inventory systems, payment services, and legacy applications. Each API is therefore an access point that must be secured without becoming a bottleneck for the developers who build on top of it.

Heavy-handed policies and overly restrictive access controls slow down innovation. The practical solution is an API management platform that mediates access to APIs, monitors their usage, and automates developer onboarding, authentication, and education.

A common mistake is applying security controls to only a subset of APIs — perhaps those intended for external partners — while leaving internal or bespoke APIs unmanaged. This is the equivalent of locking the windows while leaving the front door open. Regardless of whether an API is public, partner-facing, or internal, every API should be managed and secured.

2. Authenticate the Right Actors

Properly secured APIs must authenticate both end users and the applications calling them. OAuth is the widely adopted open standard for API authentication and authorization. It enables token-based access, allowing clients to exchange credentials for a scoped token rather than exposing a password directly. The token grants access to a protected resource at a defined permission level, without revealing the user’s sign-in credentials.

Key advantages of OAuth tokens over passwords include:

• Unique identification: A token uniquely identifies a single application or user on a single device.
• Scoped access: Tokens carry a scope that limits what the application can do on behalf of a user, reducing the blast radius of a compromised token.
• Configurable lifetime: Token expiry can be set to a short window, reducing exposure if a token is stolen.

Beyond OAuth, API teams should also consider role-based access control (RBAC), which assigns different levels of API access and privileges based on predefined user roles. Staying current with OAuth best practices and emerging standards (such as OAuth 2.1) is essential for maintaining a strong authentication posture.

3. Maintain Control with Effective Traffic Management

Any publicly reachable API is a potential target for brute-force attacks or volumetric abuse. Attackers may use automated tools to hammer an API with authentication attempts or flood back-end systems with traffic far exceeding normal throughput. For successful digital enterprises, such attacks are often unavoidable — they are, in effect, the cost of doing business online.

Rate limiting and quota enforcement are the primary defenses here. API management platforms that support these features allow teams to:

• Set per-second rate limits (for example, no more than 500 calls per second from a single source) to trigger spike arrests before back-end systems are overwhelmed.
• Enforce daily or monthly quotas per application or API key to prevent abuse of tiered access plans.
• Automatically block or throttle traffic from sources that exceed defined thresholds.

These controls protect both the API infrastructure and end-user experience during unexpected traffic spikes, whether caused by malicious actors or sudden legitimate demand.

4. Generate Insights via Analytics and Monitoring

In a multi-cloud environment, digital assets are distributed across different geographies, public and private clouds, and third-party API providers. Effective API security depends on unified visibility across this entire landscape — not just within a single data center or region.

Strong analytics and monitoring capabilities serve several functions:

• At-a-glance dashboards that surface anomalies in API traffic without requiring manual log analysis.
• Trend analysis across configurable time windows (daily, weekly, monthly) to distinguish normal variance from potential incidents.
• Drill-down reporting for per-API and per-proxy policy configuration data, helping teams audit what rules are applied where.
• Change management tracking to document governance decisions and support post-incident reviews.

Effective monitoring also improves collaboration between security and operations teams. If reporting tools clearly indicate whether a situation requires a security response or an operational fix, teams can escalate appropriately and resolve incidents faster.

5. Don’t Forget the Basics

Automated tooling and platform features are only part of a sound security program. Disciplined engineering practices remain essential:

• Code and security reviews: Regular reviews increase the likelihood of catching vulnerabilities before they reach production. They also help ensure that a defect found in one part of an API program is documented and not repeated elsewhere.
• Vulnerability disclosure channels: Many real-world security issues are discovered by developers and power users who interact with APIs regularly. Establishing a clear, accessible channel for users to report issues — and a process for triaging, fixing, and confirming resolution — converts potential adversaries into collaborators.
• Patch management: Dependencies used by API back ends (frameworks, libraries, runtimes) should be tracked and updated promptly when security patches are released.

Moving Forward: Security at Every Point of Interaction

Network perimeters no longer contain all the experiences and interactions that drive modern business. APIs cross those boundaries constantly — connecting cloud services, mobile applications, third-party data sources, and internal systems in real time. A security strategy built around a single perimeter will always have gaps.

By treating every API as both a business asset and a potential vulnerability, and applying the five techniques above — access management, strong authentication, traffic controls, unified monitoring, and engineering discipline — organizations can build a security posture that is better suited to the multi-cloud reality than the old firewall model ever was.

This article is based on guidance originally published on Forbes.com. No specific proprietary benchmarks or performance statistics have been added.

As organizations deepen their cloud-first strategies, optimizing cloud architecture has moved to the top of the IT agenda. A growing share of infrastructure spending now goes toward cloud computing, and most enterprises are not relying on a single provider. Using multiple cloud providers and services demands an architecture that supports workflow portability — and a genuinely unbiased, multi-cloud strategy to make that portability real.

What Is Multi-Cloud?

Multi-cloud is the practice of using two or more cloud providers to meet different technical or business requirements within a single organization. At its core, multi-cloud is enabled by cloud-native applications built from containers that can consume services from different providers, all managed within one overarching architecture.

It is worth distinguishing between simply using multiple cloud providers and genuinely operating in a multi-cloud way. An organization might have workloads scattered across AWS, Azure, and GCP for historical reasons without having the workflow portability that true multi-cloud requires. Vendor lock-in — where switching providers becomes prohibitively expensive or technically complex — remains a real risk even for organizations that think they have diversified.

Key Reasons Organizations Adopt Multi-Cloud

• Greater flexibility: Each cloud provider has strengths and weaknesses. Multi-cloud lets teams choose the best service for each workload rather than accepting whatever a single vendor offers.
• Better support for acquisitions: When companies merge or are acquired, their existing systems may sit on different cloud platforms. A multi-cloud architecture lets both sides continue operating without a forced migration.
• Increased resilience: Designing failover across multiple providers reduces the blast radius of a single provider outage.
• Stronger negotiating leverage: When DevOps processes are not tied to vendor-specific services, teams can negotiate better pricing or credits because switching costs are lower.
• Fewer conflicts of interest: Large cloud providers offer an expanding catalog of services that can compete with their own customers. Using multiple vendors limits exposure to those conflicts.

Can Cloud Providers Really Support Multi-Cloud?

Most major cloud service providers (CSPs) publicly endorse multi-cloud, but their business model creates an inherent tension. Cloud computing is largely pay-per-use: the more services a customer consumes from a single provider, the more revenue that provider earns and the harder it becomes to migrate those workloads elsewhere.

AWS, GCP, and Azure each offer dozens to hundreds of distinct services — many of which are deeply integrated with each other within that provider’s ecosystem. The broader and deeper a team’s adoption of any single provider’s managed services, the greater the switching cost. Proprietary data formats, provider-specific APIs, and tightly coupled managed services all work against workflow portability.

This does not mean CSPs are acting in bad faith when they discuss multi-cloud support, but DevOps teams should assess independently whether a given tool or service is genuinely cloud-agnostic or whether it creates new dependencies on a particular provider’s infrastructure.

Implementing CI/CD in a Multi-Cloud Context

CI/CD pipelines are a central component of multi-cloud delivery. If an organization wants to build once and deploy to any target environment — whether that is AWS EKS, Google GKE, Azure AKS, or an on-premises Kubernetes cluster — the CI/CD toolchain must be able to orchestrate those deployments without being tied to a specific provider’s runtime or API.

The RightScale 2019 State of the Cloud Report cited implementing CI/CD in the cloud as one of the top cloud initiatives among respondents. This reflects a broader recognition that delivery pipelines are infrastructure — and that infrastructure must be as portable as the applications it deploys.

GitHub Actions and GitLab CI/CD: A Multi-Cloud Comparison

GitHub announced Actions with CI-like functionality in 2018, bringing integrated pipelines into GitHub’s source code management platform. In June 2018, Microsoft acquired GitHub — a move that underscored the strategic value of developer tooling as a channel for cloud adoption. With millions of developers already using GitHub for source control, the platform became a natural on-ramp for Azure workloads.

That is not necessarily a problem for teams already committed to Azure, but it introduces a consideration for organizations pursuing a cloud-agnostic strategy. GitHub Actions can deploy to any cloud, but the commercial relationship between GitHub and Microsoft means there is an inherent gravitational pull toward Azure integrations and marketplace offerings.

GitLab, by contrast, is not owned by a cloud provider. When a team uses GitLab CI/CD, GitLab does not have a financial incentive to favor one deployment target over another. GitLab pipelines can build, test, and deploy to AWS, GCP, Azure, or any other target that a runner can reach. Governance features — security scanning, compliance frameworks, audit logs — apply consistently regardless of where the workload ultimately runs.

“Choosing a cloud provider should depend on the company’s business objectives, it should not be constrained by technology, and GitLab wants to enable every one of our customers to have this freedom.”

Sid Sijbrandtij, co-founder and CEO, GitLab

Practical Implications for DevOps Teams

When evaluating CI/CD tooling for a multi-cloud environment, consider the following questions:

• Does the CI/CD platform require a specific cloud runtime? Some managed CI services run exclusively on a single provider’s infrastructure, which can introduce latency, cost, or compliance issues for workloads on other clouds.
• Are pipeline definitions portable? YAML-based pipeline definitions stored in the repository alongside application code are easier to migrate than pipelines configured through a proprietary UI or API.
• Does the vendor have a commercial relationship with a specific CSP? That relationship may shape roadmap priorities in ways that disadvantage teams on other clouds.
• Can runners or agents be self-hosted on any infrastructure? Self-hosted runners give teams control over where build jobs execute, which is important for compliance, performance, and cost management across clouds.
• Are security and governance policies enforced consistently? In a multi-cloud environment, consistent policy enforcement across all deployment targets is as important as the deployment itself.

Multi-Cloud Should Mean Any Cloud

A multi-cloud strategy is only as strong as its weakest dependency. If the CI/CD layer reintroduces a single-provider dependency, the organization has not truly achieved workflow portability — it has just moved the lock-in point upstream.

Cloud-agnostic CI/CD tooling — where pipelines are defined as code, runners can execute on any infrastructure, and the vendor has no stake in which cloud you choose — is a practical enabler of genuine multi-cloud operations. As cloud strategies mature, the ability to build, test, and deploy to any target environment without rewriting pipelines or renegotiating tool contracts will become a meaningful competitive advantage.

Setting the Stage for re:Invent 2019

AWS re:Invent has become the cloud industry’s most anticipated annual event, consistently delivering a wave of new product launches, feature updates, and strategic announcements. Heading into re:Invent 2019, the cloud computing community had every reason to expect another heavy slate of announcements.

The 2018 edition delivered notable releases including Amazon Managed Blockchain, AWS Transit Gateway, and further expansions to EC2 instance types. AWS also surprised the industry with the disclosure of AWS Ground Station, a managed ground station service for satellite communications — a product that few analysts had anticipated.

With 2019’s show on the horizon, several experienced cloud practitioners shared their predictions across four key themes: enterprise-grade managed services, AI and machine learning, multi-cloud support, and security.

Enterprise Services and Custom Hardware — Kurt Marko, Consultant

Kurt Marko predicted that AWS would continue its push toward enterprise adoption, building on the hybrid infrastructure work started in 2018 with VMware on AWS and the AWS Outposts announcement. He anticipated further expansions in managed database services, with the possibility of deeper partnerships targeting ERP and CRM workloads to compete with platforms like Salesforce and Microsoft Dynamics 365.

On the AI and machine learning front, Marko expected new services and improvements to existing frameworks such as TensorFlow and MXNet. He specifically called out potential enhancements to AWS Deep Learning Containers, possibly with tighter integrations for AWS Fargate and AWS Lambda — moves that would simplify the deployment of containerized machine learning workloads alongside other AWS services.

Marko also highlighted AWS’s track record in custom silicon, pointing to the Graviton processor, AWS Inferentia (the ML inference chip), and the Nitro system. While he did not expect an entirely new processor architecture, he anticipated meaningful performance improvements to both the ARM-based and machine learning-focused chips — with stronger capabilities for higher-end compute workloads.

Multi-Cloud Support as a Competitive Necessity — David Linthicum, Cloud Analyst

David Linthicum made the boldest prediction of the group: that AWS would make a significant move toward embracing multi-cloud as part of its 2019 announcements. His reasoning was grounded in market reality — enterprise customers increasingly operate across more than one public cloud provider, and they tend to favor vendors that make cross-cloud interoperability easier.

Linthicum pointed to Google’s launch of Anthos earlier in 2019 as a clear signal that multi-cloud was becoming a mainstream expectation rather than an edge-case requirement. He argued that AWS, despite its dominant market position, could not afford to ignore a shift that its major competitors were actively promoting.

Security by Default — George Lawton, IT Writer

George Lawton focused his predictions on security, arguing that AWS would use re:Invent 2019 to announce significant security enhancements aimed at enterprise customers. His rationale was straightforward: the majority of cloud security incidents in recent years have not been caused by AWS platform vulnerabilities, but by customer misconfigurations of AWS tools and services.

Lawton noted that this issue had reached the level of political attention, with U.S. Senator Ron Wyden among those raising questions about whether cloud providers had done enough to protect customers from misconfiguration risks. While Lawton did not expect AWS to directly acknowledge political pressure, he anticipated announcements around security by default configurations and improved security scanning capabilities — both of which would reduce the likelihood of accidental data exposure.

AI Dominance and Marketing Momentum — Brian Kirsch, IT Architect

IT architect Brian Kirsch brought a market dynamics perspective to his predictions. Writing in the context of Microsoft’s JEDI contract win — one of the largest government cloud contracts ever awarded — Kirsch expected AWS to use re:Invent as an opportunity to assert its continued leadership as the largest cloud vendor and to showcase the breadth of its platform.

Like Marko, Kirsch predicted that machine learning and AI would dominate the session catalog, the show floor, and attendee conversations. He was candid about the practical reality, however: the proportion of enterprises that have mature AI use cases and the budget to deploy AWS’s more advanced ML services remains relatively small. Nevertheless, he anticipated that AI would receive outsized attention relative to its current enterprise adoption rate.

Key Themes to Watch

• AI and Machine Learning: New managed services, framework improvements, and deeper integrations with serverless and container platforms.
• Custom Silicon: Incremental improvements to Graviton and Inferentia chips for higher-performance workloads.
• Multi-Cloud: Potential announcements signaling AWS openness to heterogeneous cloud environments.
• Security: Hardened defaults and improved scanning tools to reduce misconfiguration risk.
• Enterprise Services: Managed services targeting ERP, CRM, and SAP workloads, alongside continued VMware and Outposts development.

Whether AWS delivered curveballs as unexpected as AWS Ground Station in 2018 remained to be seen — but the consensus among analysts was clear: re:Invent 2019 would be another landmark event for the cloud industry.

Kubernetes Takes Center Stage at VMworld 2019

If there was one clear signal coming out of VMware’s annual user conference, VMworld 2019, it was that Kubernetes had moved from an adjacent technology to the front and center of VMware’s entire product strategy. Executives across the company consistently emphasized that engineering teams were fully embracing the open-source container orchestration platform as the foundation for the next generation of vSphere.

This shift is significant. VMware built its business on virtualization and the vSphere platform, which underpins a massive share of enterprise data center infrastructure. Integrating Kubernetes natively into that platform rather than bolting it on as an afterthought represents a meaningful architectural commitment — and one with long-term implications for both infrastructure operators and application developers.

Project Pacific: Kubernetes Embedded into the Core of vSphere

Project Pacific is VMware’s initiative to embed Kubernetes directly into the vSphere hypervisor layer — not alongside it, but within it. The goal is to bridge the operational gap between traditional VM-based infrastructure and modern container-based workloads running on Kubernetes.

The key design principle of Project Pacific is that it serves two audiences simultaneously without forcing either to change their existing workflows:

• Developers interact with the stack through the Kubernetes API, using familiar kubectl commands, YAML manifests, and Kubernetes-native tooling. From their perspective, they are deploying to a Kubernetes cluster.
• IT Operations teams continue to manage the environment through vCenter and the vSphere interface they already know. From their perspective, workloads remain manageable as vSphere constructs.

This dual-interface approach is architecturally clever. It avoids the common enterprise dilemma of forcing a wholesale platform migration in order to adopt containers. Instead, existing vSphere investments remain valid while the platform gains Kubernetes-native capabilities.

Beyond the immediate operational benefits, embedding Kubernetes into vSphere’s core extends the platform’s strategic relevance significantly. It gives VMware’s ISV ecosystem and technology partners a well-defined integration point for container-aware products and services.

VMware Tanzu: A Brand for the Container Product Portfolio

Alongside Project Pacific, VMware announced Tanzu as an umbrella brand for its growing portfolio of container and Kubernetes-related products. Rather than a single product, Tanzu is a product family — a way of organizing and marketing VMware’s cloud-native offerings under a coherent identity.

Tanzu Mission Control

The first product shipped under the Tanzu brand is Tanzu Mission Control, a centralized management plane designed to provide visibility and governance across multiple Kubernetes clusters regardless of where they run — on-premises data centers or public cloud environments.

The long-term ambition for Tanzu Mission Control is to manage clusters across a broad range of environments, including:

• Clusters running inside Project Pacific on-premises
• Amazon Elastic Kubernetes Service (EKS)
• Google Kubernetes Engine (GKE)
• Azure Kubernetes Service (AKS)
• IBM Kubernetes Service

This positions Tanzu Mission Control as VMware’s answer to the multi-cluster, multi-cloud Kubernetes management problem — a challenge that becomes increasingly acute as enterprises run Kubernetes across multiple providers and environments.

The Pivotal Acquisition and PKS Consolidation

The Tanzu umbrella also brings potential clarity to the naming confusion that existed around Pivotal Kubernetes Service (PKS). With Pivotal becoming part of VMware, rebranding PKS offerings under the Tanzu name — as Tanzu Kubernetes Service — would consolidate the Essential PKS and Enterprise PKS product lines under a single, more coherent brand. This kind of rationalization typically reduces confusion for enterprise buyers evaluating VMware’s Kubernetes offerings.

How Project Pacific and Tanzu Fit Together

The two announcements serve distinct but complementary strategic purposes:

• Project Pacific addresses VMware’s cloud-native strategy by modernizing the core vSphere platform, making it Kubernetes-aware from the ground up.
• Tanzu addresses VMware’s multi-cloud ambitions by providing a management layer that spans Kubernetes deployments across on-premises infrastructure and multiple public clouds.

Both rely on Kubernetes as the common operational fabric — specifically its extensibility model, which allows the Kubernetes API to be extended with custom resource definitions (CRDs) and operators. This extensibility is what makes it practical for VMware to embed Kubernetes into vSphere and simultaneously build a centralized control plane on top of it.

VMware’s History of Platform Integration Strategies

This is not the first time VMware has responded to a major infrastructure trend by integrating the new technology directly into its existing platform rather than building a separate product line. There is a recognizable pattern:

• OpenStack: As OpenStack gained momentum in enterprise data centers, VMware released vSphere Integrated OpenStack, enabling side-by-side deployment and management of vCenter alongside an OpenStack control plane.
• Containers (early wave): When Docker containers began gaining traction, VMware announced vSphere Integrated Containers, allowing containers to run inside VMs on vSphere, alongside Photon OS — a lightweight, open-source Linux distribution optimized for running containers.
• Kubernetes (current wave): Project Pacific and Tanzu represent the same integration instinct applied to Kubernetes orchestration — embed it deeply, manage it centrally, and extend the platform’s life cycle in the process.

Whether this Kubernetes-first approach proves more durable than the OpenStack integration strategy remains to be seen. However, the depth of the Project Pacific integration — Kubernetes embedded into the hypervisor kernel rather than layered above it — suggests a more foundational commitment than previous efforts.

What This Means for DevOps and Infrastructure Teams

For DevOps practitioners and platform engineers working in VMware-heavy environments, these announcements have practical implications:

• Kubernetes skills become directly applicable to vSphere environments. Teams no longer need to maintain entirely separate skill sets for VM management and container orchestration when running on Project Pacific.
• Multi-cluster governance becomes a first-class problem VMware is solving. Tanzu Mission Control is worth evaluating for organizations running Kubernetes clusters across multiple environments without a unified management story.
• The vSphere platform is not going away. For enterprises with significant vSphere investments, Project Pacific represents a path to adopting cloud-native patterns without a forklift migration off the existing hypervisor infrastructure.
• The Kubernetes API becomes the integration surface. Partners and tooling vendors building on top of VMware infrastructure will increasingly target the Kubernetes API rather than proprietary VMware APIs.

VMware’s move to make Kubernetes the architectural backbone of vSphere is one of the more consequential platform decisions in enterprise infrastructure in recent years. The success of this strategy will depend on execution — particularly on how well the dual-interface model (Kubernetes for developers, vSphere for ops) holds up under the real-world complexity of enterprise environments.