The Cloud Market Keeps Growing — and Startups Are Leading the Charge

Even as the COVID-19 pandemic disrupted large portions of the global economy in 2020, the cloud computing market showed remarkable resilience. Gartner forecast the public cloud market would grow 6.4% in 2020 to reach $242.7 billion, with Software as a Service (SaaS) accounting for roughly $104.7 billion of that total. A separate 2020 InformationWeek/Interop survey found that IT leaders estimated 42% of their cloud-related budgets were directed at SaaS initiatives.

Flexera’s 2020 State of the Cloud Report reinforced how pervasive cloud adoption had become: 96% of surveyed organisations were using public cloud services, and 76% had a private cloud environment in place. Cloud computing was no longer an emerging option — it had become the default operating model for enterprises and small businesses alike.

Why Cloud-Native Startups Matter

As cloud infrastructure matured, it created fertile ground for a new generation of companies built entirely around cloud primitives. These cloud-native startups did not need to migrate legacy systems or maintain on-premises hardware — they could design their products from the ground up for elasticity, distributed architecture, and pay-as-you-go economics.

This structural advantage allowed them to challenge established vendors in categories such as backup and recovery, enterprise networking, security, and relational databases — often delivering the same capabilities at lower cost and with greater agility. Investors took notice: many of the most prominent cloud-native startups raised hundreds of millions of dollars in venture funding.

Selection Criteria

InformationWeek compiled its list of ten notable cloud startups using the following criteria:

• Founded in 2015 or later — ensuring the companies were genuinely cloud-era businesses rather than incumbents that had adopted cloud features.
• Cloud-related product or service — each company had to offer something directly tied to cloud infrastructure, platforms, or applications.
• Significant funding — the candidate pool was drawn from the highest-funded cloud startups tracked by Crunchbase at the time of publication.
• Ranked by total funding received — companies are listed in descending order of capital raised, not by subjective merit.

Key Technology Themes Among These Startups

While each company on the list has its own focus area, several common themes emerge across the group:

Cloud Meets IoT and Edge Computing

Several startups combine cloud-native architectures with Internet of Things (IoT) and edge computing capabilities. Rather than processing all data in a central cloud region, these platforms push computation closer to where data is generated — reducing latency and bandwidth costs while still leveraging cloud-scale management and analytics.

Reinventing Traditional IT with Cloud Economics

Other companies on the list take familiar IT disciplines — backup and disaster recovery, enterprise networking, identity and access management, and relational databases — and rebuild them as cloud-native services. The result is typically a consumption-based pricing model, automated operations, and integrations with major cloud providers such as AWS, Microsoft Azure, and Google Cloud.

Robotics and Automation

Some startups extend the cloud’s reach into physical operations, using cloud-connected robotics and automation platforms to bring software-defined control to warehouses, manufacturing floors, and logistics networks.

What This Means for DevOps and Platform Teams

For DevOps engineers and platform architects, the growth of cloud-native startups has practical implications:

• More specialised tooling: As startups target narrow problem spaces, teams gain access to purpose-built tools rather than trying to adapt general-purpose platforms.
• Vendor consolidation risk: Many well-funded startups are acquisition targets. Evaluate long-term vendor viability before standardising on a startup’s platform.
• Integration complexity: Cloud-native tools often assume a multi-cloud or hybrid environment. Review integration support for your specific stack before committing.
• Pricing model shifts: Consumption-based pricing can reduce upfront costs but introduces budget unpredictability. Implement cloud cost monitoring from day one.

Where to Learn More

The original InformationWeek slideshow, authored by Cynthia Harvey, provides individual profiles of each company including their founding story, core product, and funding history. For the most current funding data, consult Crunchbase directly, as startup valuations and funding rounds change frequently. Flexera publishes an annual State of the Cloud Report that tracks enterprise cloud adoption trends and is worth reviewing each year as a benchmark for your own organisation’s cloud maturity.

Original reporting by Cynthia Harvey for InformationWeek. Data points sourced from Gartner, Flexera, and a 2020 InformationWeek/Interop survey.

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.

The Core Problem: Fixed-Size Boxes (Virtual Machines)

Imagine you are packing a suitcase after a shopping trip. Every item you bought is still inside its original store box — rigid, fixed in size, with plenty of empty space inside each one. You cannot rearrange the contents because everything is sealed in its own box. As a result, you need two suitcases to carry everything home, at a total cost of $200, when all the actual clothing would have fitted in one suitcase ($100) if you had unpacked the boxes and filled every nook and cranny.

Those fixed-size boxes are virtual machines. Every VM carries significant overhead in the form of a full guest operating system — kernel, system libraries, daemons — that consumes CPU and memory before your application even starts. Because VMs are sized to handle peak load (spikes), their average utilisation is often very low. You are paying for space inside boxes that is mostly empty.

Containers: Unpacking the Boxes

A container is the equivalent of removing the clothes from the store boxes and packing them directly into the suitcase. Containers share the host operating system kernel; they do not each carry their own OS. This removes most of the overhead and allows you to pack far more workloads onto the same underlying server or VM.

The key insight is that an application built and run as containers should cost less than the equivalent VM-based deployment — provided those containers are scheduled efficiently onto the available infrastructure. That scheduling problem is exactly what Kubernetes solves.

How Kubernetes Bin-Packing Works

Kubernetes treats each containerised application as a Pod — the smallest deployable unit. When you submit a Pod to the cluster, the Kubernetes scheduler inspects each worker node’s available CPU and memory and places the Pod on the node that best fits its resource requests. This process is called bin packing: filling available capacity as tightly as possible, just like squeezing clothes into every corner of a suitcase.

Because containers have far less overhead than VMs, and because Kubernetes actively optimises placement, you can run many more workloads on the same physical or virtual hardware. Idle capacity that would have been stranded inside individual VMs is now shared across all Pods on the node.

A Rough AWS Cost Comparison

The following numbers are illustrative and simplified. Actual costs depend on instance types, reserved pricing, data transfer, storage, and many other factors. Do not treat these figures as a precise benchmark — use them to understand the order-of-magnitude difference in approach.

Typical VM-Based Setup

Consider a team running 20 application EC2 instances and 4 RDS database instances, all sized for peak load with consistently low average utilisation:

• 20 EC2 instances × ~$100/month = $2,000/month
• 4 RDS instances × ~$250/month = $1,000/month
• Total: ~$3,000/month

Kubernetes on AWS EKS

Migrating those 20 applications to containers and running them as Pods on a single EKS worker node (for example, an m5.xlarge, which AWS allows to run up to 58 Pods based on its network interface IP limits) could look like this:

• 1 × m5.xlarge EC2 worker node × ~$300/month = $300/month
• EKS control plane fee = ~$73/month (check current AWS pricing)
• RDS instances (unchanged) = $1,000/month
• Total: ~$1,373/month

In this illustrative scenario, the EC2 compute cost alone drops from $2,000 to roughly $300 — a reduction of approximately 85% on that line item, and around 54% of the overall bill. In practice, across multiple clients, savings in the range of 60–70% of existing EC2 cloud costs have been reported, particularly where EC2 instances are consistently underutilised. Your mileage will vary based on actual workload characteristics and the instance types you choose.

Note: The RDS line item is excluded from the EC2 saving because managed database services are not typically containerised in the same way. Database migration decisions deserve their own analysis.

Prerequisites: Containerising Your Workloads

Realising these savings is not automatic. Your team must be able to:

1. Containerise each application — write a Dockerfile, build an image, and push it to a container registry (Docker Hub, Amazon ECR, Google Artifact Registry, etc.).
2. Write Kubernetes manifests — define Deployments, Services, ConfigMaps, and resource requests/limits for each workload.
3. Integrate with CI/CD pipelines — automate image builds and cluster deployments so that every commit produces a tagged, versioned image that can be promoted through environments.

This investment in containerisation pays dividends beyond cost reduction. A tagged container image is a portable, reproducible artifact that runs identically on a developer laptop, an on-premises cluster, or any cloud provider’s managed Kubernetes service. It also enables advanced deployment strategies out of the box:

• Blue/Green deployments — run two identical environments, switch traffic instantly, roll back immediately if something goes wrong.
• Canary releases — route a small percentage of traffic to a new version before rolling it out fully.
• Rolling updates — Kubernetes replaces Pods incrementally with zero downtime by default.

Beyond Cost: Other Reasons to Adopt Kubernetes

Cost optimisation is a compelling starting point, but Kubernetes offers a broader set of operational benefits:

• Portability — workloads are no longer coupled to a specific cloud provider or hypervisor.
• Self-healing — Kubernetes automatically restarts failed containers and reschedules Pods away from unhealthy nodes.
• Horizontal scaling — the Horizontal Pod Autoscaler can scale your application Pods based on CPU, memory, or custom metrics, and the Cluster Autoscaler can add or remove worker nodes to match demand.
• Declarative configuration — your entire infrastructure state is described in version-controlled YAML files, making it auditable and reproducible.
• Ecosystem — a large ecosystem of Helm charts, operators, and CNCF projects covers observability, networking, security policy, and more.

