VMware Doubles Down on Cloud-Native Leadership with Two Senior Hires

VMware made two significant executive appointments in mid-2020, bringing in cloud-native and channel expertise at the highest level. The company named Carol Carpenter as its new global Chief Marketing Officer and Sandy Hogan as Senior Vice President of Worldwide Commercial and Partner Sales. Both hires signal VMware’s intent to sharpen its messaging around Kubernetes, the Tanzu portfolio, and its growing partner ecosystem.

Carol Carpenter Joins as Global CMO

Carpenter brings more than 25 years of technology marketing experience to VMware. Most recently, she served as Vice President of Product Marketing at Google Cloud, a role she held for approximately three years. During that tenure, she is credited with helping build the Google Cloud brand, go-to-market campaigns, and marketing team during a critical growth phase for the public cloud business.

Before Google, Carpenter was CEO of ElasticBox, a cloud application management platform that was acquired by CenturyLink. She has also held senior marketing and leadership positions at Trend Micro, Keynote Systems, and ClearSide.

“I believe that containers are the operating system of the future, and I am excited by what VMware is doing with Kubernetes and Tanzu to help customers accelerate development and run securely at scale. Customers are seeking container-based solutions with all the benefits of cloud-native development and operations.”

— Carol Carpenter, VMware CMO, via LinkedIn

Carpenter described VMware’s strategic market position as “unique,” drawing on her prior experience advising enterprises during her time at Google Cloud:

“In this multi-cloud world, enterprises are seeing the complexity of management, compliance, security — become more and more unwieldy. With its broad and deep portfolio, VMware offers customers an opportunity to simplify all that complexity. Enterprises need a trusted business partner who will meet them where they are and take them where they want to go.”

— Carol Carpenter

What the Hire Signals for Kubernetes and Tanzu

Carpenter’s background in cloud-native product marketing is directly relevant to VMware’s strategic priorities at the time. VMware had been investing heavily in Kubernetes — most visibly through its Tanzu portfolio, which provides tools for building, running, and managing containerized applications across on-premises and multi-cloud environments. Bringing in a CMO with deep Kubernetes-adjacent experience from Google Cloud, where Kubernetes originated, was a clear signal that VMware intended to compete aggressively in the cloud-native market.

Stephen Ayoub, president of AHEAD, a Chicago-based VMware partner, commented on the strategic significance of the appointment:

“The hiring of Carol from Google Cloud reinforces VMware’s commitment to both cloud and modern applications as the main pillars of the company’s digital infrastructure portfolio going forward.”

— Stephen Ayoub, President, AHEAD

Sandy Hogan Named SVP of Worldwide Commercial and Partner Sales

Alongside Carpenter’s appointment, VMware hired Sandy Hogan as Senior Vice President of Worldwide Commercial and Partner Sales. Hogan is tasked with leading VMware’s renewed partner ecosystem strategy and commercial go-to-market motion.

Hogan spent approximately 15 years at Cisco (2002–2017) in a range of senior roles, including Global Vice President of the Digital Transformation Group and Vice President of Business Transformation. Most recently before joining VMware, she served as Executive Vice President and Americas Managing Director at Rackspace.

“I’ve been blessed to work for some amazing companies and with amazing people — and have learned a great deal from the lesser-than experiences. And now, the best is yet to come with world-class VMware. Ready to realize what’s possible.”

— Sandy Hogan, via LinkedIn

AHEAD’s Ayoub said Hogan’s appointment demonstrates VMware’s “commitment to the channel and its expanding partner ecosystem” — a priority as VMware sought to grow indirect revenue through VARs, MSPs, and cloud service providers during a period of significant portfolio expansion.

Context: VMware’s Position in 2020

At the time of these appointments, VMware was navigating a complex competitive landscape. The company had recently completed its acquisition of Pivotal and Carbon Black, and was integrating these capabilities into a broader platform play. The COVID-19 pandemic had also accelerated enterprise demand for cloud infrastructure and remote-work enablement, increasing the urgency of VMware’s cloud-native and hybrid cloud messaging.

Hiring a CMO with direct cloud-native marketing experience and a partner sales leader with deep channel credentials from Cisco was consistent with VMware’s effort to grow both mindshare and market reach in an increasingly competitive environment that included AWS, Microsoft Azure, Google Cloud, and Red Hat.

Key Takeaways

• Carol Carpenter joined VMware as global CMO with 25+ years of experience, most recently as VP of Product Marketing at Google Cloud.
• Her appointment underscored VMware’s strategic focus on Kubernetes and the Tanzu portfolio as central to its cloud-native message.
• Sandy Hogan joined as SVP of Worldwide Commercial and Partner Sales, bringing extensive channel expertise from Cisco and Rackspace.
• Both hires were interpreted by VMware partners as a clear signal of the company’s commitment to cloud-native development and channel growth.
• The appointments came at a time when enterprises were accelerating cloud adoption amid the COVID-19 pandemic.

JFrog Takes swampUP Virtual for 2020

JFrog, the enterprise DevOps platform company behind the concept of “Liquid Software,” announced in June 2020 that its annual community conference — swampUP — would move entirely online in response to the COVID-19 pandemic. Rather than simply shifting the format, JFrog used the transition as an opportunity to give back: all registration proceeds were donated to COVID-19 charities.

The event was scheduled across two regional windows:

• Americas: June 23–24, 2020
• EMEA & APAC: June 30 – July 1, 2020

Conference Format: Training First, Then the Main Event

swampUP 2020 followed a two-day structure designed to balance practical skill-building with strategic thought leadership:

• Day 1 — Hands-On Training: Specialized instructor-led courses targeting DevOps and DevSecOps practitioners. Sessions were designed to give attendees immediately applicable skills in areas such as automation, container management, and security practices.
• Day 2 — Main Conference: An industry keynote followed by more than 30 breakout sessions organized into four tracks:
  • Cloud Native
  • DevSecOps
  • Enterprise DevOps
  • Digital Transformation

Speakers and contributors came from organizations including Google, Microsoft, and Adobe, among others.

Featured Speakers

JFrog assembled a roster of well-known DevOps practitioners and industry voices for the event, including:

• Kohsuke Kawaguchi — Co-CEO, Launchable, Inc., and creator of Jenkins
• John Willis — Vice President of DevOps and Digital Practices, Red Hat
• Wayne Chatelain — Senior Manager of Software Engineering, Capital One
• Jessica Deen — Azure Avenger (Microsoft cloud and developer advocacy)

DevOps With a Mission: Charitable Giving in Unprecedented Times

The decision to donate all registration proceeds to COVID-19 research was central to the 2020 event’s identity. JFrog co-founder and CEO Shlomi Ben Haim framed the initiative as an extension of the company’s community-first philosophy:

“Since JFrog’s inception, we’ve partnered with the community to bring top tools and methodologies to the market, always with the developer in mind. Community safety also means we can’t all be together in the usual way, but the need to share is still there. We wanted to partner again with the open-source and DevOps communities and deliver not only the top-shelf content they’re used to from swampUP, but also to give back to our global communities as we collectively accelerate the cure for this virus.”

— Shlomi Ben Haim, Co-Founder and CEO, JFrog

Key Topics Covered at swampUP 2020

The sessions were designed to address the state of modern software delivery, with particular emphasis on:

• Software distribution — Managing binaries and release artifacts at scale
• Container ecosystems — Docker image management, Kubernetes integration, and container security
• Automation — CI/CD pipeline design and toolchain integration
• Security (DevSecOps) — Shifting security left and integrating vulnerability scanning into the development lifecycle
• Package management — Universal artifact repository strategies using tools like Artifactory

About JFrog

JFrog is an enterprise DevOps platform company whose products — including Artifactory, Xray, and Pipelines — are used to manage, secure, and distribute software from code to production. The company describes its mission as enabling “Liquid Software”: a model in which software updates flow continuously and securely to end users with zero downtime. As of the 2020 announcement, JFrog reported serving more than 5,600 enterprise customers across industries. JFrog products are available as open-source and commercial editions, with cloud hosting options on AWS, Microsoft Azure, and Google Cloud Platform.

swampUP Session Playlist

1. Serverless Computing: Event-Driven Execution Without Infrastructure Overhead

Serverless computing lets development teams deploy discrete functions that execute on demand, triggered by events — HTTP requests, queue messages, scheduled jobs, and more. The cloud provider handles all provisioning, scaling, and maintenance of the underlying servers. Teams pay only for the compute time consumed during function execution, not for idle capacity.

This model delivers several practical advantages for engineering teams:

• Reduced operational burden: No operating-system patching, capacity planning, or server fleet management.
• Automatic scaling: Functions scale from zero to thousands of concurrent executions transparently.
• Faster iteration: Developers focus on business logic rather than infrastructure plumbing.
• Cost efficiency at low traffic volumes: Idle periods incur no compute costs.

Major platforms — AWS Lambda, Azure Functions, and Google Cloud Functions — have matured significantly, with improved cold-start times, richer trigger integrations, and support for long-running workloads via durable function patterns. Serverless is particularly well suited to microservice back-ends, data-processing pipelines, scheduled automation, and event-driven architectures.

Adoption challenges remain. Debugging distributed serverless systems, managing function dependencies, and avoiding vendor lock-in on proprietary runtimes are active concerns for platform and DevOps engineers. Open standards such as CloudEvents and portable runtimes (Knative on Kubernetes) address some of these concerns.

2. Hybrid Cloud: Balancing Control, Compliance, and Scalability

A hybrid cloud architecture combines a private cloud or on-premises environment with one or more public cloud providers, connected by a network that enables data and application portability. This approach has become the dominant enterprise deployment model because it addresses a fundamental tension: regulated industries and large enterprises need the control and data-residency guarantees of private infrastructure, while also needing the elastic capacity and managed services of the public cloud.

Key operational benefits of hybrid cloud include:

• Data sovereignty and compliance: Sensitive data can remain on-premises or in a private cloud while non-sensitive workloads burst to the public cloud.
• Latency optimisation: Workloads that require low-latency access to on-premises systems stay close to the data source.
• Cost optimisation: Steady-state workloads run on reserved or owned capacity; variable peaks burst to pay-as-you-go public cloud.
• Resilience: Distributing workloads across environments reduces single points of failure.

Technologies such as Azure Arc, AWS Outposts, and Google Anthos extend public cloud control planes into private data centres, enabling consistent management, policy enforcement, and developer experience across both environments. Kubernetes plays a central role in hybrid cloud portability, as the same container workloads can run on-premises or in any public cloud with minimal modification.

3. Containers and Kubernetes: The Standard Runtime for Modern Applications

Containers package an application and its dependencies into a portable, immutable unit that runs consistently across development laptops, CI pipelines, and production clusters. This portability solves one of the oldest problems in software delivery: environment drift between development, staging, and production.

Kubernetes has become the de facto orchestration layer for container workloads. It automates deployment, scaling, self-healing, and network routing for containerised applications. Key Kubernetes capabilities relevant to enterprise DevOps teams include:

• Declarative configuration: Desired state is declared in YAML manifests; Kubernetes continuously reconciles actual state to match.
• Horizontal pod autoscaling: Workloads scale out or in based on CPU, memory, or custom metrics.
• Rolling updates and rollbacks: New versions are deployed incrementally with automatic rollback on failure.
• Service mesh integration: Tools such as Istio and Linkerd layer traffic management, observability, and mTLS security on top of Kubernetes services.

Managed Kubernetes services — Amazon EKS, Azure AKS, and Google GKE — have reduced the operational complexity of running control planes, making Kubernetes accessible to teams without dedicated platform engineering specialists. The CNCF ecosystem surrounding Kubernetes (Helm, Argo CD, Flux, Prometheus, and others) provides a rich toolchain for GitOps, observability, and policy enforcement.

4. AI and Machine Learning Workloads in the Cloud

The cloud has become the primary platform for training and serving machine learning models. Managed services such as Amazon SageMaker, Azure Machine Learning, and Google Vertex AI provide on-demand access to GPU and TPU compute, managed experiment tracking, model registries, and inference endpoints — without requiring teams to manage specialised hardware.

Within data centres themselves, AI is being applied to operational problems:

• Predictive maintenance: Anomaly detection models identify hardware degradation before failure, reducing unplanned downtime.
• Energy optimisation: ML models adjust cooling and power distribution dynamically, reducing energy consumption in large-scale facilities.
• Capacity planning: Forecasting models predict resource demand trends, enabling more accurate procurement and right-sizing decisions.
• Security: AI-driven threat detection identifies unusual access patterns and potential intrusions in real time.

For DevOps and platform engineering teams, the practical implication is an increasing need to support MLOps pipelines — reproducible, versioned workflows for data preparation, model training, evaluation, deployment, and monitoring — using the same infrastructure-as-code and CI/CD practices applied to application workloads.

5. The Digital-Native Workforce and Cloud-First Culture

Cloud adoption is not purely a technology problem — it is equally an organisational and cultural one. Engineering teams increasingly expect cloud-native tooling as table stakes: self-service infrastructure provisioning, infrastructure as code, ephemeral environments, and fully automated CI/CD pipelines. Organisations that still rely on manual ticketing systems for infrastructure requests face a talent retention disadvantage.

Internal developer platforms (IDPs) have emerged as a response to this expectation. By abstracting Kubernetes and cloud primitives behind developer-friendly interfaces — using tools such as Backstage, Port, or Humanitec — platform engineering teams enable application developers to deploy and operate services without deep infrastructure expertise, while maintaining guardrails for security and cost governance.

Upskilling existing engineering staff remains critical. Cloud providers offer certification paths (AWS Certified Solutions Architect, Google Cloud Professional Cloud Architect, Microsoft Azure certifications), and organisations are increasingly funding structured learning programmes to close the gap between current capabilities and the skills required for cloud-native operating models.

What This Means for DevOps Teams

These trends converge on a common theme: the cloud is no longer a destination but an operating model. Successful DevOps and platform engineering teams are those that treat infrastructure as software, automate everything repeatable, and build platforms that accelerate developer productivity without sacrificing security or reliability.

• Evaluate serverless for event-driven workloads to eliminate idle compute costs and operational overhead.
• Adopt Kubernetes as the common runtime layer to enable hybrid and multi-cloud portability.
• Invest in GitOps practices (Argo CD, Flux) to make infrastructure changes auditable, reviewable, and reversible.
• Build MLOps capabilities alongside existing DevOps pipelines as AI workloads grow.
• Prioritise internal developer experience to attract and retain cloud-native engineering talent.

Cloud technology continues to evolve rapidly. Staying current requires not just tracking new service announcements but understanding how these capabilities compose into coherent, production-grade architectures that meet real business requirements.

Remote Work and DevOps: An Unlikely Acceleration

For many organizations, DevOps has long felt aspirational rather than operational. The DevOps Institute has reported that more than half of organizations still struggle to scale DevOps effectively — and that was before distributed work became the default. When teams suddenly went remote, the conventional wisdom was that alignment between development and operations would become harder, not easier.

What many teams discovered instead was the opposite: remote work quietly removed several of the cultural obstacles that had been holding DevOps back. Understanding why requires stepping back from tooling and automation, and focusing on what DevOps is really about — communication, collaboration, and shared ownership of outcomes.

Why Physical Proximity Was Holding DevOps Back

One of the most persistent barriers to DevOps adoption is organizational silos. When development teams and operations teams sit in separate parts of an office — or worse, separate floors or buildings — an implicit “us versus them” dynamic tends to form. Informal clusters reinforce tribal thinking. Hallway conversations happen within teams, not across them.

Remote work dissolves those physical boundaries. When every team member joins the same video call or Slack channel, proximity bias disappears. A developer in one city and an SRE in another are, from a collaboration standpoint, on equal footing. The playing field is flattened by default.

This structural change matters because DevOps transformation is fundamentally a people and culture problem, not a technology problem. Introducing CI/CD pipelines or infrastructure-as-code does not automatically produce a DevOps culture. Genuine cross-functional collaboration does.

How Distributed Work Drives Cross-Functional Collaboration

In a remote environment, collaboration must be intentional and structured. Spontaneous hallway conversations no longer derail processes or create information asymmetry. Instead, communication happens through scheduled meetings, video calls, and persistent messaging channels — all of which are inherently more inclusive and auditable.

This intentionality aligns well with core DevOps principles:

• Transparency: Decisions made in Slack threads or recorded video calls are visible to the whole team, reducing the hidden knowledge that fuels silos.
• Shared responsibility: When everyone joins the same digital workspace, ownership of the full software delivery lifecycle becomes less territorially guarded.
• Continuous feedback: Asynchronous communication tools make it easier to document retrospectives, post-mortems, and process improvements in a form the entire organization can reference.

The economic pressures that accompanied the shift to remote work also played a role. Faced with urgency to innovate and serve rapidly changing customer needs, organizations began treating DevOps as a strategic necessity rather than an IT experiment. That executive buy-in — historically one of the hardest things to secure — became far easier to obtain when digital delivery was the only delivery channel available.

The Risk: Reverting When the Office Reopens

The critical question is whether the cultural gains from remote work will survive a return to the office. History suggests that organizational culture is sticky in both directions — it is hard to change, but it is also hard to un-change once genuinely embedded.

CIOs and engineering leaders have a window of opportunity. The collaborative habits formed during distributed work can be preserved if leadership actively reinforces them rather than defaulting to pre-pandemic norms. The risk is that without deliberate effort, physical co-location will gradually rebuild the silos that remote work dissolved.

4 Practical Tips for CIOs to Sustain a DevOps Culture

Whether your organization is fully remote, hybrid, or returning to the office, these four practices can help preserve the collaborative culture that accelerated DevOps adoption.

1. Prioritize Video Over Voice

Video calls are significantly more effective than audio-only communication for cross-functional collaboration. Non-verbal cues — body language, facial expressions, engagement — are visible, which reduces misunderstandings and keeps participants more accountable. Where possible, default to video for team meetings and cross-functional syncs, even after returning to a shared office for some sessions.

2. Resist the Pressure to Rush Back to Old Habits

If asynchronous communication and distributed collaboration have improved how your teams work, do not abandon those practices simply because the office is available again. Gather feedback from your engineers, SREs, and product managers. Measure delivery metrics before and after any structural change. Let data and team input guide decisions about how and where work happens, rather than defaulting to pre-pandemic norms.

3. Make Communication a Structural Priority

DevOps is a people transformation before it is a technology transformation. Active listening, clear escalation paths, and regular cross-functional retrospectives are not soft skills — they are engineering infrastructure. Build them into your team rituals deliberately. Document decisions. Share context widely. Treat communication as a first-class engineering concern, not an afterthought.

4. Celebrate DevOps Milestones Visibly

Recognizing progress matters. When a deployment pipeline reduces release cycle time, or when a post-mortem process prevents a repeat incident, call it out. Share the business impact. Connect engineering outcomes to customer or revenue outcomes wherever possible. Visible celebration reinforces the behaviors you want to sustain and gives teams a concrete reason to remain invested in the transformation.

Key Takeaways

• Remote work removed physical silos that were actively blocking DevOps adoption at scale.
• Intentional, structured communication in distributed teams aligns naturally with core DevOps principles.
• The cultural gains from distributed work are not automatic — they require deliberate reinforcement from engineering and business leadership.
• CIOs who treat this period as a foundation rather than a temporary exception will be better positioned to sustain long-term DevOps maturity.

The relationship between remote work and DevOps success is not coincidental. The same disciplines that make distributed teams function well — transparency, shared ownership, structured communication, and continuous improvement — are the disciplines that make DevOps work. Leaders who recognize this overlap and protect it will be the ones who carry the transformation forward.

Overview

When COVID-19 lockdowns began in early 2020, IT professionals did not stop learning — they accelerated. According to data published by MeasureUp, a global provider of practice tests for ICT certifications and an official partner of Microsoft, VMware, and others, demand for digital skills training surged sharply in the weeks following national states of emergency. The leading areas of interest were cloud computing, cybersecurity, and web programming, alongside growing interest in artificial intelligence and big data.

Why These Technologies Saw a Spike

The shift to remote work created immediate, practical demand for skills that support distributed infrastructure and digital operations:

• Cloud computing became essential for organisations moving workloads off-premises and enabling remote access to business systems.
• Cybersecurity grew in urgency as expanded attack surfaces — home networks, personal devices, VPNs — exposed organisations to greater risk.
• Web programming and digital presence became a lifeline for businesses that previously operated solely in physical spaces and needed to pivot online quickly.

Top Cloud Computing Certifications in Demand

Microsoft Azure certifications dominated MeasureUp’s best-seller lists during the lockdown period. The most popular titles included:

• Microsoft Azure Fundamentals (AZ-900) — an entry-level certification covering core cloud concepts, widely used as a starting point for professionals new to cloud platforms.
• Microsoft Azure Solutions Architect (AZ-300)
• Microsoft Azure Architect Design (AZ-301)
• Microsoft Azure DevOps Solutions (AZ-400)

Amazon Web Services (AWS) certifications also featured prominently:

• AWS Certified Solutions Architect
• AWS Certified Developer

The strong showing of AZ-900 in particular reflects how many professionals used the lockdown period to establish foundational cloud literacy before pursuing more advanced credentials.

Cybersecurity Certifications Gaining Traction

Alongside cloud skills, cybersecurity certification demand rose in direct response to the heightened threat environment of remote work. The most-requested cybersecurity exams on the MeasureUp platform included:

• CompTIA Cybersecurity Analyst (CySA+) — focused on threat detection, analysis, and response.
• CISSP (Certified Information Systems Security Professional) — a senior-level credential covering security architecture and management.
• CompTIA Security+ — an industry-standard entry-level security certification widely recognised by employers.

Web Programming: HTML, C#, and .NET

An emerging and somewhat unexpected trend in the lockdown data was increased demand for web programming skills. Technologies including HTML, C# (C-Sharp), and .NET saw notable upticks, driven by businesses that needed to rapidly build or improve their online presence. For many traditionally offline businesses — retail, hospitality, professional services — digital transformation went from a medium-term strategy to an immediate operational necessity.

AI and Big Data: A Growing but Secondary Trend

Practice tests related to Artificial Intelligence and Big Data also showed increased sales during the lockdown period. Microsoft technologies were noted as particularly prominent within this category, though specific certifications were not detailed in the original report.

Who Was Training? Learner Demographics

MeasureUp analysed the profiles of professionals who engaged in training activities during the COVID-19 crisis. Key findings from their platform data:

Age Distribution

• ~60% were professionals aged 25–44
• 16% were under 25 years old
• 4.61% were aged 65 and over — a notable segment, suggesting lockdown motivated older professionals and retirees to upskill

Gender Split

• 75% male
• 25% female

The gender imbalance reflects the broader demographic reality of the ICT certification market, though it also underscores the ongoing need for greater inclusivity in technical training pathways.

Geographic Origin (Top 10 Countries)

Learners from all five continents participated, reflecting MeasureUp’s global reach, though the English-speaking market dominated the figures.

Remote Exam Delivery: A Critical Enabler

A key factor enabling certification activity during lockdown was the widespread adoption of remote proctoring by major certification bodies. Vendors including Microsoft, Cisco, VMware, AWS, CompTIA, PMI, and Oracle all offered candidates the ability to sit official exams from home, removing the dependency on physical test centres that had temporarily closed. This made the complete training-to-certification pipeline accessible entirely online for the first time at scale.

About MeasureUp

MeasureUp is a product of Media Interactiva, a technology and educational content group headquartered in Tomares, Seville, Spain. The company reports training more than 400,000 people annually in digital skills. MeasureUp operates as the exclusive practice-test provider for Microsoft and also supports AWS, Cisco, CompTIA, Oracle, PMI, and VMware certification programmes, offering over 200 titles.

Practice tests on the platform can be used in two modes:

• Certification mode — simulates exam conditions as closely as possible.
• Practice mode — allows learners to review explanations and focus on weaker areas.

Media Interactiva has been listed in the Financial Times FT 1000 ranking of Europe’s fastest-growing companies and holds ISO-20000 certification for IT service management quality.

Key Takeaways for IT Professionals and Training Teams

• The pandemic accelerated pre-existing trends toward cloud and security certification — not created them from scratch.
• Entry-level cloud credentials (such as AZ-900) saw strong uptake, indicating many professionals used the period to formalise existing knowledge or begin a cloud learning path.
• Remote proctoring removed a significant barrier to certification and is likely to remain a standard option post-pandemic.
• Demand for web development skills alongside infrastructure and security credentials signals that full-stack digital capability is increasingly valued across roles.
• The 65+ age group engaging with ICT certification training, while small, is a meaningful signal about the broadening appeal of lifelong technical learning.

Anunta Recognized as VMware’s APJ Services Excellence Partner of the Year

Anunta has announced that it received the VMware 2020 Regional Partner of the Year Award in the Services Excellence category for the Asia Pacific and Japan (APJ) region. The award recognizes VMware partners that demonstrate measurable achievements through their skills and service capabilities — spanning consulting, managed services, and subscription services — to help customers maximize the value of their VMware investments.

Recognition from VMware Leadership

Uma Thana Balsingam, Vice President of APJ Partner Business at VMware, highlighted the significance of the award:

“I am honored to recognize this year’s VMware Global Partner of the Year Award winners, which includes an exceptional group of innovative partners. VMware is proud to see Anunta honored in the Services Excellence category, and we are thrilled to see their continued commitment to delivering exceptional customer outcomes.”

Uma Thana Balsingam, Vice President, APJ Partner Business, VMware

What the Award Means for Anunta

Ananda Mukerji, Chairman of Anunta Tech, framed the recognition in the context of the company’s broader focus on next-generation workspace solutions:

“We are honored to be the regional winner of the VMware Partner of the Year Award 2020 for Service Excellence. I thank our customers for their continued trust in our solutions and delivery capabilities and VMware for recognizing Anunta as a partner they can trust. This is a recognition for Anunta’s innovative solutions around workspaces for the next generation users including cloud-based desktop services.”

Ananda Mukerji, Chairman, Anunta Tech

Sivakumar Ramamurthy, Deputy Managing Director and COO of Anunta Tech, added:

“Anunta has been consistently enabling our customers by providing innovative user-centric EUC solutions for complete workplace transformation. We are extremely delighted for this recognition by VMware. We believe this recognition will further provide an impetus to our strong technical competency and will empower us to enable our customers in achieving tangible business outcomes.”

Sivakumar Ramamurthy, Deputy Managing Director and COO, Anunta Tech

About the VMware Partner of the Year Awards Program

The VMware Partner of the Year Awards program spans multiple categories, each targeting a distinct area of partner contribution and innovation. Categories for the 2020 program included:

• Partner Value
• Partner Social Impact
• Services Excellence
• Digital Transformation
• Cloud Platform Transformation
• Partner Trailblazer
• Global Partner for Technology Innovation

The evaluation process was conducted in partnership with IDC, which reviewed and scored award submissions against the defined criteria for each category. Partners were assessed on their ability to drive measurable customer business growth and ROI, demonstrate deep expertise in specific technology domains, and deliver positive real-world outcomes using VMware technologies.

About Anunta