Is Kubernetes Right for Every Workload?

Kubernetes introduces operational complexity. Small teams running a handful of simple services may find that the learning curve and cluster management overhead outweigh the savings. Managed services like AWS EKS, Google GKE, and Azure AKS reduce — but do not eliminate — that burden. Before committing, assess:

• Whether your applications can be containerised without significant refactoring.
• Your team’s current Kubernetes expertise or appetite for training.
• Whether your workloads are genuinely underutilising their current VMs (check actual CPU and memory metrics, not just assumed peak sizing).
• Stateful workloads — databases and other stateful services require additional planning (persistent volumes, operators) and may be better left on managed cloud database services.

Summary

The suitcase analogy makes the economic argument for Kubernetes intuitive: VMs are like fixed-size boxes that waste space; containers are like loose items you can pack tightly. Kubernetes is the expert packer that fills every available gap. For organisations running underutilised VM fleets — especially on public cloud infrastructure where every idle CPU cycle costs money — migrating workloads to a Kubernetes cluster can yield substantial and measurable cost reductions, while simultaneously improving deployment velocity and operational resilience.

Original concept and suitcase analogy attributed to Owen Rogers (451 Research), as discussed on the Google Kubernetes Podcast.

Red Hat and AWS Expand Their Partnership with a Jointly Managed OpenShift Service

Red Hat has extended its strategic alliance with Amazon Web Services (AWS) to include a jointly managed Kubernetes service built on Red Hat OpenShift. Under the arrangement, AWS is responsible for managing the underlying public cloud infrastructure, while Red Hat takes ownership of a fully managed OpenShift control plane running on top of it. Billing flows through a customer’s existing AWS contract, removing the need to manage a separate Red Hat invoice.

Sathish Balakrishnan, then Vice President for Hosted Platforms at Red Hat, described the offering at the time of launch. He noted that Red Hat already had comparable jointly managed arrangements with Microsoft Azure and IBM, as well as a separately available product called Red Hat OpenShift Dedicated, which Red Hat deploys and manages on Google Cloud Platform (GCP) on behalf of customers.

Why Organizations Are Turning to Managed Kubernetes

The appeal of a managed OpenShift service reflects a broader industry shift in how enterprises consume Kubernetes. Several factors are driving this trend:

• Operational complexity. Kubernetes involves a significant operational surface area—cluster provisioning, networking, storage, upgrades, and security patching. Many organizations prefer to delegate that responsibility rather than absorb it internally.
• Talent scarcity. Skilled Kubernetes engineers remain difficult to hire and retain. A managed service lets teams consume the platform without needing deep in-house expertise from day one.
• Skills transfer. Some organizations use a managed service as a stepping stone: they consume OpenShift as a service while their internal teams learn the platform, with the option to take over management later.
• Resource constraints. At the time of the launch (mid-2020), the economic disruption caused by the COVID-19 pandemic had left many IT departments understaffed, accelerating interest in offloading platform management.

Red Hat’s Broader Managed Service Ecosystem

The AWS partnership sits within a much larger managed service ecosystem that Red Hat has built around OpenShift. At the time of the announcement, Red Hat already had relationships with more than 300 IT services providers that make OpenShift available as a managed offering. The strategy reflects Red Hat’s goal of making OpenShift available across every major public cloud and hybrid environment as the runtime fabric of a broad hybrid cloud computing strategy.

Customers can choose how they engage with the platform:

• Directly through Red Hat (OpenShift Dedicated or the relevant cloud-provider managed service)
• Through a hyperscaler such as AWS, Microsoft, or IBM under a jointly managed model
• Through a third-party IT services provider that wraps OpenShift in its own managed offering

DevOps Considerations for Managed OpenShift

One practical challenge that teams face when adopting any managed Kubernetes service is aligning their existing DevOps workflows to the constraints and opinions of the managed platform. OpenShift takes an opinionated stance on how applications are built and deployed—for example, it enforces stricter security contexts than vanilla Kubernetes by default. However, the platform does expose extension points that allow teams to integrate their preferred CI/CD tooling, policy engines, and observability stacks through plug-ins and Operators.

Engineering teams evaluating a managed OpenShift service should assess:

• Which cluster configuration options are exposed to tenants versus locked down by the managed provider
• How upgrade schedules are communicated and whether teams can defer patch windows
• How existing Helm charts, Operators, or custom controllers will behave under OpenShift’s security policies
• What observability and logging data is surfaced to tenants versus retained only by the provider

The Broader Kubernetes Adoption Curve

The launch of this service reflects a maturing Kubernetes market. Enterprises are increasingly treating Kubernetes not as a technology to evaluate, but as infrastructure to consume. The remaining open question—relevant to both managed service providers and platform teams—is what percentage of new workloads will be refactored into microservices architectures versus lifted and shifted as monoliths onto containerized infrastructure.

Microservices architectures are better suited to Kubernetes’s scheduling and scaling model, but they carry higher initial development and operational complexity. Organizations that move monolithic applications to containers gain portability and some operational consistency, but they may not realize the full flexibility benefits that a cloud-native architecture enables. Both paths are increasing the overall footprint of Kubernetes clusters in production—and, by extension, demand for managed services that absorb the operational overhead of running them.

Summary

Red Hat’s jointly managed OpenShift service with AWS gives enterprise teams a straightforward path to production-grade Kubernetes without staffing a dedicated platform engineering team. By consolidating billing through an existing AWS contract and distributing operational responsibility between the two vendors, the offering lowers the barrier to adopting OpenShift at scale. As managed Kubernetes services from multiple providers mature, the key differentiators will increasingly be operational transparency, upgrade control, and how well the platform integrates with a team’s existing DevOps toolchain.

What Is NetApp Project Astra?

In April 2020, NetApp announced Project Astra, a vision for a software-defined platform being developed in collaboration with the Kubernetes community. The goal: deliver enterprise-class storage and data services for stateful, cloud-native applications running on any Kubernetes distribution, on any cloud.

At the time of announcement, Project Astra was still in active development. NetApp positioned it as the next major evolution of its Kubernetes data management capabilities, building on existing products such as NetApp Trident (the open-source dynamic storage provisioner for Kubernetes) and NetApp Kubernetes Services.

The Problem Project Astra Was Designed to Solve

Kubernetes adoption accelerated rapidly in enterprise environments in the late 2010s, but stateful workloads—applications that depend on persistent data—exposed a significant gap in the ecosystem. While Kubernetes excels at making stateless applications portable and resilient, data portability for stateful applications remained difficult to achieve reliably.

IT teams and site reliability engineers (SREs) were expected to meet enterprise-grade standards for data governance, protection, and replication—but without a unified, Kubernetes-native toolset to do so. Specifically, the challenges included:

• Lack of reliable data services: Many organizations running Kubernetes lacked robust, enterprise-class storage services tightly integrated with their workloads.
• Limited data portability: Application containers could move freely across environments, but their associated persistent data often could not.
• Operational complexity: Managing storage and data protection across hybrid and multi-cloud Kubernetes deployments required disparate tools and significant manual effort.
• Stateful application support: Data-rich, stateful applications were treated as second-class citizens compared to stateless microservices in most Kubernetes frameworks.

Project Astra’s Core Capabilities

NetApp described Project Astra as a platform that would allow teams to:

• Discover applications running on any Kubernetes distribution, whether on-premises or in public cloud environments.
• Integrate and unify application and data management into a single, consistent workflow.
• Deliver data services as built-in capabilities, surfacing NetApp’s expertise in storage management directly within Kubernetes-native tooling.
• Extend true portability to stateful, data-rich workloads—not just stateless containers.

The platform was designed to leverage NetApp’s public cloud partnerships and augment them with Kubernetes-native data service integrations, meaning storage and data operations would be tightly coupled with the application lifecycle rather than managed as a separate infrastructure concern.

Architecture Approach: Software-Defined and Distribution-Agnostic

A key architectural principle behind Project Astra was distribution agnosticism. Rather than tying data services to a specific Kubernetes flavor, NetApp aimed to build a software-defined layer that could plug into any Kubernetes distribution and management environment.

Anthony Lye, then Senior Vice President and General Manager of NetApp’s Cloud Data Services business unit, stated at the time:

“Project Astra represents the next major step in the evolution of storage and data services for Kubernetes. We are making a decisive and long-term commitment to addressing the data challenges of Kubernetes, together with the communities and platforms that use it. Project Astra will provide a software-defined architecture and set of tools that can plug into any Kubernetes distribution and management environment.”

Anthony Lye, SVP and GM, NetApp Cloud Data Services

Community Collaboration and NetApp’s Kubernetes Lineage

NetApp emphasized that Project Astra was being built with the Kubernetes community, not just for it. The project was intended to benefit Kubernetes developers and operations managers who needed better data management tooling as a natural extension of their existing workflows.