Anunta is a provider of End-User Computing (EUC) solutions focused on helping enterprises migrate from traditional client-server architectures to unified desktop and application services environments. The company’s portfolio is designed to simplify IT operations while maximizing performance, availability, and cost efficiency at the user endpoint.

Key credentials and scale metrics cited by the company include:

• Over a decade of experience in virtualization and EUC transformation
• Management of 80,000+ endpoints across 120,000+ users
• ISO 20000 certification for IT Service Management (ITSM)
• ISO 27001 certification for Information Security Management (ISMS)
• Recognition as a Red Herring Top 100 Global company

Anunta’s focus on cloud-based desktop services and next-generation workspace delivery positions it within the growing enterprise virtual desktop infrastructure (VDI) and Desktop-as-a-Service (DaaS) market.

What Is Hybrid Cloud and Why Does It Matter?

Cloud computing sits at the heart of most digital transformation programmes — alongside IoT and AI/analytics — yet it is often the least visible in day-to-day operations. Without an integrated data infrastructure, the scale of connectivity and optimisation that transformation promises is simply unachievable. Hybrid cloud pushes the technology further by letting organisations synthesise multiple cloud models — both private and public — into a single, purposefully designed solution that addresses their specific workload, compliance, and cost requirements.

Public Cloud Is Not Always Enough

The wide availability of public cloud platforms — including Microsoft Azure, Google Cloud Platform, and AWS — means most organisations can secure a package that covers basic storage and compute needs. Each provider offers hundreds of features, and some have built industry-specific tooling on top of their core platform (IBM Cloud’s Watson for IoT is a frequently cited example).

However, a single public provider is not always sufficient. Data volumes, regulatory constraints, latency requirements, or the need for dedicated infrastructure can push organisations toward building or leasing private cloud capacity. Once a private cloud is in place, connecting it to one or more public clouds over a sufficiently capable WAN creates the hybrid architecture.

How to Evaluate a Hybrid Cloud Strategy

Eran Brown, CTO of Infinidat EMEA, argues that the evaluation of any hybrid cloud model should focus on four practical dimensions: agility, flexibility, speed-to-market, and cost efficiency. In his words:

“Companies will need to draw a strategic line between how and when they use public and private cloud for data storage. It will be impacted by the quantity of ‘legacy’ data to be stored, as well as what data companies want to ‘own’ or store locally; not all data is suitable for storage in public clouds.”

Eran Brown, CTO, Infinidat EMEA

This means that before committing to a hybrid model, teams should complete three preparatory steps:

1. Define the desired outcomes. Be explicit about what you expect from the hybrid arrangement — lower latency, data sovereignty, cost reduction, or burst capacity.
2. Map data placement rules. Identify which data sets belong on private infrastructure (sensitive, regulated, or high-churn data) and which can safely reside in a public cloud.
3. Model the financial impact. Understand both short-term spend and long-term total cost of ownership before signing contracts.

“Choosing between on-premises and public clouds should not be driven by hype, but rather what will enable units at a cost that is acceptable for the long-term viability of the business.”

Eran Brown, CTO, Infinidat EMEA

The Real Economics of Cloud Storage

Public cloud storage costs are rarely as simple as a headline price per gigabyte. A survey by storage vendor Wasabi (cited in the original Gigabit Magazine article) estimated that customers pay approximately $0.46 per GB/month on Azure, $0.26 on Google Cloud, and $0.23 on AWS — though these figures exclude regional pricing variances, egress fees, and API request costs, all of which can significantly increase real-world bills.

For workloads involving high-resolution video, large image libraries, long-form documents, or extensive transactional archives, these per-GB charges accumulate quickly. As Brown notes:

“As data growth continues unabated, larger organisations will be under increased pressure to more clearly understand the ‘cost vs benefit’ for different storage models as the volume of data expands exponentially.”

Eran Brown, CTO, Infinidat EMEA

On-premises private cloud hardware can offset these costs for data-intensive workloads. Storage vendor Cloudian has published a report claiming that on-premises storage hardware can cost up to 65% less than equivalent public cloud storage. While such estimates are vendor-produced and should be independently validated for your specific workload mix, the directional argument — that public cloud storage can become expensive at scale — is broadly accepted in the industry.

The practical question Brown poses is a useful framing device for any architecture decision:

“The cloud has proven not to be as cheap as businesses were, perhaps, expecting it to be, but what’s the trade-off? Is converting ‘time-to-market’ faster more of a business focus than bottom-line operating costs are?”

Eran Brown, CTO, Infinidat EMEA

Designing a Hybrid Architecture That Works

Hybrid cloud delivers meaningful value only when the private and public components are chosen to complement each other. Key design considerations include:

• Basepoint selection: The private cloud platform you build on (VMware, OpenStack, Nutanix, or a hyperscaler’s on-premises offering such as AWS Outposts or Azure Stack) determines integration complexity and long-term portability.
• Networking: A reliable, low-latency WAN connection — or a dedicated interconnect such as AWS Direct Connect or Azure ExpressRoute — is a prerequisite for consistent performance across the hybrid boundary.
• Data tiering: Define clear policies for hot, warm, and cold data so that active workloads run closest to compute and archive data lands on the cheapest available tier.
• Security and compliance: Identity federation, encryption in transit and at rest, and audit logging must span both environments, not just the public cloud side.
• Avoid over-engineering: For many organisations, augmenting a public cloud with targeted private capacity is more pragmatic than building a fully symmetrical private platform. The goal is solving specific problems, not replicating the hyperscaler’s feature set on-premises.

Beyond Hybrid: The Multi-Cloud Direction

Alongside hybrid cloud, a growing number of enterprises are adopting multi-cloud strategies — deliberately distributing workloads across several public providers and private clouds. Multi-cloud is more operationally complex than a straightforward hybrid model, but it offers concrete benefits:

• Resilience: No single cloud provider becomes a single point of failure.
• Reduced DDoS exposure: Distributing services across providers limits the blast radius of targeted attacks.
• Cost optimisation: Workloads can be placed on the provider offering the best price/performance for that specific task.
• Vendor leverage: Avoiding lock-in preserves negotiating power at renewal time.

Brown sees multi-cloud as the natural evolution for organisations that have already validated a hybrid approach:

“Data gravity issues and digitalisation may result in increased interest in multi-cloud solutions which are better able to compete on price, availability and resiliency.”

Eran Brown, CTO, Infinidat EMEA

Cloud Strategy Defines What Stays On-Premises Too

One of the most overlooked aspects of any cloud strategy is that it is, by definition, also a decision about what does not move to the cloud. Regulatory requirements, data sovereignty laws, latency-sensitive workloads, and intellectual property concerns may all point toward retaining certain systems on-premises indefinitely. Brown’s closing observation captures this well:

“Hybrid cloud models will continue to provide the most commercially resilient solution, especially for those companies that want to take a ‘cloud-first’ approach. A subset of defining a cloud strategy is also to consider that, inadvertently, you are defining what doesn’t go across to the cloud.”

Eran Brown, CTO, Infinidat EMEA

Key Takeaways for DevOps and Infrastructure Teams

• Hybrid cloud is a deliberate architectural decision, not a default landing zone. Evaluate it against specific workload and data requirements.
• Public cloud storage costs grow non-linearly with data volume — model egress, API, and regional fees alongside the headline storage price.
• On-premises private cloud can reduce storage costs for high-volume workloads, but requires upfront capital and ongoing operational expertise.
• The strategic question is not public vs. private — it is which data needs which properties (latency, sovereignty, cost, availability) and which platform delivers them best.
• Multi-cloud is the next logical step for mature hybrid adopters, bringing greater resilience at the cost of increased orchestration complexity.
• Every cloud migration strategy implicitly defines a retention strategy. Make that decision explicitly.

Why Kubernetes Migrations Stall

Software is increasingly the core differentiator for organizations across every industry. Banks describe themselves as software companies that happen to specialize in finance. Retailers frame themselves the same way. The pressure to modernize has driven many enterprises toward containerization and Kubernetes as the presumed solution to engineering scalability problems.

Kubernetes has earned real credibility: it solves hard problems around scheduling, resiliency, and platform consistency. But its reputation as the obvious answer to operational complexity has led many organizations to underestimate the difficulty of actually migrating to it. The result is Kubernetes projects that stretch from months into years, and platforms that are less stable than what they replaced.

Understanding why this happens is the first step to avoiding it.

A Realistic Migration Story

Consider a fictional but representative scenario. A Director of Engineering at a large technology company assigns two capable engineers — call them Allyson and Jorge — to evaluate container orchestration platforms. They do the work properly: they evaluate Docker Swarm, Amazon ECS, and multiple Kubernetes distributions before selecting Kubernetes for well-reasoned technical reasons:

• Deployments as a first-class platform primitive, giving them declarative rollout and rollback control.
• Built-in resiliency through node and container health checking and automatic restarts.
• Sidecar consolidation, allowing log aggregators, metrics agents, and security daemons to run as shared out-of-process containers rather than being independently managed per VM.

With a clear technical direction, they begin migrating a single application — the logical first step. But “one application” rapidly expands in scope once they account for every dependency that application carries:

• Translating VM-based build pipelines into container image build processes.
• Ensuring compliance and security agents work correctly inside containers.
• Adapting deployment pipelines to take advantage of Kubernetes primitives like rolling updates and health probes.
• Documenting organization-specific conventions so other teams can follow the same path.

What looked like a contained task becomes a collection of bespoke solutions. Eight months later, the first application is running on Kubernetes. Allyson and Jorge look around for other teams to migrate — and find almost no takers.

Why Other Teams Won’t Follow

This is a critical moment that many migration efforts misread. The refusal is not irrational. Most engineering teams are measured on feature delivery and system stability. They are not opposed to new technology, but they are conservative about adopting it when the value is unclear and the risk is high.

When Allyson and Jorge ask them to migrate, they are effectively asking each team to:

• Absorb months of reduced delivery velocity.
• Retrain on new tooling and operational practices.
• Accept a less-understood runtime with potential gaps in observability and compliance coverage.
• Trust that implicit migration assumptions — which took Allyson and Jorge months to discover — will not derail their own timelines.

Product owners will rarely approve more than a sprint or two for platform migration work. Eight months is a non-starter. The migration stalls not because Kubernetes is wrong, but because the migration approach failed to account for organizational risk.

The Real Risks in a Kubernetes Migration

Most migration plans start with “How do we deploy to Kubernetes?” Focusing on delivery first is understandable, but it consistently causes teams to treat the following as secondary concerns — often until something breaks:

Security

Container security models differ significantly from VM security models. Network policies, pod security contexts, RBAC configuration, image scanning, and secrets management all require deliberate design. Migrating workloads without addressing these areas produces a platform that is harder to audit and potentially less secure than what it replaced.

Observability

Kubernetes introduces ephemeral workloads, which invalidates many host-centric monitoring assumptions. Log pipelines, metrics collection, alerting rules, and distributed tracing all need to be re-evaluated for a dynamic, container-based environment. Teams that skip this step lose visibility into their own systems.

Compliance and Auditing

Compliance agents, audit logging, and data residency requirements that worked on VMs may not translate cleanly to containers. Validating these requirements before migrating production workloads avoids costly rework — or worse, a compliance incident.

Infrastructure Complexity

Kubernetes itself is operationally complex. Networking (CNI plugins, service meshes), storage (persistent volume provisioning), and cluster lifecycle management (upgrades, node scaling) all introduce new failure modes that need documented runbooks and trained on-call engineers before workloads move to production.

The “Do Everything the Kubernetes Way” Trap

A related failure mode is scope creep driven by enthusiasm for the ecosystem. A migration to Kubernetes quickly becomes a simultaneous migration to containerd, a service mesh like Istio, a GitOps controller like Argo CD or Flux, a new secrets backend, a new logging stack, and a new metrics platform — all at once.

Each of these tools has genuine merit. But adopting all of them simultaneously compounds risk, slows onboarding, and makes it nearly impossible to isolate the cause of any given failure.

As Kelsey Hightower has noted about Kubernetes adoption: “There are no best practices; everyone is just practicing.” The ecosystem evolves quickly, organizational contexts vary enormously, and what works well for one team may be wrong for another. This is not an argument against using these tools; it is an argument for introducing them one at a time, when you have a clear reason and the organizational bandwidth to absorb them.

Structuring a Lower-Risk Migration

The uncomfortable answer to most Kubernetes migration problems is not a clever tool or architectural pattern. It is disciplined incremental delivery — the same principle that led engineering organizations to adopt Agile development in the first place.

Rather than designing the full migration up front and then executing it as a single large project, define milestones that:

• Deliver measurable value independently. Each milestone should produce something a team can use or learn from, not just contribute to a future payoff.
• Are small enough to fit within normal sprint planning. If other teams cannot absorb migration work without special budget approval, the milestones are too large.
• Reduce risk before expanding scope. Prove out security, observability, and compliance requirements on low-criticality workloads before migrating anything that requires an on-call rotation.
• Produce reusable artifacts. Every migration should generate documented patterns, Helm charts, pipeline templates, or runbooks that reduce the cost of the next migration.

This approach requires patience, but it is the difference between a migration that finishes in a reasonable timeframe with organizational buy-in and one that drags on indefinitely with declining support.

Key Takeaways

• Kubernetes migrations routinely underestimate organizational risk — not just technical risk.
• Focusing exclusively on deployment mechanics causes teams to defer security, observability, and compliance until they become crises.
• Ecosystem enthusiasm (service meshes, GitOps, new runtimes) compounds complexity when introduced all at once.
• Incremental milestones with independently deliverable value reduce the activation energy required to get other teams to migrate.
• Reusable artifacts from each migration — templates, runbooks, documented conventions — lower the cost of every subsequent migration.

A Kubernetes migration is not primarily a technical project. It is an organizational change project that happens to involve significant technical work. Planning for both dimensions is what separates migrations that succeed from those that stall.

The original post was attributed to Armory.io, the company behind a Spinnaker-based continuous delivery platform for Kubernetes.

This article examines the most significant advantages and drawbacks of bringing AI and ML into a DevOps practice, drawing on perspectives from practitioners and technology leaders.

The Benefits of AI and ML in DevOps

Making Sense of Complex Data

Modern software systems generate enormous volumes of logs, metrics, traces, and events. Engineers cannot manually review all of it at the pace that continuous delivery demands. AI and ML models can be trained to categorise and contextualise this data far more quickly than humans, surfacing meaningful signals from the noise.

Kevin Dallas, CEO of Wind River, has argued that AI and ML will become mandatory for analysing and processing operational data at scale. As he explained, the goal is not just to detect that a fault occurred, but to understand the sequence of events leading up to it—giving developers richer context for root-cause analysis, diagnostics, and business-level insights alike.

Earlier Defect Detection and Smarter Code Analysis

A core DevOps objective is finding and fixing defects as early in the pipeline as possible, before they propagate downstream to production. AI-assisted code analysis tools and automated code-review systems can identify severe issues earlier than traditional static analysis, and ML-powered testing tools can highlight coverage gaps and predict where defects are most likely to appear.

Joao Neto, Head of Quality and Acceleration at OutSystems, notes that AI and ML can also analyse value streams to identify bottlenecks and inefficiencies, and can even propose corrective actions. The same principles extend beyond code quality into security, architecture, performance, and user experience—any area where pattern recognition in data can guide better decisions.

Democratising Experimentation

Rigorous A/B testing and experimentation traditionally require specialised skills—data analysts who understand statistical significance, control group design, and result interpretation. Most software teams do not have this expertise on hand, which limits their ability to run meaningful experiments.

ML can lower this barrier by automating much of the statistical heavy lifting, making experimentation accessible to a broader range of team members, and potentially even to business stakeholders. When combined with observability tooling, ML techniques can also help teams understand how customers are actually using a product, what friction points they encounter, and what conditions reliably lead to system failures.

The Risks and Drawbacks

Deployment of AI Assets Is Harder Than It Looks

Many AI initiatives stall not at the modelling stage but at deployment. Building a predictive model in a notebook environment is relatively straightforward; operationalising it reliably within a production pipeline is a different problem entirely.

Peter van der Putten, Director of AI Systems at Pegasystems, identifies several requirements that are specific to deploying AI assets and are not fully addressed by standard DevOps practices. These include:

• Ethical bias checks: Models must be evaluated for discriminatory outputs before they are promoted to production.
• Transparency and explainability requirements: Depending on the use case, a model may need to meet minimum standards of explainability before deployment is appropriate.
• Model drift monitoring: Unlike traditional software, ML models can degrade silently over time as the data they receive diverges from their training distribution.

Standard CI/CD practices—automated testing, integration pipelines, staged rollouts—help, but they are not sufficient on their own. Teams deploying AI assets need to extend their pipelines with ML-specific quality gates.

Narrow AI Can Distract from Deeper DevOps Work

A significant and often overlooked risk is the opportunity cost of investing heavily in AI tooling before the underlying organisational and process foundations are sound.

Nigel Kersten, Field CTO of Puppet, draws a useful distinction: what most DevOps teams are working with is not general-purpose AI that replicates human reasoning, but narrow, task-specific statistical models. This is genuinely useful, but it can become a distraction if leaders treat it as a shortcut to avoid harder organisational work.

“I see far too many enterprise leaders looking to ‘AI’ and Robotic Process Automation as a way of dealing with the complexity and fragility of their IT environments instead of doing the work of applying systems thinking, streamlining processes, creating autonomous teams, adopting agile and lean methodologies, and creating an environment of incremental progress and continuous improvement.”

Nigel Kersten, Field CTO, Puppet

Kersten’s recommended order of operations: first, maximise the value of human expertise by fixing processes and culture. Then, apply ML selectively to augment those humans—automating well-understood, repetitive tasks such as anomaly detection in narrow, defined domains.

Bias and Model Quality Risks

AI and ML models are only as good as the data and processes used to train them. A model trained on historical data that reflects past biases or gaps in coverage will reproduce those problems at scale—and often invisibly. In a DevOps context, this could manifest as anomaly detection systems that miss novel failure modes, or automated code-review tools that flag issues inconsistently across different codebases.

Getting staff to trust and work effectively alongside AI tooling adds another layer of complexity. Without adequate training, documentation, and a culture that encourages engineers to challenge model outputs, AI tools can generate false confidence rather than genuine improvement.

Key Takeaways for DevOps Teams

• Start with clear use cases. AI and ML deliver most value in well-scoped, data-rich domains: log analysis, anomaly detection, test prioritisation, and value-stream analytics. Avoid broad, vague mandates to “add AI” without a defined problem to solve.
• Extend your pipelines for ML assets. Treat models as first-class software artifacts. Add bias checks, explainability validation, and drift monitoring to your CI/CD pipelines alongside standard unit and integration tests.
• Fix the fundamentals first. If your processes are fragile, your teams lack autonomy, or your observability is poor, addressing those issues will deliver more value than any AI tooling overlay.
• Plan for human oversight. AI and ML should augment engineers, not replace their judgement. Design workflows that keep humans informed and in control of consequential decisions.
• Invest in training and buy-in. Teams that understand how a model works—and what its limitations are—will use it more effectively and catch its failures earlier.

The Outlook

As AI and ML capabilities mature, their integration with DevOps practices is likely to deepen. Real-time optimisation of running systems—where models trained on live development, validation, and operational data continuously adjust system behaviour—represents a compelling direction. However, that future depends on teams building sound data infrastructure, responsible deployment practices, and a culture that treats AI as one tool among many rather than a silver bullet.

The teams that will benefit most are those that apply AI and ML thoughtfully, with clear metrics for success, strong human oversight, and a willingness to fix the organisational problems that no model can automate away.

Overview

Italian telecommunications operator TIM and Google Cloud, in collaboration with Intesa Sanpaolo Forvalue, announced a joint initiative in April 2020 to help Italian businesses maintain continuity during the COVID-19 pandemic. The offer bundled connectivity, cloud-based collaboration tools, and hardware into a single package aimed primarily at small and medium-sized enterprises (SMEs).

Background: TIM and Google Cloud Agreement

The initiative built on a broader collaboration agreement that TIM and Google Cloud had recently signed to provide cloud services to Italian businesses and public administration bodies. That agreement’s stated goals included developing innovative products and accelerating Italy’s wider digital transformation. The COVID-19 response offer was the first concrete product to emerge from that partnership.

Intesa Sanpaolo Forvalue, a subsidiary of the Intesa Sanpaolo banking group specialising in non-financial business consultancy, joined as the third partner, adding a hardware rental component to the package.

What the Package Included

The all-in-one offer combined three distinct layers of capability:

• Connectivity — TIM’s fixed and mobile network services, including fibre broadband, Fixed Wireless Access (FWA), and 4G (with provision for future network evolutions), to ensure reliable remote access for employees regardless of their location.
• Collaboration and productivity software — Google Cloud’s G Suite (now Google Workspace), encompassing Gmail for business email, Google Meet for video conferencing, Google Drive for cloud storage, and the broader suite of collaboration applications.
• Hardware — A laptop rental service offered through Intesa Sanpaolo Forvalue, designed to reduce upfront capital expenditure for businesses that lacked sufficient devices for a sudden shift to remote work.

Target Audience: Italian SMEs

The package was explicitly targeted at the small and medium-sized enterprise segment, which typically has less in-house IT capability and fewer existing remote-working tools than larger corporations. By bundling connectivity, software, and hardware into a single commercial offer, the partners aimed to reduce the complexity of procurement and deployment for companies with limited IT resources.

Dual Goals: Immediate Continuity and Long-Term Transformation

Beyond the immediate crisis response, the collaboration carried a stated second objective: helping Italian businesses plan for the post-pandemic period. The partners positioned the initiative not only as an emergency measure but also as a catalyst for longer-term changes in working practices and production methods. This framing aligned with broader European discussions during 2020 about accelerating digital adoption as economies prepared to reopen.

Significance for the Italian Market

Italy was among the first European countries to experience severe COVID-19 outbreaks and imposed one of the strictest early lockdowns on the continent. The sudden requirement for large numbers of employees to work remotely exposed gaps in connectivity infrastructure and collaboration tooling, particularly among SMEs. A bundled offer from a major national telco, a global cloud provider, and a banking-sector consultancy represented a pragmatic attempt to close those gaps quickly.

The initiative also illustrated a pattern seen across the industry during 2020: telecommunications operators and cloud providers forming rapid partnerships to convert existing infrastructure agreements into market-ready products in response to demand spikes driven by remote work mandates.

Key Takeaways

• TIM, Google Cloud, and Intesa Sanpaolo Forvalue combined connectivity, software, and hardware into a single SME-focused package.
• The offer drew on a pre-existing TIM–Google Cloud agreement to accelerate Italy’s digital transformation.
• G Suite (Google Workspace) provided the collaboration layer, including Gmail and Google Meet.
• Laptop rental via Intesa Sanpaolo Forvalue lowered the barrier to adoption for hardware-constrained businesses.
• The partnership was designed to address both the immediate COVID-19 disruption and longer-term shifts in working culture.

CircleCI Secures $100 Million to Scale Its CI/CD Platform

San Francisco-based CircleCI announced the close of a $100 million Series E funding round, one of the largest single raises by a DevOps-focused company at the time. The round was led by IVP and Sapphire Ventures, pushing the company’s total funding to $215 million. CEO Jim Rose told CRN the investment would be used to expand the product portfolio, grow the company’s international presence, and formalize enterprise sales motions.

Why CI/CD Attracted This Level of Investment

Continuous integration and continuous delivery (CI/CD) had moved well beyond early-adopter startup culture by 2020. Rose described the shift as a “phase change” that had accelerated over the previous six to eight quarters, with CI/CD evolving from an aspirational practice into a non-negotiable requirement for software teams at enterprises of all sizes.

“Continuous delivery has gone from being a glimmer in a startup’s eye to an aspirational North Star,” Rose said, reflecting the broader industry momentum that made CircleCI an attractive investment target.

CircleCI’s customer base spanned both web-scale technology companies — including Facebook and Spotify — and more traditional enterprises such as Ford and Unilever. The breadth of that customer mix signaled that CI/CD adoption had crossed into mainstream enterprise IT, not just digital-native organizations.

Product Roadmap: Change Validation and Cloud Architecture Complexity

A significant portion of the new capital was earmarked for product development, with a particular focus on change validation capabilities. As organizations adopt increasingly complex cloud-native architectures, the ability to automatically validate and model the downstream effects of code changes becomes critical to maintaining delivery velocity without introducing instability.

“Being able to map and model and take care of all those sources of change is important,” Rose said. “We’re helping customers deal with the complexity of these new modern cloud architectures.”

CircleCI delivers its CI/CD tooling primarily as a Software-as-a-Service (SaaS) platform, which allows development teams to integrate pipelines without managing the underlying infrastructure themselves.

International Expansion: Tokyo and London Offices

CircleCI had already begun building an international footprint before the Series E closed. The company opened an office in Tokyo to serve Asia-Pacific customers and subsequently opened a London office to support European demand. The new funding was intended to accelerate that expansion further.

“We’ve been trying to drive growth with our existing customers and new customers, ranging in all sizes and types,” Rose said.

How CircleCI Fits Into Enterprise Digital Transformation

Rose described a consistent pattern in how large enterprises engage with CircleCI during digital transformation projects. The typical journey unfolds in three phases:

1. Cloud adoption: A systems integrator establishes a relationship and executes the initial migration to cloud infrastructure.
2. Source code consolidation: The organization rationalizes its version control and code management tooling.
3. Pipeline modernization: As development teams increase their delivery cadence, they recognize the need to replace legacy tooling sitting between source control and the data center — which is where CircleCI enters the picture.

“As developers pick up the pace, they realize they then need to replace tooling that sits between the code source and the data center,” Rose said, “and that’s where we get involved.”

Company Background: From Distiller to CI/CD Leader

CircleCI was founded in 2011 and built its early growth on a developer-led, bottoms-up adoption model — individual engineers signing up and using the platform before formal enterprise procurement. That grassroots approach gave the company deep penetration across development teams globally before the enterprise sales layer was formalized.

In 2014, three years after founding, CircleCI acquired Distiller, a startup focused on CI/CD for mobile applications. Jim Rose was CEO of Distiller at the time; his team literally walked across a street in San Francisco to meet with CircleCI leadership, and the two companies agreed to merge after recognizing that the market would eventually demand a comprehensive, multi-platform CI/CD solution. Rose subsequently became CEO of the combined company.

Key Takeaways for DevOps Teams

• The $100 million Series E reflected significant investor confidence in CI/CD as a foundational enterprise software category, not a niche developer tool.
• CircleCI’s dual focus on web-scale internet companies and traditional enterprises illustrated how broadly CI/CD adoption had spread by 2020.
• Investment in change validation capabilities points to a maturation of CI/CD from pipeline automation toward intelligent release governance.
• The SaaS delivery model remained central to CircleCI’s value proposition, reducing operational overhead for engineering teams.
• International expansion — particularly into APAC via Tokyo — signaled that the DevOps tooling market had become genuinely global.

DevOps World 2020 Call for Papers Is Now Open

CloudBees, the enterprise software delivery company, announced the opening of the DevOps World 2020 Call for Papers (CFP) on March 18, 2020. DevOps practitioners were invited to submit session abstracts covering a broad range of topics relevant to modern software delivery teams.