Eric Han, Vice President of Product Management for NetApp’s Cloud Data Services business unit, brought notable credentials to the initiative, having served as an early product manager for Kubernetes at Google. He commented:

“In a few short years, Kubernetes has become the de facto choice in orchestrating container environments. Yet there is still potential, and a need, to further evolve. With Project Astra, NetApp is delivering on the true promise of portability that professionals working with Kubernetes require today and is working in parallel with the community and our customers to make all data managed, protected, and portable, wherever it exists.”

Eric Han, VP Product Management, NetApp Cloud Data Services

Foundation: NetApp Trident and NetApp Kubernetes Services

Project Astra was not a greenfield effort. It was explicitly built on NetApp’s existing Kubernetes data management foundation:

• NetApp Trident: An open-source, dynamic storage provisioner for Kubernetes that automates the creation and management of persistent volumes backed by NetApp storage systems. Trident supports the Container Storage Interface (CSI) standard and had already enabled customers to manage large volumes of container data before Project Astra was announced.
• NetApp Kubernetes Services (NKS): A managed Kubernetes service that provided a unified control plane for deploying and managing Kubernetes clusters across multiple cloud providers.

Project Astra was positioned as the logical next layer—adding application-aware data management, protection, and portability on top of the storage provisioning capabilities Trident already provided.

Why This Announcement Mattered for DevOps Teams

For DevOps engineers and platform teams in 2020, Project Astra addressed a real and growing pain point. As Kubernetes usage expanded beyond stateless microservices into databases, message queues, and other stateful workloads, the lack of enterprise-grade, Kubernetes-native data management tooling was a meaningful operational risk.

Key implications for practitioners included:

• Simplified disaster recovery: Application-integrated data management means backup, restore, and replication policies can be defined alongside workload manifests rather than as separate infrastructure-level configurations.
• Multi-cloud portability: A distribution-agnostic platform reduces lock-in risk and makes it easier to migrate stateful workloads between cloud providers or between on-premises and cloud environments.
• Developer self-service: Surfacing data services as Kubernetes-native capabilities opens the door to self-service data management for application teams, reducing the operational burden on centralized storage teams.
• Compliance and governance: Enterprise-class data services include audit trails, access controls, and policy enforcement—capabilities that are difficult to bolt on after the fact in most Kubernetes environments.

Project Astra’s Evolution: Astra Data Store and Astra Control

Following the initial announcement, NetApp continued to develop the Project Astra vision. The project eventually materialized as the NetApp Astra portfolio, which included products such as Astra Control (for application-aware data management and protection) and Astra Trident (the rebranded evolution of NetApp Trident). Teams evaluating NetApp’s Kubernetes data management solutions should refer to current NetApp documentation for the latest product names, features, and availability, as the portfolio has continued to evolve after this original 2020 announcement.

Summary

Project Astra represented NetApp’s strategic commitment to solving one of the most persistent challenges in enterprise Kubernetes adoption: making stateful application data as portable, protected, and manageable as the applications themselves. By building a software-defined, distribution-agnostic platform in close collaboration with the Kubernetes community, NetApp aimed to bridge the gap between the rapid growth of container adoption and the enterprise-grade data management capabilities that production workloads require.

Overview

Tel Aviv-based prooV announced a strategic integration with AWS Service Catalog in April 2020, allowing enterprises to run structured proofs-of-concept (PoCs) and promote validated third-party software directly into their AWS Service Catalog. The integration is aimed at eliminating one of the most persistent bottlenecks in corporate software adoption: the slow, resource-intensive PoC process.

The Problem: PoCs as an Innovation Bottleneck

Before deploying any third-party software, most enterprises require a proof-of-concept phase to validate the technology against their specific business and technical requirements. Historically, this process has been time-consuming, expensive, and difficult to standardize across large organizations. Each PoC typically demands dedicated infrastructure, security reviews, and manual coordination between vendors and internal teams.

prooV positions itself as a purpose-built platform to address these inefficiencies. According to the company, enterprises can use prooV to set up isolated evaluation environments using AWS CloudFormation, run comparative tests across multiple vendor solutions simultaneously, and then promote the selected software directly to their AWS Service Catalog once evaluation is complete.

What Is AWS Service Catalog?

AWS Service Catalog is a managed AWS service that lets organizations create and centrally manage approved IT service portfolios. Administrators can define catalogs of pre-approved resources — including virtual machine images, databases, multi-tier application stacks, and other AWS-native services — that end users can then self-provision in a governed, compliant way.

By integrating PoC outputs directly into AWS Service Catalog, teams close the gap between software evaluation and production deployment, reducing re-work and ensuring that only vetted configurations enter the live environment.

What the prooV and AWS Service Catalog Integration Enables

According to the announcement, the integration supports the following enterprise workflows:

• Side-by-side vendor comparison: Evaluate multiple third-party software options simultaneously against defined business and technology KPIs, rather than testing each vendor sequentially.
• Pre-deployment configuration testing: Fine-tune software configurations in an isolated PoC environment before committing to production deployment, reducing the risk of post-deployment issues.
• Direct deployment to AWS Service Catalog: Once a PoC evaluation concludes and a solution is selected, the validated software configuration can be pushed directly to the enterprise’s AWS Service Catalog, maintaining compliance and governance throughout.
• CloudFormation-based environment setup: PoC environments are provisioned using AWS CloudFormation, enabling repeatable, infrastructure-as-code-driven setup and teardown of evaluation sandboxes.

Why This Matters for DevOps and Platform Engineering Teams

For DevOps and platform engineering teams, the integration addresses a real operational challenge: maintaining the speed of innovation without sacrificing security, compliance, or architectural consistency.

By enforcing PoC evaluation through a structured platform that integrates natively with AWS Service Catalog, organizations can:

• Standardize how new technologies are evaluated and approved across business units.
• Avoid shadow IT by giving teams a sanctioned, self-service path to test and adopt new tools.
• Surface performance bottlenecks, scaling limitations, and security risks earlier in the software selection lifecycle — before production traffic is involved.
• Reduce the time from vendor selection to production readiness by eliminating manual handoffs between the PoC team and the infrastructure team.

“CIOs today need to make quick, yet insightful decisions on which application is best for their business. Using prooV, enterprises can assess multiple technologies simultaneously to identify feature sets, scaling challenges, performance bottlenecks, and security risks before releasing an application to production. This strategic integration with AWS gives organizations an extra level of assurance on how a new solution will operate in its production environment before implementation.”

— Toby Olshanetsky, CEO and Co-Founder, prooV

About prooV

prooV describes itself as an end-to-end proof-of-concept platform for third-party software evaluation. The company was founded by serial entrepreneurs who experienced the inefficiencies of traditional PoC processes firsthand. Its platform is designed to help global enterprises evaluate and adopt new technologies more quickly and at lower cost than conventional approaches.

Related Video

One thing I have noticed is that each industry comes up with their own terms and acronyms. Unfortunately, these inventions often vary depending on the person you speak to due to a lack of a governing body that decides on an exact definition. At times, acronyms can even overlap, causing further confusion. Therefore, when it comes to definitions, I always look to ask a variety of persons from across industries on how they would define certain terms. In fact, I took to Twitter and asked those in the industry to submit some responses to a study conducted on Survey Monkey a few results are below. (If you would like to add your definition(s), the survey is still open here) The survey results are presented below.

How would you define DevOps?
“It is supposedly a culture where dev and ops work side by side to deliver digital products within a timeframe that brings value to the business.” –anonymous
“DevOps is a combination of practices and tools that help an organization increase its capacity to evolve and improve products continuously and efficiently as well as to deliver IT services at high velocity.” –Zied TURKI
The above definitions were of interest to me because the first conceptualization separates the development team from the operations whereas the second viewpoint discusses the development team and their practices. To me, DevOps is essentially a team of developers designing, building, deploying, and maintaining software of any kind. The goal of this team is to do this efficiently and in a manner that’s aligned with a set standard decided by the organization. Speed is a piece of this, security another, but it’s the holistic approach through which the developers proceed that is important here.

How would you define NetOps?
“No clue.” –anonymous
“More like the combination of DevOps and network operations.” –anonymous
“Simply put – the network team.” –Evan Mintzer
“Apply DevOps principles to improve agility and performance of network services. Program and automate the ‘softwarized’ network infrastructure.” –Zied TURKI
This group of definitions made me smile, I personally have never heard NetOps used within an organization I worked for. I have used operations teams, network management, network architecture, and more, but never NetOps. However, as networking shifts from hardware to software focuses, I can see how this term could begin to grow. If I consider Cisco’s intent-based networking, its DevNet side and certifications along with the definitions provided by those above, I arrive at the following definition: NetOps is the networking team working with similar principles and practicing standardized practices but in reference to resilient networks.