The conference was scheduled for September 21–24, 2020, at the Aria Resort in Las Vegas, Nevada. DevOps World is widely recognized as one of the largest gatherings of DevOps practitioners and Jenkins users globally, providing a forum for learning, networking, and exploring emerging trends in software development and delivery.

Topics Sought for CFP Submissions

The CFP invited proposals across a wide range of DevOps and software engineering disciplines. Suggested topic areas included:

• Continuous integration and continuous delivery (CI/CD) best practices
• Feature delivery automation
• Test automation strategies
• DevOps at scale
• Data-driven change management
• KPIs and engineering metrics
• Organizational and cultural transformation
• Open source tooling and community contributions

These topics reflect the core challenges that DevOps teams face when scaling delivery pipelines, measuring software performance, and driving cultural change within large organizations.

New Addition: The Software Delivery Leadership Forum

A significant new feature for the 2020 event was the introduction of the Software Delivery Leadership Forum, a track running throughout the entire conference and chaired by Accelerated Strategies Group, an independent analyst firm.

The Leadership Forum was designed to bridge the gap between strategic business thinking and deep technical expertise. Unlike purely technical sessions, this forum would deliver content through a mix of:

• Presentations by industry leaders
• Panel discussions
• Hands-on exercises
• Peer networking and collaboration

The goal was to equip executives and senior leaders responsible for driving digital transformation with the tools, frameworks, and peer insights needed to accelerate their organizations’ DevOps journeys.

“Accelerated Strategies is excited to chair the Software Delivery Leadership Forum at this year’s DevOps World, in partnership with CloudBees. As the pace of digital transformation increases, we believe a greater emphasis on educating the executives responsible for leading the transformation will help organizations find the fastest path to success.”

— Mitch Ashley, CEO, Accelerated Strategies Group

Key Dates and Registration Pricing

The following timeline and pricing structure was announced alongside the CFP:

COVID-19 Contingency Planning

Given that the announcement was made in March 2020, at the onset of the global COVID-19 pandemic, CloudBees included an important caveat regarding in-person event planning:

“In light of the global health concerns due to the novel coronavirus (COVID-19), CloudBees is monitoring public health guidance in relation to in-person events. We are not taking decisions lightly, but the health and well-being of our employees, partners, customers and other guests remain our ultimate priority. We will continue to monitor and make any necessary changes as the situation evolves. If the conference must be canceled at a later date due to guidance from public health authorities, the event will be held virtually and all CFP submissions will be reviewed for potential inclusion.”

This foresight proved relevant across the technology conference industry in 2020, as many large events pivoted to virtual formats throughout the year.

Sponsors

At the time of the announcement, confirmed sponsors included: CloudBees, Sonatype, MacStadium, Sauce Labs, Go2Group, LogDNA, NowSecure, Plutora, SmartBear, WhiteSource, Compuware, GitLab, LaunchDarkly, Synopsys, Xray, ZeroNorth, FOSSA, Gradle, and Zimperium.

Why the Leadership Track Matters for DevOps Teams

The addition of a dedicated leadership forum reflects a broader maturation of the DevOps discipline. Early DevOps adoption was largely practitioner-driven, focused on tooling and automation. As organizations scale their DevOps programs, the strategic decisions made by engineering leaders, VPs of Engineering, and C-suite executives become equally critical to success.

Key leadership challenges in DevOps at scale include:

• Measuring ROI — Defining and tracking meaningful KPIs that connect engineering output to business outcomes
• Cultural change — Breaking down silos between development, operations, security, and product teams
• Governance at scale — Managing compliance, security, and reliability without sacrificing velocity
• Platform strategy — Deciding when to build internal developer platforms versus adopting commercial tooling

Forums like the Software Delivery Leadership Forum provide senior leaders with structured peer learning opportunities that go beyond vendor-led product demonstrations, offering insights grounded in real-world organizational experience.

Why Edge and IoT Demand a Unified DevOps Approach

Digital transformation touches every part of an enterprise—HR, finance, logistics, operations—but it is the IT function that must be the most responsive and agile. Applications are the primary vehicle through which business needs are met, which means delivering new deployments faster, with a consistent cadence, has become a strategic imperative rather than a nice-to-have.

Meeting that imperative typically involves a familiar set of modern practices:

• Containerized application packaging
• Iterative, pipeline-driven DevOps
• Microservice-based architectures
• Software-defined infrastructure
• Automation platforms for provisioning and configuration

These practices are well-understood for cloud and on-premise workloads. The challenge that edge computing and IoT introduce is extending the same discipline—continuous delivery, automated testing, rapid rollback—to environments that are physically distributed, resource-constrained, and often connected through intermittent or low-bandwidth links.

The Core Problem: Fragmented Development Methodologies

One of the most common mistakes enterprises make when expanding into edge or industrial IoT is treating those environments as entirely separate from their existing development pipeline. The result is two (or more) toolchains, two release cycles, and two sets of operational runbooks—multiplying complexity and slowing everything down.

A better model treats edge and cloud as different deployment targets for the same artifacts. Container images built and tested centrally can be deployed to edge nodes using the same orchestration tooling used in the data center. Continuous delivery pipelines can target edge clusters as just another environment, enforcing the same quality gates and rollout strategies.

This portability-first philosophy requires that the underlying platform be consistent across environments. That is where the choice of operating system, container runtime, and orchestration layer becomes critical.

Why Open Source Is the Only Practical Foundation

Proprietary stacks can introduce vendor lock-in that actively undermines portability. An application packaged for one vendor’s edge gateway may not run without modification on another vendor’s hardware—defeating the entire purpose of containerization.

Open-source software provides several structural advantages in this context:

• Portability: Open standards and open container formats (OCI) mean workloads are not tied to a specific vendor’s runtime.
• Security transparency: Open codebases allow the security community to audit, find, and fix vulnerabilities faster.
• Breadth of features: A large contributor ecosystem means edge-specific capabilities (hardware accelerator support, real-time kernels, LoRa/5G networking drivers) are developed and maintained by those closest to the hardware.
• Vendor independence: Organizations retain the ability to switch hardware vendors or cloud providers without rewriting their application layer.

SUSE’s Position in the Edge and IoT Stack

SUSE was among the first vendors to ship an enterprise Linux distribution, and it has extended that lineage into edge and IoT scenarios. The portfolio relevant to edge DevOps (as described in the original 2020 source material) includes several components:

SUSE Embedded Linux

An embedded Linux operating system designed for IoT and Industrial IoT (IIoT) devices. The goal is to provide a production-grade, security-hardened Linux foundation on resource-constrained hardware—the same kernel lineage that runs in the data center, adapted for the constraints of embedded and edge deployments.

SUSE CaaS Platform

A Kubernetes-based container-as-a-service platform that, per the source material, can be used to build and deliver applications targeting edge environments. Running Kubernetes-compatible orchestration at the edge allows teams to reuse the same deployment manifests, Helm charts, and CI/CD integrations they already use for cloud workloads.

Cilium-Based Advanced Networking

The source material references SUSE’s use of Cilium—an open-source project that provides eBPF-based networking, observability, and security for Kubernetes clusters. At the edge, network policy enforcement and east-west traffic visibility are especially important because edge nodes frequently operate in less-controlled network environments than a typical data center.

SUSE Cloud Application Platform

A platform-as-a-service layer (based on Cloud Foundry at the time of writing) that abstracts infrastructure details away from developers, enabling faster application delivery across cloud and on-premise targets.

Edge-Specific Technical Considerations

Several characteristics distinguish edge deployments from traditional data center or cloud workloads, and DevOps tooling must account for all of them:

Bandwidth and Latency Constraints

Edge nodes frequently sit on expensive or unreliable WAN links. Pushing every byte of raw sensor data to a central cloud for processing is economically and technically impractical at scale. Local pre-processing—filtering, aggregation, anomaly detection—reduces the volume of data that must traverse the WAN and enables real-time decision-making that a round-trip to the cloud cannot support.

Real-Time and Deterministic Requirements

Industrial, medical, and autonomous-vehicle applications often have hard real-time requirements. A general-purpose Linux kernel may need to be configured with real-time patches (PREEMPT_RT) or replaced with a real-time kernel variant to guarantee deterministic response times. Operating system choice matters here in a way it simply does not for a typical web application.

Remote Fleet Management

When a fleet of edge devices is spread across geographies—remote utilities, retail locations, transport hubs—manual updates are not a viable operational model. Automated over-the-air (OTA) update mechanisms, integrated with CI/CD pipelines, are essential for maintaining security and feature currency across the fleet without requiring on-site visits.

Machine Learning at the Edge

Running inference workloads locally—rather than sending data to a central ML service—reduces latency and bandwidth usage. Edge ML pipelines typically involve training models centrally (using aggregated data), then deploying optimized model artifacts to edge nodes where inference runs locally. Platforms that support GPU or neural processing unit (NPU) passthrough into containers simplify this workflow considerably.

In combination with communications technologies like 5G (low latency, high throughput) and LoRa (long range, low power), locally-running ML models can generate actionable insights from IoT sensor streams without a constant cloud dependency.

Applying DevOps Principles to Edge Deployments

The principles of DevOps translate to edge environments, though the implementation details differ:

Key Takeaways for DevOps Engineers

• Unify your pipeline. Resist the temptation to build a separate toolchain for edge. Treat edge nodes as deployment targets within your existing CI/CD system.
• Choose a portable base. An open-source, standards-compliant OS and container runtime reduces the risk of being locked into hardware or cloud vendor decisions made today.
• Design for disconnected operation. Edge deployments will lose connectivity. Applications, update mechanisms, and observability tooling must degrade gracefully and recover automatically.
• Account for real-time requirements early. Retrofitting real-time kernel support into a production edge deployment is painful. Understand latency requirements before selecting the OS layer.
• Automate fleet management from day one. Manual update processes that are acceptable for a handful of edge devices become untenable at hundreds or thousands. Build OTA update automation before the fleet scales.

Further Reading

For more detail on SUSE’s edge and IoT offerings, refer to the SUSE Edge Computing solutions page. For background on the Cilium networking project referenced above, see the Cilium project website. The original article appeared on TechHQ.

The analogy is deliberate. Airline passengers adopt the brace position during an emergency landing—alert, braced for impact, hoping for the best. Enterprises in the middle of a digital transformation often feel exactly the same way: impressive momentum, but a real risk of a hard landing. Industry observers consistently note that a large proportion of digital transformation initiatives fall short of their goals, frequently due to cultural resistance, siloed teams, and an inability to scale software delivery at pace.

DevOps is one of the most effective tools available to enterprises trying to break out of that brace position. It does not just connect development and operations—it creates a shared operating model that spans the entire organisation, aligning delivery speed with business outcomes. Below are the five ways DevOps delivers that rescue.

1. Collaboration Across the Entire Enterprise

As enterprises scale, teams naturally fragment. Each group develops its own toolchain, its own vocabulary, and its own definition of success. The result is conflicting priorities, duplicated effort, and slow handoffs between teams that should be working in concert.

DevOps addresses this at the cultural level. While it is commonly described as a bridge between development and operations, its scope is broader: it brings together security, QA, product management, business stakeholders, and operations under shared objectives—primarily, delivering value to customers reliably and quickly.

Practical collaboration mechanisms include:

• Daily stand-ups and cross-functional sprint planning — keeping all stakeholders aligned on priorities and blockers.
• Shared project-tracking tools — a single source of truth for work in progress, regardless of team.
• Infrastructure as Code (IaC) — perhaps the clearest example of forced collaboration. When developers write and own infrastructure definitions (using tools such as Terraform or Ansible), they develop a working understanding of network topology, server configuration, and environment parity. Operations engineers, in turn, review application code and participate in testing. The traditional handoff disappears.

This shared ownership model means that digital channel performance becomes everyone’s responsibility, not a problem that gets thrown over the wall when something breaks.

2. Agility: Responding to Change Without Chaos

Collaboration naturally produces agility—the capacity to absorb requirement changes, pivot direction, and continue delivering without everything falling apart.

In a traditional, non-DevOps delivery model, a late requirement change typically triggers a cascading set of rework across disconnected pipelines. In a DevOps model, integrated CI/CD pipelines mean that a change in requirements results in a new build, a new round of automated tests, and a deployment to the appropriate environment—often with minimal manual intervention.

Three specific agility capabilities that DevOps enables for enterprises:

1. Delivering new solutions — continuous integration and delivery pipelines allow teams to ship features incrementally rather than waiting for large, risky releases.
2. Running and evolving infrastructure alongside solutions — IaC and cloud-native tooling let teams provision, modify, and tear down infrastructure as part of the same workflow as application delivery.
3. Managing midcourse corrections — standardised communication practices (common language, shared processes, agreed toolchains) mean that when priorities shift, teams can recalibrate without lengthy re-negotiation.

Planning boards that are visible to both product owners and business stakeholders help teams prioritise features by impact and manage dependencies—eliminating the guesswork that slows agile execution at scale.

3. Speed of Delivery: Reducing Lead Time to Market

For a digitally transforming enterprise, speed of delivery is a competitive differentiator. Lead time—the elapsed time from a code commit to a production deployment—is one of the most closely watched metrics in DevOps performance research.

Research from Puppet Labs’ annual State of DevOps Reports (published mid-2010s) consistently showed that high-performing IT organisations achieved dramatically shorter lead times than their low-performing counterparts. Importantly, as low-performing organisations adopted DevOps practices, the gap between cohorts changed over time—not because high performers slowed down, but because the broader population improved. This is a healthy signal: DevOps practices genuinely raise the floor for software delivery performance across the industry.