How would you define DevSecOps?
“Security is included in the DevOps culture so that business value is delivered with lowest risk.” –anonymous
“The merging of development and security teams for coding into production. However, DevOps should be dealing with security.” –Evan Mintzer
“DevSecOps is about incorporating Security into DevOps at the beginning of the software development lifecycle to bridge security and agility. It’s about shifting security to the left.” –Zied TURKI
When I started working closer with development teams, advising on best practices and standards in regard to security, we were practicing what I would call SecDevOps. To me, the security piece come first. Wherever you put the word “security,” however, DevSecOps is at its heart a collaboration of development and security with the goal of creating resilient software for consumers.

What stands out uniquely between the above definitions to you?
“Less manual, traditional ways is doing things operationally.” –anonymous
“The terms above are newer, but they represent teams that have been around for a while.” –Evan Mintzer
“Being agile for better served customers.” –Zied TURKI
What is DevOps, NetOps, DevSecOps, and why does it matter? Truthfully, the overall definition of the term isn’t important; it’s the actions these teams take that does. To me, DevOps is a team that doesn’t simply build software. It’s a team that works holistically.

Whilst speaking at GOTO Berlin, I had the privilege to attend Oliver Drotbohm’s talk “REST beyond the obvious – API design for ever-evolving systems.” In this presentation, Oliver discussed the responsibility of working together across the teams and of not lumping work onto others by making it easier for yourself only. To me, that essentially defines what DevOps is.

Google’s Cloud Market Position: The Paradox

Google owns the world’s largest search engine, the most widely used web browser (Chrome), and the dominant mobile operating system (Android). Yet as of the Gartner analysis cited in early 2020, Google Cloud controlled just 4% of the public cloud services market — placing it in fourth position behind Amazon Web Services (AWS), Microsoft Azure, and Alibaba Cloud, which held approximately 48%, 16%, and 8% of the market respectively.

At the time, Google’s leadership reportedly expressed ambitions to become one of the top two cloud providers by 2023, according to reporting by The Information. Achieving that goal, however, required overcoming three significant structural challenges.

1. Management Instability and Internal Conflicts

Google recruited Diane Greene — co-founder of VMware — to lead Google Cloud roughly four years before this writing. Her tenure was marked by strategic disagreements with Google CEO Sundar Pichai, most notably around Project Maven, a U.S. Department of Defense initiative that applied AI to identify people and objects in imagery.

Greene reportedly wanted to retain the Project Maven contract as a significant revenue stream for the cloud unit. Pichai, facing intense internal employee backlash over ethical concerns about AI weaponization, chose not to renew it. Google ultimately formalized a set of AI ethics principles and withdrew from bidding on the Pentagon’s Joint Enterprise Defense Infrastructure (JEDI) — a $10 billion cloud contract that Microsoft eventually won.

Greene also pursued a strategy of bundling Google Cloud services with Alphabet’s other product lines. According to The Information, this approach created friction with other division heads and failed to convert major enterprise customers. Adding to the instability, Google Cloud’s COO Diane Bryant resigned abruptly after less than a year in the role.

Greene herself stepped down in early 2019. Her replacement, Thomas Kurian — a former Oracle executive — inherited a cloud organization that had lost momentum while AWS and Azure continued to accelerate. Kurian moved to expand Google Cloud’s enterprise sales force and made targeted acquisitions, including migration-tool maker CloudSimple, but the question remained whether these moves were sufficient to close a widening gap.

2. Missed Strategic Acquisitions

Unlike its major cloud competitors, Google did not aggressively pursue acquisitions to build out its cloud platform. This restraint proved costly on multiple fronts:

• GitHub: Greene reportedly sought to acquire the code-hosting and collaboration platform, but the proposal did not advance internally. Microsoft acquired GitHub in 2018 for $7.5 billion, immediately gaining deep integration points with enterprise development workflows.
• Red Hat: IBM acquired the open-source enterprise software company for $34 billion, significantly strengthening its hybrid cloud capabilities — a model many enterprises prefer.
• MuleSoft: Salesforce acquired this integration platform developer for $6.5 billion, extending its reach into enterprise data integration — a market increasingly important in multi-cloud environments.

At the time of writing, Alphabet held approximately $121 billion in cash, cash equivalents, and marketable securities — ample capital to have pursued multiple large acquisitions. The restraint left Google Cloud without the enterprise software hooks and developer mindshare that competitors were actively acquiring.

3. Privacy Concerns and a Lack of Enterprise Leverage

Alphabet’s core business model depends on targeted advertising fueled by data mining — a fact that creates a structural trust deficit when approaching enterprise customers in privacy-sensitive sectors like healthcare, finance, and government.

This tension surfaced directly in 2019 when Google Cloud’s agreement to store patient data for Ascension Health hospitals drew widespread scrutiny and triggered a federal investigation. A pending acquisition of Fitbit — intended to accelerate Google’s presence in digital health — also faced Justice Department review. These high-profile concerns gave regulated-industry buyers additional reasons to favour AWS or Azure, whose parent companies derive comparatively little revenue from advertising and data monetization.

Beyond trust, Amazon and Microsoft each had structural leverage Google lacked:

• AWS benefits from a first-mover advantage, a vast service catalogue, and a reputation for reliability that many enterprises built their architectures around.
• Microsoft Azure can bundle cloud services with Office 365, Windows 10, and a deep enterprise software sales motion — relationships that go back decades. Microsoft is also a natural choice for retailers competing with Amazon’s own e-commerce business and wary of giving AWS further data on their operations.
• Google Cloud, by contrast, had no comparable enterprise software suite to bundle with its infrastructure offering. Its strongest competencies — search, advertising, browsers, and Android — offered limited leverage in selling enterprise cloud contracts.

Where Google Cloud Has Real Strengths

Despite these challenges, dismissing Google Cloud entirely would be a mistake. The platform has genuine technical differentiators worth recognising:

• Kubernetes and container services: Google invented Kubernetes and remains a leader in container orchestration. This gives Google Cloud a credible foothold with engineering-led organisations adopting cloud-native architectures.
• Data analytics and AI/ML tooling: BigQuery, Vertex AI, and related services are genuinely competitive offerings in the data platform market.
• Global network infrastructure: Google operates one of the world’s largest private fibre networks, which can translate to performance advantages for globally distributed workloads.
• Competitive pricing: Google has historically used pricing aggressively as a lever, offering sustained-use discounts and per-second billing models that put pressure on competitors.

The Path Forward: Can the Gap Be Closed?

The structural obstacles Google Cloud faces — trust deficits in regulated sectors, a lack of enterprise software bundling, and a slower start on acquisitions — are real but not insurmountable. The levers available include:

• Targeted acquisitions in enterprise software or security to fill capability gaps
• Aggressive price competition to dislodge workloads from AWS and Azure
• Doubling down on niche technical strengths, particularly in AI/ML and containerisation
• Building explicit data-use boundaries and compliance certifications to address privacy concerns in regulated industries

Under Thomas Kurian’s leadership, Google Cloud began reporting revenue separately and showed accelerating growth. Whether it can close the gap with AWS and Azure — let alone surpass them — depends on consistent execution over a multi-year horizon, not just product capability.

For DevOps engineers and architects evaluating cloud platforms, Google Cloud’s technical merits increasingly stand on their own. The competitive dynamics at the corporate level are real, but workload fit, tooling integration, and total cost of ownership should drive platform decisions — not market share rankings alone.

Market share figures and financial data cited in this article reflect publicly reported information from approximately late 2019 to early 2020 and may not reflect current conditions.

The crowded halls of the official Kubernetes conference Kubecon reflect a nascent but important technology whose best future might be to disappear into the background.

Kubernetes is an important part of the future of computing infrastructure, because containers are an important new tool for the way we build applications.

CLOUD
Microsoft acquires cloud file-migration specialist Mover
Red Hat OpenShift 4.2: Kubernetes for the hybrid-cloud developer
Top cloud providers 2019: AWS, Microsoft Azure, Google Cloud
Adobe’s cloud pivot: What we’ve learned (ZDNet YouTube)
Buy a Google Pixel 4, get 3 free months of Google One (CNET)
How to calculate AWS costs and avoid paying too much for cloud services (TechRepublic)
What we often call ‘cloud-native’ applications are designed to handle failure by just restarting and retrying rather than having enormous fault tolerance and resilience built in – replacing hardware with software but still keeping the rather brute-force nature of turning things off and on. The distributed microservices that make up cloud-native applications help with that, as well as allowing small pieces of the application to be built and updated independently.

That doesn’t mean abandoning all the other technologies that have been useful, and the introduction into Linux of Intel’s KATA isolated containers is validation of Microsoft’s opinion that the security isolation provided by virtual machines is still important. Kubernetes is still catching up in some fairly critical areas; support for combined IPv4 and IPv6 networks has only just been introduced in Kubernetes 1.16. Windows support is only just maturing – with Microsoft’s LCOW (Linux Containers on Windows) work now part of the containerd runtime – and Active Directory service account support still only in beta. Kubernetes isn’t in any sense what you’d call complete.