To improve delivery speed, enterprises should build out a complete CI/CD pipeline covering:

• Planning and backlog management — Jira, Azure DevOps, Linear, or equivalent.
• Source code management — Git-based repositories (GitHub, GitLab, Bitbucket).
• Continuous integration — automated build and test on every commit (Jenkins, GitHub Actions, CircleCI, etc.).
• Continuous delivery and release management — automated promotion through environments with approval gates where needed.
• Infrastructure as Code — reproducible environment definitions that eliminate the “works on my machine” problem.

Once a pipeline is in place, teams should benchmark their current lead time and deployment frequency against industry baselines (such as those published in the DORA State of DevOps research) and against their own historical performance. The diagnostic exercise reliably surfaces bottlenecks in integration, test coverage, or deployment approval processes.

4. Reliability: Quality at Speed

Speed without reliability is just a faster way to break things. The classic waterfall argument—that testing at the end of the cycle ensures quality—fails at scale because it concentrates risk into a single, high-stakes event. If defects are found late, timelines slip and the brace position tightens.

DevOps distributes quality assurance throughout the delivery cycle rather than concentrating it at the end. Key practices include:

• Version control for everything — application code, infrastructure definitions, configuration, and scripts. This creates an auditable history and enables safe rollbacks.
• Standardised technology stacks and source code repositories — reducing variance in how software is built and tested, which directly improves repeatability.
• Automated test gates in the CI pipeline — every commit triggers unit tests, integration tests, and functional tests. Builds that fail quality gates are blocked from progressing to the next environment.
• Minimum acceptance criteria — teams agree in advance what “good enough to proceed” looks like, removing subjective judgement from the promotion decision.

This approach does not eliminate defects, but it catches them at the cheapest possible point in the cycle—immediately after the code is written, when the context is fresh and the fix is fastest.

5. Mean Time to Recover (MTTR): Failing Safely and Recovering Fast

Even the best-run DevOps organisations experience outages. The goal is not to achieve zero downtime—it is to recover from failure so quickly that the customer impact is minimal. This is measured as Mean Time to Recover (MTTR): the elapsed time between a system failure and full restoration of service.

High MTTR is often a symptom of manual, error-prone recovery processes and brittle, single-cloud or on-premises infrastructure. DevOps addresses this through:

• Automation of recovery procedures — runbooks codified as scripts or IaC templates that can be executed consistently and quickly under pressure.
• Hybrid and multicloud strategies — distributing workloads across cloud providers or regions so that a failure in one zone does not bring down the entire application.
• IaC-driven infrastructure replacement — rather than diagnosing and repairing a failed server, teams can destroy and redeploy it from a known-good definition in minutes.
• Observability and alerting — monitoring that detects failure early and routes alerts to the right people immediately, compressing the detection-to-response window.

Reducing MTTR is one of the four key metrics tracked in DORA research alongside deployment frequency, lead time for changes, and change failure rate. Organisations that invest in reducing MTTR consistently improve across the other three metrics as well—recovery discipline and delivery discipline reinforce each other.

Conclusion: DevOps as the Landing Gear for Digital Transformation

Enterprises in the digital transformation brace position are not doomed to crash. But surviving the turbulence requires more than good intentions and a digital strategy document. It requires a coherent operating model that connects teams, accelerates delivery, maintains quality, and recovers gracefully from failure.

DevOps provides that operating model. Collaboration breaks down silos. Agility absorbs change. Speed shortens time to market. Reliability distributes quality assurance. And fast MTTR ensures that when something does go wrong, it goes wrong briefly.

Enterprises that are stalling on their digital transformation journey should audit each of these five dimensions against their current practices. The gaps that surface are the specific areas where DevOps investment will deliver the greatest return—and provide the smoothest possible landing in the digital space.

Nadella Arrives in India for Three-Day Strategic Visit

Microsoft CEO Satya Nadella began a three-day visit to India in late February 2020, starting in Mumbai before moving on to meetings with Indian industry leaders, technology partners, and government officials. The visit was widely interpreted as a signal of Microsoft’s deepening commitment to the Indian market, particularly as the company accelerated growth of its Azure cloud platform across the Asia-Pacific region.

India ranks as one of Microsoft’s top-performing markets globally, with more than half of the company’s India revenue reported to be coming from cloud and cloud-based services at the time of the visit — a figure that underscores the strategic importance of the region as Microsoft competes with Amazon Web Services (AWS) and Google Cloud.

New Engineering Hub in Noida Anchors Microsoft’s India Expansion

Just prior to Nadella’s visit, Microsoft opened a new engineering hub in Noida, Uttar Pradesh — a facility intended to develop products and services that support digital innovation at a global scale. Analysts described the hub as a strategically important investment in Microsoft India’s long-term growth story.

“This is a strategic investment for Microsoft and will play an important role in Microsoft India’s expansion and growth story. It will also create thousands of jobs for Indian engineers.”

Sanchit Vir Gogia, Founder and CEO, Greyhound Research

Government Engagement: Digital Transformation of State Ecosystems

A central element of Nadella’s India itinerary was a planned meeting with Uttar Pradesh Chief Minister Yogi Adityanath to discuss the digital transformation of the state’s government ecosystem. This followed a broader initiative Microsoft had launched in August 2019, when the company organized a series of workshops in Lucknow aimed at equipping government IT officials with AI and cloud computing skills. The programme targeted training 5,000 government personnel over 12 months, with a focus on leveraging AI and secure cloud technology for more efficient and transparent governance.

Microsoft was empanelled as a public cloud service provider by India’s Ministry of Information Technology (MeitY) in late 2016 and has continued to hold certification as a cloud provider for multiple state governments. According to tech and policy advisor Prasanto K. Roy, Nadella’s engagement with state-level BJP leadership was part of a broader strategy to reinforce Microsoft’s relationship with both central and state governments.

“Nadella will want to assure the government of his and Microsoft’s complete support for government projects and policy, irrespective of his personal views. A deeper engagement with Uttar Pradesh and a meeting with CM Adityanath is part of that assurance and strategic engagement with both Centre and state governments.”

Prasanto K. Roy, Tech and Policy Advisor

Azure’s Growth and Microsoft’s Cloud Business Momentum

Nadella’s India visit came on the back of strong Azure performance. In its Q2 FY2020 earnings report, Microsoft disclosed that its Intelligent Cloud segment — which includes Azure — generated $11.9 billion in revenue for the quarter, representing 27% year-on-year growth.

Microsoft rebranded Windows Azure as Microsoft Azure in 2014 and has since built it into one of the world’s largest cloud infrastructure platforms, holding the position of second-largest cloud provider globally behind AWS. In India, enterprises such as InMobi and Myntra were reported to be moving to Azure as their preferred cloud platform.

Jayanth Kolla, Partner at Convergence Catalyst, noted that Microsoft had been expanding its research activities in India and running AI and deep-tech pilots in sectors including healthcare — areas where cloud computing and machine learning are increasingly seen as transformative tools.

“From a business point of view, Microsoft has been increasing its research activities in India and running a number of AI/deep tech pilots in India in areas like healthcare.”

Jayanth Kolla, Partner, Convergence Catalyst

Key Challenges: Data Localisation, Reliability, and Market Competition

Data Localisation Requirements

One of the most significant policy challenges Microsoft faced in India at the time of the visit was data localisation — a regulatory push requiring companies to store certain categories of data on servers physically located within India. For a cloud provider like Microsoft, complying with expanding localisation requirements would mean investing in additional data centres at both national and state levels, driving up capital expenditure and ongoing operational costs.

“This for a company like Microsoft that is running a cloud service like Azure and growing it would mean opening more and more data centres locally in India and at the state level too. This would increase the capex cost and the operational expenditure of the company.”

Jayanth Kolla, Partner, Convergence Catalyst

Service Reliability and CIO Concerns

Despite Azure’s growth momentum, enterprise customers in India expressed concerns that Microsoft still needed to address. According to Sanchit Vir Gogia of Greyhound Research, CIO feedback highlighted issues around Azure outages and support quality — specifically around cost transparency and response timeliness.

“Our CIO customers do often share with us their concerns with Azure outages and also support issues around costs and timeliness. Both are extremely important topics for organisations to ensure availability of resources in production.”

Sanchit Vir Gogia, Founder and CEO, Greyhound Research

A Competitive Cloud Market

In India, Microsoft competes directly with AWS and Google Cloud for enterprise workloads. While Microsoft had established a strong foothold and maintained decades-long relationships with the Indian government, the cloud market remained fiercely contested. Analysts noted that Microsoft had much to prove before it could claim cloud dominance in the Indian market, particularly as AWS continued to hold significant mind-share among large enterprises and startups alike.

Start-ups, Developers, and the Partnership Ecosystem

Beyond government and enterprise engagements, Microsoft’s India strategy at the time rested heavily on cultivating relationships with the start-up community and the developer ecosystem. India’s large pool of engineering talent and its rapidly growing start-up sector made it a natural fit for Microsoft’s cloud-first, AI-focused product strategy. Programmes targeting start-ups through Azure credits and AI tooling formed a complementary layer to the government-facing initiatives announced during the visit.

Context: Broader India-Tech Industry Dynamics

Microsoft’s visit took place against a backdrop of complicated dynamics between large technology companies and the Indian government. Several IT majors had scaled back bidding for government contracts citing delayed or non-payment issues. Wipro had, around the same period, suspended services related to Assam’s National Population Register (NPR) project. This environment made Microsoft’s careful diplomatic engagement with state and central government stakeholders all the more significant — maintaining trust while navigating politically sensitive terrain required measured communication at the executive level.

For Nadella, whose family roots are in India, the visit carried both personal significance and substantial business weight. As Microsoft continued to build out its Azure infrastructure globally and deepen AI integration across its product suite, India’s combination of engineering talent, a rapidly digitising government sector, and a large enterprise market made it a region where both the stakes and the opportunities were high.

A Pricing Shift That Caught Enterprise IT Off Guard

As chip manufacturers continue to pack ever-higher core counts into modern CPUs, VMware announced a fundamental change to how it prices its vSphere hypervisor product line. The move — from a per-socket licensing model to a per-core model — landed as a significant cost shock for many enterprise IT teams, and it reignited a debate that has simmered for years: is the economics of on-premises virtualization still competitive with the public cloud?

The new fee structure took effect in April 2020, applying to VMware’s hypervisor products that allow multiple operating systems to run on a single physical server. For organizations with large fleets of high-core-count servers, the change translated directly into materially higher licensing bills.

How the New Licensing Model Works

Under the legacy model, VMware charged per CPU socket — essentially, per physical processor slot on the motherboard. A dual-socket server required two licenses regardless of how many cores each CPU contained.

Under the new core-based model:

• One license covers up to 32 cores per CPU.
• A CPU with more than 32 cores requires a second license for that socket.
• These licensing costs are in addition to any fees for software managing physical and virtual machine operations.

VMware positioned the change as bringing its pricing in line with how operating system vendors and database software companies — such as Oracle and Microsoft — have long charged for enterprise software: by core count rather than by socket. Base pricing for the enterprise edition of vSphere was reported at around $3,500 per month, with optional features and support packages potentially increasing that figure by an order of magnitude.

Why Core Counts Matter Now More Than Ever

The timing of VMware’s change is directly tied to a hardware trend that shows no signs of reversing: CPU vendors are aggressively increasing per-socket core counts, squeezing more parallel compute threads onto a single die.

At the time of this pricing change, several high-core-count platforms were either shipping or in active development:

• Intel Ice Lake and Cooper Lake: Targeting 38 and 48 cores per socket, respectively, in the server segment.
• AMD EPYC Rome: Already shipping with up to 64 cores per socket, making dual-license requirements almost certain for any EPYC-based host.
• Ampere Computing: A startup developing an 80-core Arm-based processor aimed at cloud infrastructure operators.
• Arm Cortex server chips: Arm itself was pushing into the data center with 32-core Cortex-based designs.
• Huawei Kunpeng: A 64-core Arm-licensed chip launched for data center workloads.
• AWS Graviton2: Amazon Web Services’ custom Arm ISA implementation, used internally across its hyperscale fleet.

The practical implication: any enterprise running or planning to run AMD EPYC or upcoming Intel platforms would automatically cross the 32-core threshold and incur double licensing costs per socket. For organizations with hundreds or thousands of host servers, that arithmetic compounds quickly.

VMware’s Market Position and Revenue Context

VMware, then a Dell EMC subsidiary listed on Nasdaq, held an overwhelmingly dominant position in the enterprise data center hypervisor market. Industry analysts estimated that VMware hypervisors were running on approximately three-quarters of all data center servers at the time. License revenue represented roughly 40% of the company’s reported $9 billion annual revenue in fiscal year 2019.

The transition to core-based licensing was therefore not simply a pricing policy adjustment — it was a significant revenue strategy. As chip vendors compete to deliver more cores per socket, VMware’s new model is designed to capture a share of that performance growth in the form of additional license fees, rather than allowing customers to benefit from hardware improvements within a fixed per-socket cost envelope.

Customer Discontent and Transition Incentives

VMware appeared aware that the change would generate friction. To soften the transition, the company offered a grace period: customers who purchased 32-core licenses before the end of April 2020 could receive additional licenses to cover their existing server estate at no extra charge — a one-time concession for organizations that had already committed their 2020 IT budgets under the old model.

Despite this, criticism from the enterprise IT community was swift and pointed. Key complaints included:

• Perceived favoritism toward Intel: Critics noted that most Intel server CPUs at the time fell below the 32-core threshold, meaning Intel-based customers faced a smaller pricing impact than those running AMD EPYC hardware. This raised questions about whether the licensing structure indirectly steered customers toward a particular chipmaker.
• Justification language: Some IT professionals challenged the framing of the change as an “industry alignment,” arguing it obscured a straightforward price increase for a large portion of the customer base.
• Budgeting disruption: Enterprise procurement cycles operate on annual or multi-year timelines. An unplanned licensing cost increase mid-cycle forced difficult conversations between IT and finance teams across many organizations.

The Cloud Migration Calculus

The pricing change arrives at an awkward moment for the case for on-premises virtualization. Public cloud providers — AWS, Microsoft Azure, Google Cloud — have long argued that the total cost of ownership for on-premises infrastructure, when license fees, hardware refresh cycles, power, cooling, and staffing are factored in, is comparable to or higher than cloud consumption pricing for many workloads.

VMware’s per-core fee increase hands cloud vendors a concrete, quantifiable talking point. A cloud account executive can now present a specific scenario: a customer running dual-socket AMD EPYC servers who previously paid for two vSphere licenses will now pay for four — and can compare that directly against the cost of equivalent compute capacity consumed elastically from a public cloud provider.

Dell EMC also operates its own cloud hosting services covering compute, storage, and networking. The pricing pressure VMware creates for third-party managed service providers and colocation vendors that run VMware in their own data centers could reshape competitive dynamics in that market as well, potentially funneling enterprise workloads toward Dell’s own cloud offerings.

Key Takeaways for DevOps and Infrastructure Teams

• Audit your host topology now. Identify every physical host running VMware hypervisors and document the exact core count per socket. Any CPU exceeding 32 cores triggers an additional license requirement.
• Model the cost delta. Calculate the difference between your current licensing spend and projected spend under core-based pricing, accounting for planned hardware refreshes over the next three to five years.
• Include cloud in the TCO comparison. Use the updated VMware costs as a forcing function to run a genuine total cost of ownership comparison against equivalent workloads hosted on public cloud or a managed VMware-on-cloud offering.
• Watch the chipmaker roadmap. Core counts are not plateauing. Planning infrastructure purchases without accounting for the licensing cost of future high-core-count CPUs is a budgeting risk.
• Engage your VMware account team. Large enterprise accounts may have negotiating leverage, particularly if the pricing change creates a credible migration threat.

The broader question the industry will continue to work through is whether VMware’s model encourages the digital transformation its parent company Dell EMC promotes — or whether it inadvertently accelerates the migration of workloads to public cloud platforms that do not carry the same per-core hypervisor licensing overhead.

The collision between speed and security is a tension that is not easily resolved. DevSecOps—the practice of embedding security directly into the software development lifecycle (SDLC)—has emerged as a leading methodology for helping development and security teams work through these conflicting priorities. Despite its growing adoption, however, security still lags behind as a fully integrated part of most application development pipelines.

A report developed by 451 Research and sponsored by Synopsys (published in October 2019) found that most organizations employ far more application developers than information security professionals, and that only 9 percent of security budgets at surveyed organizations were dedicated to application security. This matters because Verizon’s 2019 Data Breach Investigations Report found that over 60 percent of the hacking attempts analyzed targeted web applications.

The DevSecOps Cultural Shift

One of the most persistent obstacles to DevSecOps adoption is cultural, not technical. Developers naturally want to ship new features quickly; security teams are often still perceived as the “Department of No,” slowing releases to patch vulnerabilities before they can be exploited. Bridging this divide requires security teams to move from gatekeeping to enablement.

Michelle McLean, then vice president of product marketing at security firm StackRox, articulated the key insight clearly:

“It’s important to understand that developing DevSecOps means integrating security into DevOps practices, not the other way around. Integrating security into DevOps creates massive impact on the developer culture and what developers see as important.”

Michelle McLean, StackRox

McLean also emphasized that security teams must go into problem situations with a clearly defined issue, offer multiple resolution options rather than mandates, and collaborate with DevOps teams to jointly craft the fix. This cooperative framing is central to making DevSecOps work in practice.

With that cultural foundation in mind, three concrete trends are shaping how teams operationalize DevSecOps.

Trend 1: Better Tooling Across the Full Application Lifecycle

Historically, security checks were bolted on at the end of the development cycle—or worse, only performed reactively after a breach. Modern DevSecOps requires tooling that covers the entire application lifecycle: build, deploy, and run.

McLean highlighted the importance of catching vulnerabilities early:

“In DevSecOps, it’s just as important—arguably more important—to identify security gaps at build and deploy, such as container and Kubernetes vulnerabilities and misconfigurations, as during runtime.”

Michelle McLean, StackRox

Practically, this means moving beyond runtime detection tools and adopting solutions that:

• Automatically flag risky builds and risky deployment configurations.
• Use orchestration context (such as Kubernetes namespace and workload metadata) to prioritize risk.
• Integrate security feedback directly into CI/CD pipelines so developers receive actionable alerts without leaving their existing workflow.

The goal is to make security tooling a natural extension of the developer experience rather than a separate, adversarial process.

Trend 2: Automation to Close the Security Gap at Scale

No operations team has the bandwidth to manually remediate every vulnerability flagged by scanning tools. The volume of alerts generated by modern security tooling can overwhelm even well-staffed teams, leading to alert fatigue and deferred fixes.

Thomas Hatch, then CTO and co-founder of SaltStack, pointed to automation as the practical answer:

“We are finally seeing a trend where developers are ensuring that deployed code and environments are secure on Day 0, rather than being dictated solely by the opportunity to deploy new apps.”

Thomas Hatch, SaltStack

Automated security remediation—where tooling can apply configuration fixes, revoke over-permissive access, or quarantine a vulnerable container without requiring manual intervention—shifts security from a reactive cost center to a proactive quality layer. When automation is wired into CI/CD pipelines, security checks and fixes happen at the same cadence as feature deployments, rather than lagging behind.

Automation also helps security teams make the business case for DevSecOps: demonstrating that security processes do not slow delivery, but rather protect the delivery pipeline itself.

Trend 3: Accounting for an Expanded Attack Surface

Modern cloud-native architectures—microservices, containers, serverless functions, and complex API meshes—dramatically expand the attack surface compared to traditional monolithic applications. Default configurations in many platforms and frameworks are tuned for ease of use, not security hardness, requiring explicit hardening steps before production deployment.

Jack Mannino, CEO of nVisium, a firm that specializes in integrating security into development processes, noted that issues such as server-side request forgery (SSRF)—where an attacker tricks a server into making requests to internal resources—are receiving more attention precisely because distributed architectures create more trust relationships between components that can be abused.

Mannino’s recommendation:

“It is important that we perform security testing, during development and in production, from different angles to ensure we’re exercising as many code paths as possible.”

Jack Mannino, nVisium

Concretely, this means combining multiple testing strategies rather than relying on a single approach:

• Static Application Security Testing (SAST): Analyzes source code for known vulnerability patterns without executing the application.
• Dynamic Application Security Testing (DAST): Tests running applications by simulating external attacks.
• Software Composition Analysis (SCA): Identifies vulnerable open-source dependencies.
• Infrastructure-as-Code (IaC) scanning: Checks Terraform, CloudFormation, Helm charts, and similar configuration files for misconfigurations before deployment.
• Penetration testing: Human-led adversarial testing to find logic flaws that automated tools miss.

Putting It Together: A DevSecOps Mindset

DevSecOps is not a product you buy or a single tool you deploy. It is an organizational practice built on three pillars: a culture where security is a shared responsibility, tooling that makes secure behavior the path of least resistance for developers, and automation that keeps pace with modern release cadences.

The three trends above—better lifecycle tooling, automation-driven remediation, and multi-angle testing for an expanded attack surface—are concrete starting points for engineering teams looking to mature their DevSecOps practices. Progress in any one of these areas reduces risk; progress across all three creates a genuinely resilient delivery pipeline.

Original reporting sourced from insights.dice.com. Quotes attributed to Michelle McLean (StackRox), Thomas Hatch (SaltStack), and Jack Mannino (nVisium).

DevOps Is No Longer Optional for Enterprises

Software delivery speed has become a direct competitive differentiator. The faster development and operations teams can ship reliable software, the faster an organisation can create customer value, open new revenue streams, and respond to market shifts. DevOps — the combination of cultural practices, process improvements, and tooling that breaks down silos between development and operations — is no longer a trend reserved for digital-native companies. It is a survival imperative for any enterprise navigating digital transformation.

Yet despite widespread awareness of DevOps, many enterprise adoption efforts plateau or fail entirely. The reason is rarely the technology. It is leadership.

Why DevOps Initiatives Stall Without Executive Ownership

Most organisations begin their DevOps journey by implementing automation tools — CI/CD pipelines, infrastructure-as-code, monitoring platforms. This is a logical first step, but it quickly runs into organisational friction: rigid departmental boundaries, slow approval processes inherited from waterfall delivery models, and cultural resistance from teams that feel threatened by change.

These are not tooling problems. They are organisational and cultural problems, and they can only be resolved when leadership actively drives the transformation. Without executive sponsorship, DevOps remains a grass-roots experiment confined to a single team rather than a capability that scales across the enterprise.

The Two Risks Executives Face

Leadership reluctance to commit to DevOps transformation usually comes down to two competing fears:

• Sinking the ship — Making a bold organisational change that fails visibly, damaging the business and the executive’s reputation.
• Missing the boat — Failing to make a necessary change and watching competitors pull ahead as a result.

In stable markets, executives naturally weight the first risk more heavily. But in a period of rapid digital change, missing the boat on DevOps carries a compounding cost: delayed delivery, accumulating technical debt, eroding developer experience, and ultimately an inability to meet customer expectations at the pace the market demands. Organisational agility — the ability to adapt quickly — must be treated as a core business competency, not a nice-to-have.

Four Pillars of Transformational Leadership for DevOps

Aligning a DevOps transformation to business objectives requires leaders to adopt behaviours associated with transformational leadership — a style that motivates through inspiration and purpose rather than pure authority. Four pillars are especially relevant.

1. Create a Clear Vision

A DevOps transformation without a clearly articulated destination will drift. Leaders must define what success looks like in terms the whole organisation understands — not just deployment frequency metrics, but business outcomes. For example:

• If the strategic goal is accelerating product innovation, the DevOps direction should focus on reducing cycle time and creating capacity for experimentation.
• If the goal is improving system reliability, the direction should prioritise observability, incident response automation, and blameless post-mortems.

Vision gives teams a reason to change. Without it, DevOps adoption feels like organisational overhead rather than purposeful improvement.

2. Actively Manage Delivery of That Vision

Vision alone is not enough. Leaders must invest personal effort in understanding how work actually flows through the organisation today — where handoffs break down, where approval gates slow delivery, and where DevOps practices can remove friction. This requires leaders to:

• Participate in value-stream mapping exercises alongside engineering and operations teams.
• Remove organisational impediments that teams cannot resolve at their own level.
• Treat delivery metrics (lead time, deployment frequency, change failure rate, mean time to recovery) as business metrics, not just engineering KPIs.

Leaders who remain at arm’s length from delivery realities send a signal that DevOps is someone else’s responsibility. Leaders who engage directly model the behaviour they want to see.

3. Build Trust-Based Relationships

High-performing DevOps teams are built on psychological safety — the confidence that people can raise concerns, flag failures, and propose ideas without fear of blame. Leaders cultivate this environment through consistent, genuine engagement with their teams: understanding individual goals, providing honest and constructive feedback, and recognising contributions explicitly.

Trust is also what makes blameless incident reviews work. When engineers trust that a post-mortem is about systemic improvement rather than assigning fault, they share information openly — which leads to better fixes and fewer repeat incidents.

4. Motivate Teams to Challenge the Status Quo

DevOps is fundamentally about continuous improvement. Leaders must create the conditions for teams to question existing processes, experiment with new approaches, and learn from the results — including failures. Practically, this means:

• Decentralising decision-making so teams can act on improvements without waiting for approval chains that add weeks of latency.
• Allocating explicit time and budget for learning, experimentation, and tooling improvements.
• Celebrating improvements publicly, even when the initial experiment did not fully succeed.

When leaders encourage teams to operate with greater autonomy, they build an engine for the continuous improvement that DevOps depends on.

Why Transformational Leadership and DevOps Are a Natural Fit

Transformational leadership behaviours — inspiring a shared vision, modelling commitment, building trust, and stimulating innovation — map almost directly onto what high-performing DevOps cultures require. Research into software delivery performance (notably the work published in the State of DevOps reports and the book Accelerate by Forsgren, Humble, and Kim) consistently identifies transformational leadership and organisational culture as stronger predictors of DevOps outcomes than any specific tooling choice.

This alignment also extends to agile practices. Agile delivery and DevOps are complementary: both rely on short feedback loops, cross-functional collaboration, and iterative improvement. Transformational leaders who sponsor agile working will find that DevOps adoption accelerates because the cultural foundations are already in place.

Practical First Steps for Leaders

If your organisation’s DevOps initiative has been running as a purely technical project, here are concrete actions leaders can take to reclaim ownership:

1. Audit your current DevOps narrative. Is the transformation framed in terms of business outcomes or only engineering metrics? Reframe it around value delivery.
2. Attend a sprint review or deployment retrospective. Direct exposure to how teams work — and where they are blocked — changes leadership behaviour more than any report.
3. Identify and remove one cross-team organisational impediment per quarter. Nothing signals leadership commitment like eliminating a bureaucratic obstacle teams have complained about for years.
4. Make DORA metrics visible at the executive level. Lead time for changes, deployment frequency, change failure rate, and mean time to recovery belong in the same dashboard as revenue and customer satisfaction.
5. Sponsor a blameless post-mortem on a recent high-impact incident. Lead by example in separating systemic causes from individual blame.