SEE: Cloud v. data center decision (ZDNet special report) | Download the report as a PDF (TechRepublic)

That’s because rebuilding all the tools and concepts we had before, in Kubernetes, is a lot of work; it may be worth it to get the benefits of containers, but it’s important to keep things in perspective.

To look at Kubecon this year, with its 10-12,000 attendees, you’d think that Kubernetes was well on its way to comprising the entirety of compute infrastructure, from enterprise apps to mobile networks to edge computing to serverless to databases to machine learning to networking to development tools to literally everything else.

Putting all of that together with the on-going developments in Kubernetes itself makes it hard to find any one topic and dig deep on it, because there’s just so much noise. Not only were there more attendees at one session covering a new Special Interest Group than the 550 people who went to the first Kubecon in Seattle in 2015, but there are almost as many organizations who have joined the CNCF as the attendees at that first Kubecon.

Some of that is about the way Kubernetes is becoming a common piece of infrastructure, and some of it is about the millions of dollars sloshing around the Kubernetes ecosystem. Kubernetes has become so significant that large enterprise IT companies from Microsoft to VMware to IBM have hired key developers and made contributions to key projects, either to get the expertise to deliver their own Kubernetes products and services or to move the ecosystem forward in a way that meshes with their existing products and services. The CNCF certification program for Kubernetes distros has allowed the number to proliferate without succumbing to the OpenStack problem of incompatibility between distributions from different vendors.

Some of it is even part of the way that Kubernetes is one of the healthiest open-source projects in recent years, in both senses of the word. The community building Kubernetes is particularly helpful, welcoming, diverse, self-aware and supportive, and while progress on some features like dual-stack support has been slower, regular releases bring new features at a fairly respectable clip. An organized process for rotating who’s working on the launch team stops the same few people from being overburdened, keeps enthusiasm high – and brings a continual stream of new people from more companies into the process.

Kubernetes is still booming, still growing and still producing new projects at a speed that says the ecosystem is still in its pre-Cambrian explosion of species diversity. But every pre-Cambrian explosion is followed by an Ediacaran die-off and if you squint carefully enough you might see the glow from the meteorite plummeting towards you. The explosion of multiple products (five service meshes! Multiple service catalogs!) will get curated down to a more manageable set of choices and ideally, much of Kubernetes will disappear into the infrastructure that most people in technology don’t have to think about any more than they think about the way an OS filing system, a database engine or a hypervisor works.

SEE: Just how popular is Kubernetes?

Kubernetes evangelist Kelsey Hightower noted recently that “The cloud made the hypervisor disappear. Kubernetes will be next.” That doesn’t mean either Kubernetes or the hypervisor is going away (see KATA containers where the oh-so-important isolation is provided by a hypervisor), any more than serverless magically works without anyone having any servers: just that all these trends are about not having to care about that infrastructure to get something done.

For Kubernetes, that might mean caring more about the Kubernetes API that handles the ‘getting things done’ part than the nodes and pods and other Kubernetes concepts that actually do the thing.

There are lots of ways of delivering that – cloud Kubernetes services, virtual kubelets and ephemeral containers and a half dozen other ideas – so there will be multiple projects and vendors springing up like mushrooms in the forest to deliver that abstraction, and infrastructure admins will get to care and worry about all of those. And Kubecon probably won’t get any smaller or more manageable unless it splits into a couple of more focused conferences.

But however ubiquitous the Kubernetes API might get, it’s not going to displace everything else. It might become the new IaaS where workloads run, but there’s still going to be plenty of more specialised PaaS options as well as ways to piece together cloud native applications out of PaaS pieces.

SEE: Serverless Kubernetes containers: Amazon EKS on AWS Fargate

And while Kubernetes itself is fairly new, many of the concepts it delivers aren’t. So yes, Kubernetes can be a big part of the future of computing without anyone apart from the infrastructure team knowing how to work with it directly or maybe even knowing it’s there. But the tools to do that need to shape up and stop treating Kubernetes as some special new thing.

It’s the latest crank of the wheel in computing platforms. It’s the latest abstraction for delivering a platform, likely itself to get abstracted away by some new layer.

It might be more useful to think of Kubernetes as the new Linux kernel rather than the new hypervisor. But whichever layer of infrastructure you think of it as, fast forward a couple of years and the focus will be much more on what you do with Kubernetes than how you do Kubernetes. And maybe Kubecon will be a little more targeted and manageable to go with that progression.

What Happened

A publicly accessible Jenkins server owned by GE Aviation exposed sensitive internal assets — including plaintext passwords, source code, private keys, and global system configuration details — due to a DNS misconfiguration that made the server reachable from the open internet.

GE Aviation is a subsidiary of General Electric and one of the world’s leading commercial aircraft engine suppliers. The exposed Jenkins server reportedly contained a README file that listed all stored files along with notes about their sensitivity, effectively serving as an index for attackers.

How It Was Discovered

Security researcher Bob Diachenko discovered the open server after querying Shodan — a search engine that indexes internet-connected devices — to find how many Jenkins instances were publicly accessible. As of July 7, 2019, Diachenko reported finding 5,495 open and publicly available Jenkins instances in Shodan’s index.

After identifying the GE Aviation server in June 2019, Diachenko sent multiple notifications to the company. GE’s security team eventually responded and the server was taken down or secured. The duration for which the server remained publicly accessible was not disclosed.

Why Jenkins Servers Are a High-Value Target

Jenkins is a widely used open-source automation server written in Java, commonly deployed for continuous integration (CI) and continuous deployment (CD) pipelines. Because Jenkins sits at the center of the software delivery process, it routinely handles some of the most sensitive assets in a development environment.

• Source code — often the company’s core intellectual property
• API tokens and credentials — used to authenticate deployments to cloud services, registries, and databases
• Private keys — for SSH access, code signing, or TLS termination
• Configuration files — detailing internal network topology and service dependencies
• Database credentials — potentially granting direct access to production or staging data stores

“Jenkins is a service instance used by developers for integration and deployment. It is accessed via browser and can keep very sensitive information. Apart from source code itself, which is IP (Intellectual Property), it’s possible to dig out config files, API tokens, database credentials and lot more.”

— Bob Diachenko, security researcher

Root Cause: No Master Password and a DNS Misconfiguration

Two distinct failures contributed to this exposure:

1. Disabled authentication. Jenkins supports authentication and authorization controls, but these must be explicitly configured and enforced. Diachenko noted that developers frequently disable password protection for convenience — for example, when working remotely on a project — leaving the Jenkins panel accessible to anyone who can reach the server’s URL.
2. DNS misconfiguration. A misconfiguration in the server’s DNS records caused the internal Jenkins instance to resolve to a publicly routable IP address, exposing it to the internet rather than keeping it restricted to GE Aviation’s internal network.

Together, these two misconfigurations removed both layers of protection that should have kept the server private: network-level isolation and application-level authentication.

GE Aviation’s Response and Risk Classification

GE Aviation classified the incident as medium-risk, a characterisation that drew attention given the nature of the exposed data. The company stated it had found no evidence of unauthorised access, but reset all exposed credentials as a precautionary measure.

“Plaintext usernames and passwords were exposed on this server, but these credentials mapped to applications only accessible from our internal network, and no customer data, nor any significant GE data, was impacted. Furthermore, even if a malicious actor were to have acquired these credentials, they would also need access to our internal environment to exploit them.”

— GE Aviation statement

While GE Aviation’s argument that internal-network-only credentials limit direct exploitability has some merit, security practitioners generally consider plaintext credential exposure a high-severity finding regardless of where those credentials are subsequently used, because the credentials themselves can be leveraged in further attacks such as phishing, credential stuffing, or lateral movement if combined with other access paths.

Broader Context: A Pattern of Inadvertent Exposure

This incident was not isolated. Around the same period, several other organisations experienced similar inadvertent exposure events:

• Attunity (June 2019): Three publicly accessible cloud storage buckets belonging to the data management firm exposed more than a terabyte of data from Fortune 100 customers, including internal business documents and system passwords.
• HCL Technologies (May 2019): The IT services provider accidentally exposed passwords, sensitive project reports, and private customer and employee data on publicly accessible HCL subdomains.
• Facebook (April 2019): Hundreds of millions of Facebook user records were found in two separate publicly exposed third-party app datasets.

Each of these incidents shares a common thread: sensitive data placed in an internet-accessible location without adequate access controls, often as a result of misconfiguration rather than a sophisticated attack.

How to Prevent Jenkins Exposure

The GE Aviation incident is instructive for any team running Jenkins or similar CI/CD tooling. The following controls should be treated as baseline requirements:

• Enable authentication by default. Jenkins ships with security disabled in some older configurations. Always enable the built-in security realm or integrate with an identity provider (LDAP, SAML, OAuth) from the first deployment.
• Restrict network access. Jenkins should never be exposed directly to the public internet. Place it behind a VPN, restrict access by IP allowlist, or host it on an internal-only network segment.
• Audit DNS records regularly. DNS misconfigurations can inadvertently expose internal services. Use automated tooling to audit which hostnames resolve to public IP addresses and validate that this matches your intended exposure.
• Use credential management integrations. Avoid storing plaintext secrets in Jenkins configuration. Use the Jenkins Credentials Plugin, HashiCorp Vault, or a cloud-native secrets manager to inject credentials at runtime.
• Monitor with Shodan or similar tools. Proactively search for your own organisation’s exposed infrastructure. Many organisations now run periodic Shodan queries against their IP ranges and domain names as part of their attack surface management programme.
• Apply the principle of least privilege. Restrict which users and pipelines can access which credentials and environments. Role-based access control (RBAC) is available through Jenkins plugins such as the Role Strategy Plugin.

Key Takeaway

Sophisticated attacks are not always necessary to compromise sensitive corporate infrastructure. A single DNS misconfiguration combined with a missing authentication prompt was sufficient to expose an aircraft engine manufacturer’s internal credentials and source code to the entire internet. For DevOps teams, this underscores the importance of treating CI/CD infrastructure security with the same rigour applied to production systems — because in practice, your build server often holds the keys to your production environment.

DevOps and MSPs: A Primer

Managed Service Providers (MSPs) are companies that deliver IT services to client organizations on a contract basis. MSPs are typically engaged by organizations that want to outsource some or all of their IT functions—reducing the need to hire, train, and retain in-house IT staff.

DevOps is a software delivery philosophy and cultural practice that emphasizes close collaboration between development and IT operations teams. Its core goals include shorter release cycles, continuous feedback loops, shared responsibility, and iterative improvement across the full software delivery lifecycle.

Both the MSP market and DevOps adoption have been growing steadily within the IT industry. The fundamental question is whether an organization can pursue both at the same time—or whether choosing one means limiting the other.

Where DevOps and MSPs Work at Cross-Purposes

The core tension is straightforward: DevOps requires direct control over IT operations culture, tooling, and process. When you outsource IT operations to an MSP, you typically hand that control to a third party.

MSP clients generally do not dictate which tools, workflows, or cultural practices their provider uses internally. The MSP manages those decisions. This creates a structural barrier to DevOps adoption:

• No in-house Ops team: If your entire IT operations function is outsourced, there is no internal team with whom developers can collaborate in the DevOps sense. The “Ops” side of DevOps effectively sits behind a contractual wall.
• Partial outsourcing: If you retain some IT staff but rely on MSPs for certain services, your DevOps practice is constrained to whatever your in-house staff can support. Anything the MSP handles falls outside the DevOps loop.
• Cultural misalignment: DevOps depends on a shared culture of continuous improvement, blameless post-mortems, and rapid feedback. An MSP operating under a traditional service-level agreement (SLA) model may not naturally align with those values.

In short, the more heavily an organization relies on MSPs for its IT operations, the harder it becomes to implement a genuine DevOps practice—not because of technical limitations, but because of organizational and cultural ones.

DevOps-Friendly MSPs: A Practical Middle Ground

The conflict between MSPs and DevOps is real, but it is not absolute. A growing number of MSPs explicitly design their services and communication models to support DevOps practices. If your organization wants to use managed services while also pursuing DevOps, the key is selecting the right MSP partner.

What distinguishes a DevOps-compatible MSP from a traditional one?

• Transparent operations: Rather than operating as a black box—delivering outputs without visibility into process—a DevOps-friendly MSP shares data, metrics, and operational context with the client.
• Collaborative planning: The MSP actively involves the client organization in IT planning, change management, and incident reviews rather than handling everything internally.
• Toolchain flexibility: The MSP is willing to integrate with the client’s existing CI/CD pipelines, monitoring tools, and communication platforms (such as Slack, PagerDuty, or Jira) rather than enforcing a proprietary stack.
• Continuous feedback loops: The MSP provides regular reporting and is open to iterative process improvement based on client feedback—mirroring the retrospective culture central to DevOps.
• Shared responsibility model: Incidents and outages are treated as shared problems to solve together, not as contractual disputes over SLA compliance.

Working in a DevOps manner across an organizational boundary—between an in-house dev team and an external MSP—does demand more effort from both sides. Communication must be more deliberate. Agreements around tooling, escalation paths, and data sharing need to be explicit rather than assumed. The seamless collaboration that DevOps enables within a single co-located team becomes harder to achieve when some participants work for a different company.

Key Questions to Ask Before Combining MSP and DevOps

Before committing to a hybrid MSP-plus-DevOps model, engineering and IT leadership teams should work through the following questions:

1. Which IT functions are being outsourced? If the outsourced functions are entirely separate from the software delivery pipeline (e.g., facilities networking or helpdesk), DevOps may not be significantly affected. If Ops functions central to deployment and monitoring are outsourced, the impact is much greater.
2. Does the MSP support your toolchain? Ask prospective MSPs whether they can integrate with your CI/CD pipeline, monitoring stack, and incident management tools.
3. How does the MSP handle incidents? Understand whether the MSP conducts post-incident reviews, shares root cause analyses, and welcomes client participation—or whether incidents are resolved internally with minimal client visibility.
4. What does the contract allow? Review SLA terms to understand whether the agreement supports the kind of transparency and collaboration DevOps requires, or whether it creates barriers.
5. Is the MSP willing to adopt your communication culture? A DevOps-oriented organization that communicates in real time via chat and shared dashboards will struggle with an MSP that defaults to weekly email reports and ticketing queues.

The Bottom Line

DevOps and MSPs are not mutually exclusive, but they do require deliberate alignment. Organizations that lean heavily on managed services without thinking carefully about DevOps compatibility risk ending up with fragmented teams, opaque operations, and delivery pipelines that are difficult to iterate on.

The organizations best positioned to benefit from both are those that treat their MSP relationship as a genuine collaboration rather than a transactional service contract—and those that select MSP partners who are willing to operate that way. As both DevOps practices and managed IT services continue to mature, the market for MSPs that explicitly support DevOps workflows is likely to grow alongside demand from engineering-led organizations.

The Business Pressure Behind Cloud Automation

Speed and quality dominate executive conversations about IT strategy. Boards want faster delivery of innovative products and services without sacrificing reliability. That pressure falls squarely on engineering and operations teams: How do you accelerate the software delivery lifecycle across an increasingly complex, hybrid infrastructure?

The challenge has intensified as enterprise environments have expanded well beyond the data center. Healthcare providers monitor patients remotely via cloud platforms. Banks process financial transactions in the cloud. Retailers run marketing and commerce workloads on public cloud infrastructure. Few large organizations operate exclusively on-premises anymore, and managing a consistent operational posture across private, public, and hybrid environments is genuinely hard.

Why Manual Cloud Orchestration Doesn’t Scale

Manually deploying and configuring cloud infrastructure — server clusters, storage, virtual networks, load balancers, and the applications that run on top of them — is time-consuming and error-prone. When each environment must be configured by hand, IT teams face several compounding problems:

• Slow provisioning cycles: Standing up individual virtual machines or services one at a time creates bottlenecks that delay projects.
• Configuration drift: Inconsistent manual processes lead to environments that diverge from intended state, making troubleshooting harder.
• Operational overload: Teams that spend time on repetitive provisioning tasks have less capacity for higher-value engineering work.
• Governance gaps: Without automated policy enforcement, resource allocation and access controls become difficult to audit consistently.

All of this complexity slows the software delivery lifecycle and creates delays for business-critical processes — the opposite of what the business needs from IT.

What Cloud Automation Actually Does

Cloud automation removes the manual steps from provisioning, configuration, and lifecycle management of cloud resources. Instead of an operator configuring each component individually, an automation platform applies pre-defined templates and policies to deploy entire stacks with minimal human intervention.

A practical example: spinning up a fleet of identically configured virtual machines across a cloud region. Without automation, each VM requires individual setup. With automation, the operator selects a template, sets a handful of parameters, and the platform handles deployment — consistently, at scale, and without requiring an operator to babysit the process.

The same principle applies regardless of whether the target infrastructure is private cloud, a public cloud provider, or a hybrid combination of both.

Key Capabilities of a Cloud Automation Platform

Self-Service Catalogs

A well-designed automation platform exposes a self-service catalog that lets developers and operators request approved resources — virtual machines, databases, network segments, application stacks — without filing tickets or waiting for manual intervention. The catalog abstracts the underlying complexity while keeping provisioning within policy guardrails.

Infrastructure Templates

VM templates and infrastructure-as-code definitions encode the desired configuration of a resource or environment. Tools such as Terraform, AWS CloudFormation, Azure Resource Manager templates, and Pulumi are widely used to define infrastructure declaratively. The automation platform applies these templates repeatably, reducing configuration variance.

Policy-Based Governance

Automation without governance creates sprawl. Policy-based controls ensure that resources are provisioned with appropriate size, network access, security configuration, and tagging — automatically, as part of the provisioning workflow. This makes compliance and cost management enforceable rather than aspirational.