Conclusion: Leadership Determines DevOps Success or Failure

Tools automate tasks. Processes define workflows. But culture — shaped directly by leadership behaviour — determines whether a DevOps transformation delivers lasting business value or fades into a collection of partially adopted practices. Executives who treat DevOps as a technology initiative delegate accountability to a level that cannot resolve the organisational and cultural barriers that ultimately limit scale.

The enterprises that will thrive in an increasingly software-driven economy are those whose leaders step forward, own the transformation, and model the behaviours that high-performing engineering organisations require. The question is not whether your teams are ready for DevOps. The question is whether your leaders are.

The challenge is that DevOps as a discipline is still maturing. Many people claim expert-level DevOps knowledge but lack the practical experience, contextual insight, and people skills needed to be effective mentors. The following attributes — drawn from practitioners and advisors across the industry — provide a practical framework for evaluating candidates.

Experience Across Both Development and Operations

A qualified DevOps trainer needs grounding in both software development and IT operations — not just one or the other. According to Jai Schniepp, Director of Product for Secure DevOps Platforms at Liberty Mutual Insurance, you want someone who can navigate the natural friction that arises when two historically siloed disciplines are brought together.

A trainer with dual-discipline experience can recommend best practices and appropriate tooling that bridges the developer and operations perspectives, rather than defaulting to a generic, one-size-fits-all approach. Schniepp notes that such a trainer “can maintain focus on the skills and structure needed for the organization,” tailoring guidance to the team’s actual context rather than imposing a rigid framework.

Beyond technical breadth, a strong trainer should also demonstrate organizational aptitude — the ability to prioritize competing concerns, remain flexible as circumstances evolve, and maintain empathy for both the delivery team and the customers they serve.

Emotional Intelligence Is Non-Negotiable

Technical knowledge alone does not make a great DevOps trainer. Justin Rodenbostel, Vice President of Delivery at digital transformation advisory firm SPR, argues that emotional intelligence (EQ) may be the single most important attribute to evaluate.

DevOps adoption is frequently a radical organizational change. It disrupts established workflows, reshuffles responsibilities, and challenges long-held assumptions about how development and operations teams interact. Where radical change occurs, human resistance follows. A trainer who lacks empathy and self-awareness will struggle to bring skeptical team members along — no matter how technically proficient they are.

High EQ enables a trainer to read the room, adjust communication style for different audiences, de-escalate tension, and build the psychological safety that teams need to experiment and learn from failure — all of which are prerequisites for a healthy DevOps culture.

Soft Skills and Change Management Capability

Alan Zucker, Founding Principal of Project Management Essentials, emphasizes that at the start of a DevOps initiative, soft skills training is at least as important as technical instruction. DevOps is fundamentally a mindset — a set of practices and principles that enable organizations to deliver value more rapidly and reliably. It draws on systems thinking to challenge assumptions about end-to-end product value streams and how teams organize their work.

This means effective DevOps trainers must be skilled in:

• Communication: Translating complex technical concepts for non-technical stakeholders, and vice versa.
• Collaboration and facilitation: Running workshops, retrospectives, and cross-functional planning sessions that produce real alignment.
• Negotiation and conflict resolution: Helping teams navigate disagreements about tooling, processes, and ownership boundaries.
• Motivating toward a shared goal: Articulating a compelling vision for what DevOps will deliver and rallying people behind it.

Sara Faatz, Senior Manager of Developer Relations at Progress, frames this succinctly: the trainer must be trustworthy and respected — in effect, a leader. Getting the “people part” of DevOps right — building trust, earning respect, and communicating effectively — is paramount to success.

Technical Depth and Hands-On Practical Experience

While soft skills set the foundation for adoption, technical credibility is what earns a trainer lasting respect from engineering teams. Josh Komoroske, Senior DevOps Engineer at StackRox (a container security software firm), highlights two specific technical requirements:

• Product and toolchain familiarity: The trainer should know the specific tools the team will use — CI/CD pipelines, container orchestration, infrastructure-as-code frameworks, monitoring stacks, and so on — not just DevOps theory in the abstract.
• Real-world deployment experience: Book knowledge of Kubernetes or Terraform is not sufficient. A trainer who has actually deployed, operated, and troubleshot these systems in production environments brings irreplaceable context. They can help teams find practical, creative solutions to real-world DevOps challenges rather than prescribing idealized workflows that don’t survive contact with production systems.

Komoroske also notes that familiarity with the underlying programming language landscape used by the team is a meaningful advantage — it allows the trainer to contextualize DevOps tooling recommendations within the team’s existing technical reality.

Genuine Enthusiasm for Teaching

One attribute that is easy to overlook but difficult to fake is a genuine passion for helping others learn. A trainer who derives satisfaction from watching team members grow will invest more deeply in individuals, adapt their approach when someone isn’t keeping pace, and remain patient when concepts need to be revisited. This quality often separates trainers who produce durable capability from those who deliver a one-time engagement and move on.

Adaptability and the Ability to Hold Multiple Perspectives

No two organizations adopt DevOps in exactly the same way. Team structures, regulatory environments, legacy technology constraints, and cultural starting points all vary. An effective DevOps trainer must be able to view problems from multiple angles and adapt their recommendations accordingly.

As Komoroske puts it: “Different people value different things, and being able to understand this leads to better adoption.” A trainer who insists on a single canonical approach regardless of context will find adoption rates lag — while one who can flex their approach to meet teams where they are will drive faster and more durable change.

Evaluating These Attributes During the Selection Process

Assessing technical skills through structured interviews, code reviews, or tool-specific demonstrations is relatively straightforward. Assessing soft skills and emotional intelligence is harder, but not impossible.

For internal candidates, Faatz recommends 360-degree reviews — gathering structured feedback from the candidate’s peers to understand whether they have already earned trust and respect within the organization. For external trainers, the interview process itself is revealing: observe how they explain complex concepts, how they respond to pushback or skeptical questions, and whether they adapt their communication style to the audience in the room.

Requesting references from previous training engagements and asking referees specifically about the trainer’s ability to manage resistance and communicate with non-technical stakeholders can surface insights that a standard interview will miss.

Summary: A Checklist for Evaluating DevOps Trainers

• Background in both software development and IT operations
• High emotional intelligence and demonstrated empathy
• Strong communication, facilitation, and conflict-resolution skills
• Hands-on experience with the tools and platforms your team uses
• Familiarity with real-world deployment and operations challenges
• Genuine enthusiasm for teaching and mentoring
• Ability to tailor their approach to your organization’s specific context
• Trustworthiness and credibility as a leader — not just a subject matter expert

A trainer who combines deep technical experience with strong interpersonal skills and genuine adaptability is rare — but investing the time to find that person will pay dividends throughout your DevOps transformation and beyond.

This article draws on practitioner perspectives originally published by InformationWeek.

What Is CI/CD?

Continuous Integration (CI)

Continuous integration is a development philosophy and set of practices that encourages developers to commit small, incremental code changes to a shared version-control repository on a frequent basis — often multiple times per day. Each commit triggers an automated build and test process, so integration problems surface immediately rather than accumulating into large, painful merge conflicts later.

The goal of CI is a consistent, automated way to build, package, and test a software application. That consistency reduces integration risk and gives teams the confidence to collaborate on code at higher speed.

Continuous Delivery (CD)

Continuous delivery picks up where CI ends. Once code has passed automated tests in CI, CD automates the process of pushing that code through a sequence of environments — development, testing, staging, and eventually production. The key outcome is that every successful build is potentially releasable; the decision to deploy to production remains a deliberate human one, but the mechanical work is automated.

Continuous delivery relies on continuous testing — automated regression, performance, and security tests that run inside the pipeline — to ensure that only high-quality, secure code advances toward end users.

The CI/CD Pipeline

The CI/CD pipeline is the automated sequence of steps — source control trigger → build → test → deploy → verify — that forms the backbone of the entire process. It is widely considered a foundational DevOps best practice and the mechanism through which agile development teams achieve continuous improvement.

Why CI/CD Adoption Is Growing

Industry observers consistently report rising adoption of CI/CD across organisations of all sizes. Several forces are driving this trend:

• Serverless and cloud-native infrastructure frequently requires automated deployment tooling as a prerequisite, making CI/CD integration effectively mandatory.
• Security requirements demand that developers have limited or no direct login access to production infrastructure, pushing more of that work into automated pipelines.
• Agile methodologies require higher-frequency deployment and testing cycles that are impractical to sustain manually.
• Competitive pressure means that organisations that can release and iterate quickly have a structural advantage over those that cannot.

Hasan Yasar, technical director at the Software Engineering Institute (SEI) at Carnegie Mellon University, has noted that practices such as comprehensive automated testing and continuous delivery — once the domain of well-resourced startups — are now being adopted successfully by traditional enterprises.

Recommended Practices for Implementing CI/CD

1. Involve Key Stakeholders Early

Bring all project stakeholders — developers, QA engineers, IT operations, security, and product owners — into the conversation as early as possible, ideally at project inception. When operations personnel participate in architectural decisions from the start, developers build on infrastructure that has already been reviewed and approved, significantly reducing the technical debt that accumulates when those conversations happen too late.

2. Choose the Right CI/CD System — Then Actually Use It

The CI/CD tooling market offers a wide range of solutions, from open-source options such as Jenkins and GitLab CI to cloud-hosted services. Before committing to a platform, have whoever is responsible for the technical direction of the product lead a structured evaluation of the available options — and solicit input from the developers who will use the system every day, because they are its primary customers.

Once selected, the biggest risk is non-adoption. Most platforms offer free tiers or trials and integrate readily with popular source-control hosts. Start small: automate a single build, a single test suite, or a single deployment step. When team members see the system delivering real value, adoption tends to accelerate organically.

3. Build a Comprehensive Automated Testing Strategy

Continuous delivery depends on confidence in automated tests. A mature CD pipeline typically includes:

• Unit and functional tests — fast, isolated tests written alongside the code.
• Automated regression tests — ensuring that new changes do not break existing behaviour.
• Performance tests — catching throughput or latency regressions before they reach production.
• Security and compliance tests — static analysis, dependency scanning, and configuration validation.
• Environment and orchestration validation — confirming that infrastructure configuration is correct after provisioning.

No single layer of testing is more important than the others; they work together. Complement automated tests with peer code review through pull requests and static analysis tooling.

4. Add Manual Approval Gates at Critical Points

Full automation does not mean zero human judgment. Insert manual approval steps at key junctures — particularly before deploying to staging or production — to prevent untested or unapproved code from advancing and to give teams control over release timing. This is especially important for regulated environments or when releases need to be coordinated with business events.

5. Track Metrics and Continuously Improve

CI/CD is not a one-time implementation; it requires ongoing measurement and optimisation. Useful pipeline metrics include:

• Build duration — how long the end-to-end pipeline takes.
• Test flakiness rate — the percentage of test failures caused by non-deterministic behaviour rather than real defects.
• Deployment frequency — how often code is successfully released.
• Change failure rate — the proportion of deployments that require a hotfix or rollback.
• Mean time to recovery (MTTR) — how quickly the team can restore service after an incident.

Speed matters, but reliability and correctness take precedence. A fast pipeline that produces unreliable results erodes team trust and defeats the purpose of automation. Treat the pipeline itself as a product: measure it, optimise it, and hold it to the same engineering standards as the software it builds.

6. Understand Your Business Drivers and Plan for the Future

Before adopting CI/CD, be explicit about why your organisation needs it. Common objectives include improving developer productivity, reducing time-to-market, increasing deployment frequency, or meeting compliance requirements. Clear objectives make it easier to select appropriate tooling, define success metrics, and demonstrate ROI.

First-generation CI/CD platforms were often built as simple orchestration services. Modern platforms support modular, plug-and-play architectures and pipeline-as-code configuration, giving engineering teams the flexibility to adapt the pipeline as business requirements evolve. Avoid implementing CI/CD in isolated silos that mirror existing manual processes — this approach leads to tool fragmentation, lack of standardisation, and minimal delivery agility.

7. Automate Everything That Can Reasonably Be Automated

Automation is a foundational pillar of DevOps, and CI/CD is one of its primary expressions. Alongside pipeline automation, teams should adopt infrastructure as code (IaC) — managing networks, virtual machines, load balancers, and other infrastructure components through versioned configuration files, using the same practices applied to application source code.

Storing infrastructure code in the same repository as application code gives both developers and operations engineers a single source of truth, enables change tracking, and makes environment provisioning repeatable and auditable. Treat all automated procedures as code: version-control them, review them, and test them.

The Four Components of Continuous Delivery

A mature continuous delivery capability is built from four broad components:

1. Re-architecting for isolation — structuring applications so that individual components or features can be tested and released independently.
2. Test automation — building a comprehensive, reliable automated test suite that gives the team confidence in every build.
3. An automated process pipeline — the end-to-end sequence of build, test, and deploy stages that runs on every commit.
4. Automated environment provisioning and configuration — ensuring that every environment (test, staging, production) can be created and configured consistently and repeatably.

Each component has many individual practices beneath it. The re-architecture requirement — breaking monolithic applications into independently deployable units — is often the most challenging aspect of CD adoption for organisations with existing legacy systems.

Summary

CI/CD is not a single tool or a one-time project. It is a culture, a set of engineering principles, and a collection of practices that work together to make software delivery faster, safer, and more reliable. The organisations that get the most out of CI/CD are those that treat it as a continuous improvement programme: measuring outcomes, iterating on the pipeline, involving stakeholders early, and building automated testing as a first-class engineering discipline — not an afterthought.

Start with CI, automate a build and a test suite, then progressively extend the pipeline into CD. When engineers see the system saving them time and catching real bugs, adoption follows naturally.