Multi-Cloud and Multi-Vendor Support

Enterprise environments typically involve multiple cloud providers and on-premises systems. Effective automation platforms abstract provider-specific differences, allowing a consistent provisioning and management experience across AWS, Azure, GCP, and private infrastructure. This “pervasive automation” — uniform across all deployment targets — is the goal for mature cloud operations teams.

Lifecycle Management and Monitoring

Automation doesn’t stop at provisioning. A complete orchestration approach covers the full resource lifecycle: deployment, configuration, scaling, health monitoring, updates, and decommissioning. Automated health checks and remediation reduce the operational burden of keeping complex environments running reliably.

Cloud Automation vs. Cloud Orchestration: A Useful Distinction

These terms are often used interchangeably but refer to different layers of capability:

• Automation refers to executing a specific task without human intervention — for example, automatically resizing a VM when CPU utilization exceeds a threshold.
• Orchestration refers to coordinating multiple automated tasks across systems to achieve a higher-level outcome — for example, provisioning a complete three-tier application environment including networking, compute, and database layers in the correct sequence.

In practice, modern DevOps toolchains use both together. Automation handles individual tasks; orchestration coordinates workflows across those tasks and across services.

Business Impact: Why This Matters Beyond IT

When cloud provisioning is slow or error-prone, it creates downstream delays across the business. Development teams wait for environments. Releases are held up. Incident response is slower because replicated environments are hard to stand up quickly.

Cloud automation directly addresses these delays. Faster, reliable provisioning means development teams can iterate more quickly, releases can be deployed with greater confidence, and infrastructure can scale in response to demand without requiring manual intervention at each step.

For organizations operating across hybrid or multi-cloud environments, automation also provides the consistency needed to maintain security and compliance posture without duplicating effort across each environment manually.

Getting Started: Practical Considerations

• Audit current provisioning workflows to identify where manual steps introduce the most delay or risk.
• Start with repeatable, well-understood workloads — standardized VM configurations or common application stacks — before automating more complex environments.
• Invest in infrastructure-as-code practices early; automation depends on having infrastructure defined in a form that tools can consume and version-control.
• Define governance policies before automating at scale — enforcing tagging, sizing limits, and network controls from the start prevents costly sprawl later.
• Evaluate tooling against your actual environment: the right platform depends on which cloud providers and on-premises systems you need to support.

Summary

Cloud automation and orchestration are not optional optimizations for mature engineering organizations — they are foundational to operating at the speed modern businesses require. By replacing manual provisioning with template-driven, policy-governed automation across private, public, and hybrid infrastructure, teams reduce delivery time, improve consistency, and free up engineering capacity for higher-value work. The principles described here have only become more relevant as cloud environments have grown more complex since this topic was first widely discussed.

Attribution: This article is based on content originally published by Opsview (opsview.com). Product claims reflect Opsview’s own documentation and marketing materials as of the original publish date (April 2017) and may not reflect the current product. Readers should verify current feature availability directly with the vendor.

Why Nagios Core Has Limits for Complex Environments

Nagios Core is free, flexible, and has a vast plugin ecosystem—but those strengths come with trade-offs. Configuration is entirely file-based, and a single syntax error can halt all monitoring activity. There is no built-in graphical configuration interface, no native SNMP trap handling, and no out-of-the-box SLA reporting. For a small, relatively static environment managed by an experienced Nagios administrator, these gaps are manageable. For larger, fast-changing environments with multiple teams and stakeholders, they become significant operational burdens.

The sections below cover the key capabilities that organisations typically need once they move beyond a basic Nagios deployment.

Usable Configuration Interface

One of the most immediate pain points with Nagios Core is its configuration model. Hosts, services, contacts, and escalation rules are all defined in flat text files. There is no validation layer beyond what Nagios checks at startup, and a misconfiguration silently breaks monitoring until it is fixed and the daemon is restarted.

Platforms built on top of Nagios—such as Opsview, Icinga, or Naemon—typically provide a web-based configuration UI that abstracts away the raw config files. This lowers the barrier to entry, reduces the risk of configuration errors, and allows non-expert team members to manage monitoring without needing to understand Nagios internals.

Role-Based Dashboards

Nagios Core’s default web interface presents a unified view of host and service states that is functional but not tailored to different audiences. In practice, a Windows systems administrator, a Linux administrator, a network engineer, and a business manager all need different views of monitoring data.

Enterprise monitoring platforms address this with role-based, customisable dashboards. Common capabilities include:

• Drag-and-drop dashboard builders that let administrators compose views from widgets such as service summary panels, performance graphs, and gauges.
• Role assignment so that a user logging in sees only the dashboards and data relevant to their responsibilities.
• Business service grouping that maps low-level host and service checks to higher-level business outcomes, often visualised with simple traffic-light status indicators.
• Read-only dashboard sharing for non-technical stakeholders such as executives or external clients who need visibility into service health without access to configuration.

Managed service providers (MSPs) can use role-based dashboards to give individual clients a view of their own SLA data without exposing other tenants’ information.

Auto-Discovery

In Nagios Core, every host and service must be defined manually in configuration files. In dynamic environments—where virtual machines are spun up and torn down regularly, or cloud workloads scale in and out—keeping configuration in sync with reality is a significant maintenance task.

Auto-discovery features scan networks, query cloud provider APIs, or inspect virtualisation platforms to detect new hosts and services automatically, then import them into the monitoring configuration. This is particularly valuable for:

• Initial onboarding of large existing environments.
• Keeping monitoring current in environments with frequent infrastructure changes.
• Reducing the manual effort of configuring monitoring for cloud or virtualised workloads.

Distributed Monitoring

When infrastructure spans multiple data centres, office locations, or cloud regions, a single central Nagios server may not be able to reach all monitored endpoints, and network latency can distort check results. Distributed monitoring architectures address this by placing monitoring nodes (variously called pollers, collectors, or slave servers) close to the resources they monitor.

While Nagios Core can participate in distributed setups using passive checks and NSCA, the configuration and maintenance of this is complex. More capable platforms provide managed distributed architectures where:

• Remote collector nodes are configured and managed centrally.
• Results are aggregated at a master server without requiring administrators to manually manage NSCA pipelines.
• The architecture can scale by adding additional collector nodes without restructuring the entire monitoring setup.

High Availability: Slave and Master Server Clustering

A standalone Nagios instance is a single point of failure. If the monitoring server goes down, you lose visibility across your entire infrastructure—exactly when you may most need it.

Enterprise platforms typically offer two layers of high availability:

• Collector/slave clustering: Multiple collector nodes can be grouped so that monitoring load is automatically balanced across them. If one collector fails, its checks are redistributed to remaining nodes without manual intervention.
• Master server clustering: The central management and reporting server can itself be clustered for redundancy, ensuring that configuration management and dashboards remain available even if a master node fails.

Agentless Windows Monitoring

Monitoring Windows hosts with Nagios Core typically requires installing an agent such as NSClient++ on each Windows machine. This is workable but introduces agent lifecycle management overhead—agents must be deployed, kept up to date, and monitored themselves.

Agentless Windows monitoring uses WMI (Windows Management Instrumentation) to query Windows hosts remotely without any software installed on the target machine. The practical advantages are:

• No agent deployment or maintenance overhead on Windows hosts.
• Easier onboarding of Windows machines in environments where software installation approval processes are slow.
• Flexibility to run agent-based monitoring where higher-frequency or more detailed checks are needed, and agentless monitoring everywhere else.

Flexible Host and Service Grouping

Nagios Core supports hostgroups and servicegroups for organising monitored resources, but these are static groupings defined in configuration files. In complex environments you often need to slice and filter monitored resources in multiple dimensions—by location, by business criticality, by application, by team ownership.

Tagging or keyword systems (as Opsview calls them) allow free-form labels to be applied to hosts and services. A host can carry multiple tags simultaneously, and operators can filter the monitoring view to show only hosts and services matching a particular tag or combination of tags. This provides flexibility that static group membership cannot easily replicate.

Host Attributes for Templated Service Configuration

When you need to monitor the same type of resource across many hosts—for example, a specific disk partition name that differs between servers—Nagios requires either separate service definitions for each host or complex use of custom variables. Host attribute features in more capable platforms let you define a set of variable parameters at the host level and then create service check templates that reference those parameters. The result is that a single service template can generate correctly configured checks across many hosts with different attribute values, dramatically reducing configuration duplication.

Distributed Alerting

In a distributed monitoring architecture, notification reliability matters. If the link between a remote collector and the central master server is lost, you still need alerts to be generated for issues detected at the remote site.

Distributed alerting allows remote collector nodes to send notifications autonomously when they cannot reach the master, ensuring that on-call engineers receive alerts regardless of WAN connectivity issues between monitoring tiers.

Network Mapping and Visualisation

Understanding parent-child relationships between network devices helps engineers quickly determine whether a downstream failure is caused by a genuine problem with that device or is a consequence of a parent device being unreachable. Nagios Core supports parent-child host relationships in its configuration, but visualisation is limited.

Network mapping features in enterprise platforms render these relationships graphically, showing device topology alongside real-time status. This makes it much faster to perform root cause analysis during an incident, particularly in complex multi-tier network environments.

SNMP Trap Processing

Nagios Core is a poll-based monitoring system: it initiates checks against targets on a schedule. It does not natively receive or process SNMP traps, which are unsolicited notifications sent by network devices when specific events occur (such as a link going down or a threshold being crossed).

For environments with significant network infrastructure—routers, switches, UPS units, and other SNMP-capable devices—trap processing is important because it provides near-real-time event notification that poll-based checking cannot match. Platforms with integrated SNMP engines can receive traps, parse them against MIB definitions, apply filtering rules, and translate them into monitoring alerts through the same interface used for all other checks.

Configuration Cloning

When adding hosts or services that are similar to existing ones, being able to clone an existing configuration and modify only the differing attributes saves significant time compared to building each configuration from scratch. This is especially useful during onboarding of new infrastructure where many similar devices need to be added quickly.

SLA and Availability Reporting

Nagios Core logs state history, but generating formatted SLA and availability reports from that data requires additional tooling. In practice, many teams end up manually compiling availability figures from log data—an error-prone and time-consuming process.

Enterprise monitoring platforms typically include reporting engines that can:

• Generate availability and SLA reports for specified hosts, services, or business service groups over configurable time periods.
• Schedule automatic report delivery by email.
• Export reports in multiple formats (PDF, HTML, spreadsheet formats) suitable for different audiences.

Service Desk Integration

When monitoring generates an alert, the typical operational response is to create a ticket in a service desk system. Doing this manually for every alert introduces delay and relies on on-call staff to act immediately. Automated service desk integration allows monitoring alerts to trigger ticket creation directly in ITSM platforms, eliminating the manual step and ensuring that every alert has an associated ticket for tracking and audit purposes.

Common integration targets include platforms such as ServiceNow, Atlassian Jira Service Management, and similar ITSM tools. The specific integrations supported vary by monitoring platform and version.

Flexible Notification Profiles

Nagios Core supports notification escalations and time-period-based notification suppression, but configuring fine-grained notification routing is complex. The result in many Nagios deployments is that teams receive too many alerts, or alerts go to the wrong people, leading to alert fatigue and missed incidents.

Notification profile systems let administrators configure rules such as:

• Send email alerts for a specific service only during business hours.
• Send SMS alerts for critical e-commerce services at any hour.
• Route alerts for Windows services to the Windows team, and Linux service alerts to the Linux team.
• Automatically create service desk tickets for high-severity alerts and assign them to the relevant engineer group.

APIs for Automation and Integration

In modern DevOps and infrastructure-as-code workflows, monitoring configuration needs to be manageable programmatically—not only through a web UI. REST APIs for monitoring platforms allow teams to:

• Automate the addition and removal of hosts and services as infrastructure changes (for example, integrating with Terraform or Ansible).
• Query current monitoring state from other tooling or dashboards.
• Trigger configuration reloads or acknowledgements from CI/CD pipelines.
• Integrate monitoring data into broader IT management or observability platforms.

Mobile Access

On-call engineers need to check monitoring status and acknowledge alerts from mobile devices. While Nagios Core’s web interface can be accessed via a mobile browser, dedicated mobile applications provide a better experience with features such as push notifications that alert engineers even when the app is not in the foreground.

Commercial Support

Nagios Core is community-supported. For test environments and non-critical monitoring this is generally acceptable, but for monitoring that underpins production infrastructure, having access to vendor support with defined response times is important. Commercial monitoring platforms built on Nagios foundations typically offer tiered support plans backed by engineers familiar with the product internals.

Evaluating Your Options

Nagios Core remains a viable starting point for many environments, and a significant ecosystem of Nagios-compatible tools, plugins, and extensions exists. However, the features described in this article—configuration UI, role-based dashboards, auto-discovery, distributed monitoring, HA clustering, agentless Windows monitoring, SNMP trap processing, SLA reporting, service desk integration, and automation APIs—represent a meaningful capability gap between bare Nagios Core and what most production IT operations teams need.

When evaluating whether to extend Nagios Core with additional tooling or move to a more complete platform, map your operational requirements against these capabilities and assess both the initial configuration cost and the ongoing maintenance burden of each approach.

Alternatives in the Nagios ecosystem and broader monitoring space include Icinga 2, Naemon, Zabbix, Opsview, and others. Each has different strengths, licensing models, and integration ecosystems. The right choice depends on your infrastructure scale, team skills, and budget.

Suddenly, on-shoring is becoming more in vogue. Like many U.S. CIOs and their C-suite colleagues, you may be actively exploring how to duplicate or offset the loss of cost benefits from offshore/labor-arbitrage services. I have good news for you, along with a crucial tip.

Four primary factors are driving U.S. companies to make the move to onshore service delivery:

• Uncertainty associated with the potential of changing tax laws and border taxes, which could introduce a tax of 20 to 30 percent on services done offshore.
• Potential changing regulations and increasing regulatory pressures to relocate work from offshore resources to the U.S.
• Potential of reputation damage of companies called out publicly in the news media for use of offshore workforces.
• Uncertainty around rising costs due to changing immigration laws and use of H-1B visas, which could make offshoring more expensive for service providers and increase barriers.

Although these factors vary by industry and company, the net result is companies are looking even more closely at digital technologies and digital business models to offset the cost benefits of offshoring.

Let’s look at how these digital models apply to IT.

IT infrastructure

Many firms support their legacy infrastructure offshore and have significant teams in what is called Remote Infrastructure Management Outsourcing (RIMO) done offshore. A digital model applies to this in two ways:

1. Cloud. It will accelerate the move to private and public cloud models. When you move to the cloud, you move into a highly automated environment, thus dramatically lowering the number of people to support the infrastructure. You can use that savings, and potentially the necessary support people can be more easily afforded onshore.
2. Automation. By applying automation tools to the legacy IT infrastructure, you can dramatically reduce the number of people needed to support the legacy environment, once again making it more affordable to have the remaining people operate out of the U.S. instead of offshore. For example, you can eliminate 40 percent of the FTEs by using tools such as IPSoft’s Autonomics (featuring virtual engineers and toolset for all components of IT service management) or TCS’s Ignio (a cognitive system for enterprise IT operations). These digital models and technologies change the economics, making it much more affordable to do this work onshore rather than offshore.

DevOps Toolkit

Applying the DevOps set of tools (self-provisioning, automated testing, agile methodologies) in an IT shared services organization creates up to a 30 percent productivity benefit. A 30 percent increase in productivity goes a long way to offsetting some of the offshore/onshore cost issues.

In truth, these productivity gains can be captured using an offshore model. So the argument is a little more complicated because the opportunity to apply DevOps tools and techniques to shared services is independent of location. But if you adopt them, it will lessen the impact of moving work back onshore.

In a DevOps model, it’s necessary to move to cross-functional teams in pods aligned to the business that operate from app development through IT infrastructure. Designed to be highly productive teams, these IT employees naturally want to be close to the business users – therefore onshore. Using this model, we find companies enjoying substantial productivity gains well over 100 percent, which more than offset labor arbitrage/offshoring losses.

Automated Testing. The advancements in automated testing (a DevOps tool) enable companies to isolate testing as a separate discipline and automate 60 percent or more of the work. The smaller, more productive footprint of automated testing environments reduces the dependency on low-cost locations for testing, giving companies the freedom to stand up automated tests onshore.

Necessity of changing your business model

There is a caveat to achieving the cost and productivity benefits I described: To get the biggest benefits or breakthrough performance through digital tech and models, your company must fundamentally change its business model.

What does this involve? Digital business models accompanying digital technologies require an end-to-end approach.

Three elements comprise the business model:

• Delivery elements. For product companies, delivery factors affect how their products are made and include such elements as the manufacturing factory, supply chain and logistics. For services companies, delivery factors are how a company delivers services to customers. For example, in an insurance company, the delivery elements affect how the company processes claims.
• Customer-facing elements. These aspects of the business model affect how you touch, reach, or access customers and the value proposition for customers. It includes such components as sales channels, pricing model and customer segments.
• Support elements. These service elements undergird the delivery and customer-facing elements. They include IT infrastructure and operational technologies along with business processes. These elements of your business model affect how you do application development and innovation, the components of your IT infrastructure, your partnering ecosystem and what technologies you implement.

Changing your company’s business model doesn’t just change how the company operates. It is the key to changing the value the company delivers.

If you want to achieve an incremental outcome from digital technology initiatives, it is fine to maintain your current business model. But if you change various elements of your business model, you will achieve big cost and productivity benefits that offset the cost differences between IT services delivered onshore vs. offshore.