DevOps Is More Than a Delivery Pipeline

DevOps is arguably the most influential IT philosophy of the last two decades. It draws on psychology, sociology, systems thinking, and economics to help engineering organizations move faster and more reliably. Companies from AWS to Netflix have credited DevOps practices as central to their ability to scale and innovate.

But DevOps is often reduced to its tooling — CI/CD pipelines, infrastructure-as-code, containerization. The deeper story is how these practices shape team culture: how people collaborate, find meaning in their work, and continuously get better at what they do.

The Three Ways: The Philosophical Core of DevOps

Gene Kim describes the foundational principles of DevOps as The Three Ways: Flow, Feedback, and Continuous Learning and Improvement. These are not just process guidelines — they are a framework for building teams that are engaged, autonomous, and effective.

The First Way: Flow

Flow is about optimizing the movement of work from development through to production. It underpins the practice of continuous delivery: the ability to get changes into users’ hands quickly, reliably, and with minimal friction.

In practice, Flow means:

• Version control — every change is tracked, documented, and reversible. A clear commit history helps future maintainers understand why decisions were made.
• Automated builds and tests — repetitive validation tasks are handed off to machines, reducing human error and freeing engineers for higher-value work.
• Automated deployments — releases become routine events rather than high-risk, high-stress operations.

Beyond efficiency, Flow has a human dimension. When developers can ship meaningful features and bug fixes quickly — without bureaucratic delays or error-prone manual steps — they experience a direct connection between their effort and real-world impact. That sense of purpose is a powerful driver of engagement and job satisfaction.

Flow also demands that teams actively eliminate waste: unnecessary approvals, handoff delays, redundant manual testing, and “toil” — repetitive operational work that scales linearly with system growth. Removing these obstacles is as much about respect for engineers’ time as it is about delivery speed.

The Second Way: Feedback

Continuous delivery without feedback is flying blind. The Second Way builds on Flow by creating fast, reliable feedback loops at every level of the system.

Feedback operates in two directions:

• From production systems — instrumentation, monitoring, alerting, and observability tools that surface the real-world behavior of the software you ship.
• From the development process itself — metrics like deployment frequency, lead time for changes, mean time to recovery (MTTR), and change failure rate (the DORA “four key metrics”) give teams a quantitative picture of their delivery performance.

As systems have grown into web-scale, distributed architectures, the observability challenge has become significant. Netflix’s Atlas monitoring platform — which at one point was tracking over a billion individual time series — illustrates the scale at which modern Ops teams must work. The engineering challenge is not just collecting data, but filtering it: surfacing the signals that actually matter and suppressing noise that would otherwise overwhelm on-call engineers.

A useful analogy: if Flow is the nervous system’s efferent pathways — the signals that drive action and movement — then Feedback is the afferent pathways, carrying sensory information back from the world. Both are necessary for coordinated, effective behavior.

The Third Way: Continuous Learning and Improvement

The Third Way is where Flow and Feedback come together. Teams use the information generated by their systems and processes to experiment, adapt, and improve — continuously and deliberately.

This is also the way that most directly unites Dev and Ops. Examples of how this plays out in practice:

• A new software deployment triggers unexpected CPU spikes. The Ops team raises the alert, the development team investigates, and both collaborate on a fix — learning something about the interaction between the code and the infrastructure.
• An infrastructure change — say, a migration to a new runtime or a network policy update — affects what deployment patterns are viable. Dev teams need to adapt their approach.
• A post-incident review (blameless retrospective) produces documented learnings that prevent the same failure mode from recurring.

Central to the Third Way is a systems perspective: understanding that complex software systems behave in ways that no single team fully controls or predicts. Operating effectively in this environment requires psychological safety, a focus on practical improvement over assigning blame, and the freedom to experiment and learn from failure.

Embedding These Principles in Team Culture

The Three Ways make intuitive sense as principles. Making them real inside an organization is harder — it requires both tooling investment and cultural change.

Moving Away from Command-and-Control Management

One of the defining characteristics of knowledge work — software engineering included — is that the people doing the work often understand the technical details better than their managers do. That’s not a failure of management; it’s the nature of deep specialization. A senior engineer who has spent weeks working inside a distributed caching layer knows things about it that no manager or architect can absorb from a status update.

This reality has a direct implication for how DevOps teams should be structured and led. Hierarchical, directive management — where decisions flow down from those with authority — is poorly suited to environments where expertise is distributed and conditions change rapidly. Instead, effective DevOps leadership means:

• Delegating decision-making to the people closest to the problem.
• Creating clear goals and constraints rather than prescribing solutions.
• Building systems (runbooks, on-call rotations, incident review processes) that capture and distribute learning across the team.
• Fostering psychological safety so that engineers feel comfortable raising concerns, reporting incidents honestly, and proposing changes.

Autonomy as a Driver of Engagement

DevOps, at its best, gives individual contributors the autonomy to act, observe results, and adapt — rather than simply executing instructions. This is not a soft, feel-good benefit. Research in organizational psychology consistently links autonomy, mastery, and purpose to higher performance and lower attrition in knowledge-work environments.

When teams own their deployment pipelines, define their own alerting thresholds, and run their own post-incident reviews, they develop a direct relationship with the outcomes of their work. That ownership is motivating in a way that ticket-based, handoff-driven processes rarely are.

Key Takeaways for DevOps Leaders

• Invest in Flow before anything else. Automation of builds, tests, and deployments is the foundation on which everything else rests. Without it, feedback loops are slow and learning is impaired.
• Treat observability as a first-class requirement. Teams cannot learn from systems they cannot see. Monitoring, logging, and tracing infrastructure should be built alongside the application, not bolted on afterward.
• Make retrospectives and post-incident reviews a genuine practice, not a compliance exercise. Blameless, action-oriented reviews are the mechanism through which Continuous Learning becomes real.
• Restructure for autonomy. Push decision-making authority toward the people with the most context. Managers’ roles shift from directing to enabling and unblocking.
• Measure the right things. The DORA four key metrics — deployment frequency, lead time, change failure rate, and MTTR — are a practical starting point for understanding delivery performance.

Conclusion

The Three Ways are not a checklist. They are a way of thinking about software delivery as a sociotechnical system — one where human motivation, team structure, and tooling all interact. Organizations that implement DevOps purely as a tooling upgrade often get incremental gains. Those that internalize the underlying principles — Flow, Feedback, and Continuous Learning — build teams that are more engaged, more resilient, and more capable of sustained improvement over time.

The question for any engineering leader is not just “what tools should we adopt?” but “what kind of team are we trying to build, and what do our people need to do their best work?”

How many certifications you have and where you live will likely drive what you make as a cloud engineer. Catch the latest cloud salary and hiring trends.

COVID-19 has caused a spike in demand for lucrative cloud-related roles, which could offer engineers an opportunity to take the next step in their careers. However, the adoption of remote working strategies could complicate how professionals are compensated across the IT industry going forward.

The average annual salary for a cloud engineer is just under $129,000, according to ZipRecruiter, an employment marketplace. But this number will vary depending on a few factors, such as where IT pros live and the industries they work in. However, recent industry salary reports indicate that many of the variables that determine cloud computing salaries are in the job candidates’ hands.

For example, a job candidate can boost salary potential by earning relevant certifications or relocating to an emerging tech hub — like Columbus, Ohio or Denver.

Demand for cloud engineers and architects has gone up since the outbreak began, according to Scott Engler, an analyst at Gartner. But the rise of remote work has increased the supply of available talent as well.

“The supply-demand equation just changed,” Engler said. “It allows for more wage arbitrage.”

Remote work also changes the compensation equation around cost of living. A cloud professional now working remotely with a coastal salary may want to relocate to a city with lower living expenses.

Two of the biggest factors that determine your cloud computing salary are how many certifications you have and where you live. Learn how COVID-19 and remote work have altered this equation.

Raise your skills with certifications

IT pros often get certified in specific technologies to improve their skills, but industry certifications are also a popular and affordable way to earn salary bumps.

According to Global Knowledge’s 2019 IT Skills and Salary Report, 85% of IT professionals worldwide — and 81% in North America — have at least one certification. Global Knowledge, a provider of IT skills and training services, examined multiple industries and locations and found that certified professionals earn more than their non-certified counterparts. With each additional certification there is also a small bump in salary. In North America, a certified IT professional earns 7% more than someone who is not certified — the average salary jumps around 2% for each additional certification earned.

Of the 10 certifications that attract the highest salaries in North America, four are cloud related. The Google Cloud Platform Cloud Architect certification is the highest on that list, with certificate earners averaging an annual salary of $152,129. Three different AWS certifications — AWS Certified Solutions Architect – Associate, AWS Certified SysOps Administrator – Associate or AWS Certified Developer – Associate — can translate to salaries around $130,000 a year.

In addition, cross-certifying with a breadth of certifications is a strong way to improve an IT pro’s cloud computing salary, according to Global Knowledge. Cross-certifying with AWS is a particularly attractive option in North America. For example, pairing an AWS certification with one from VMware, Cisco or CompTIA can increase a candidate’s income by more than $10,000.

While in-person certification exams are unavailable at time of publication due the pandemic, each major cloud platform offers certification exams with online proctoring.

The benefits of earning multiple certifications
Relocation is an enticing option, for now
Relocation has long been a way to increase yearly earnings, but that doesn’t mean you should head straight to the San Francisco Bay area. When looking to relocate, cloud professionals need to factor in where salaries are rising, as well as the cost of living in those places.

Cloud professionals just starting out can also pursue opportunities in what Dice, an employment marketplace, calls “emerging tech hubs” in its 2020 Tech Salary Report. In these emerging tech hubs, IT and tech salaries are rising, and cost of living is still relatively low. The highest increases in IT salary have occurred in Columbus, Ohio (14.2%), St. Louis (13.6%), Atlanta (9.5%) and Denver (6.5%).

The 2020 State of Salaries report from Hired, an employment marketplace focused on technology roles, evaluated how far your tech salary would go in certain cities. The report adjusted the average tech salary in major U.S. cities for Bay area living expenses. The report found that adjusted salaries in Austin, Texas and Denver became $224,000 and $202,000, respectively. This explains how, when evaluating whether or not to relocate, candidates should look for how far their money will go, not necessarily how much they could earn.

Remote work brings relocation wrinkle
The rise of remote work has raised a few issues around compensation, especially in terms of cost of living. According to Hired’s report, 53% of tech professionals said a permanent remote working situation would make them likely to move to a city with lower living expenses. If IT pros are working remotely for the foreseeable future, it makes sense for many to move to a more affordable location. However, employers may not want to pay Silicon Valley salaries for employees working from home in Montana.

For example, Facebook said it could shift half of its workforce into remote work within five years, but it would also adjust salaries for cost of living. So, if a Facebook employee moves out of Silicon Valley to work remotely in a more affordable area, the employee’s salary could be reduced.

Unsurprisingly, tech professionals are not on board with altering salaries based on remote work situations. Most tech talent believe remote and in-office employees should be paid the same and would not take a pay cut to work from home on a permanent basis, according to the Hired report.

Remote work has begun to change the way companies seek and compensate tech talent, Engler said. Organizations are now looking to identify pockets of talent around the world and have found them in places like Warsaw, Poland; Chennai, India; Melbourne, Australia; St. Petersburg, Russia; and Mexico City. Remote work offers more opportunity for cloud professionals around the world, but that also means more competition for employment opportunities.

“You’re now going to be competing as a job seeker with someone from Warsaw with some companies,” Engler said.

The tech industry might see wage arbitration on a macro scale over the next year as these conflicts come to a head, Engler said. Employers and job seekers will have to hash out exactly how remote and hybrid work strategies change compensation models over the next year.

From Insult to Industry Standard

Git, the distributed version control system that has underpinned a generation of DevOps tooling and practice, turned 15 in April 2020. Created by Linus Torvalds — best known as the originator of the Linux kernel — Git was named with characteristic irreverence. Torvalds and the broader Linux community jokingly referred to it as “that stupid content tracker,” and the word git itself is British slang for a contemptible or foolish person. The name stuck.

Fifteen years later, the joke has aged rather poorly: Git is now one of the most widely adopted and consequential open source projects in computing history.

A Brief History of Git

Torvalds created Git in 2005, initially to manage the Linux kernel source code after a licensing dispute ended the project’s use of the proprietary BitKeeper system. The goals were clear from the start: speed, strong support for non-linear development (branching and merging), full distribution, and the ability to handle large projects efficiently.

Shortly after its creation, day-to-day stewardship of the project passed to Junio Hamano, a software engineer who has led Git development for the full 15 years since. Hamano works at Google. His long-running maintenance of the project is widely credited with providing the stability and discipline that allowed Git to mature from a Linux-centric tool into a universal standard.

Why Git Won

Non-linear version control was not a new concept when Git launched in 2005 — other systems already supported branching. What set Git apart was the combination of:

• Speed: Most operations are local, making common commands nearly instantaneous compared to centralized systems.
• Cheap, fast branching and merging: Creating a branch in Git is a trivial operation, which encouraged experimentation and short-lived feature branches — a workflow that maps directly onto modern CI/CD pipelines.
• Distributed architecture: Every working copy is a full repository with complete history, eliminating single points of failure and enabling offline work.
• Visualizable non-linear history: Git’s directed acyclic graph (DAG) model makes it possible to reason about complex development histories in a way that linear systems cannot match.

These properties aligned naturally with the principles that would later crystallize into DevOps: automation, collaboration, rapid iteration, and a focus on flow. Git became the connective tissue between source code, CI systems, deployment pipelines, and infrastructure-as-code repositories.

“Git is an essential part of everything we do. It’s the single source of truth.”

Pratik Wadher, Vice President, Intuit

Git’s Place Alongside SQL and Linux

By 2020, organizations across every industry were running DevOps initiatives that depended on Git. GitHub, GitLab, Bitbucket, and related platforms had grown into a multi-billion-dollar segment of the IT industry. Platforms compete on features built around Git — merge request workflows, code review, CI integration, security scanning — but the underlying protocol remains the shared foundation.

“The interesting thing about Git is that it has had real staying power. In terms of industry standards, Git can take its place alongside SQL and Linux in terms of impact.”

Kelly Stirman, Vice President of Product Strategy and Marketing, GitHub

That comparison is worth sitting with. SQL survived decades of competing query languages and NoSQL movements. Linux displaced proprietary Unix variants and now runs the majority of the world’s servers. Git appears to be following a similar trajectory in the version control space.

Ongoing Innovation: Partial Clones and Large File Support

Despite its maturity, Git’s pace of development remained active at the 15-year mark. A notable area of collaborative work involved partial clone capability — a feature that GitLab, GitHub, Microsoft, and Google contributed to together. Rather than requiring developers to clone every file in a repository, partial clones allow a working copy to be initialized with only the objects actually needed for a given task, fetching additional data on demand.

This is particularly relevant for:

• Large monorepos where full clones are prohibitively slow or storage-intensive.
• Game development pipelines that routinely involve binary assets (textures, audio, 3D models) many gigabytes in size.
• Geographically distributed teams for whom cloning over wide-area networks is a recurring bottleneck.

“It will enable new use cases.”

Brendan O’Leary, Senior Developer Evangelist, GitLab

At the time of writing (April 2020), partial clone support was available as an experimental feature in both GitHub and GitLab. Developers working with very large repositories should consult current documentation for each platform to understand what is now generally available.

Git as the Default — Not a Choice

Perhaps the clearest sign of Git’s dominance is that, for most developers entering the industry today, using Git is not a deliberate choice — it is simply how software is managed.

“Git is now the default way to manage source code. Ten years ago that was not the case.”

François Dechery, Chief Strategy Officer, CloudBees

This shift has profound implications for DevOps adoption. When Git is assumed, practices built on top of it — feature branching, pull/merge request workflows, GitOps, trunk-based development — become easier to introduce because teams are not simultaneously learning a new tool and a new methodology.

What Comes Next

Looking beyond the 15-year milestone, several trends point to continued evolution around Git rather than replacement of it:

• GitOps: Using Git repositories as the source of truth for infrastructure and application state, with automated reconciliation loops keeping live environments in sync with declared configuration.
• AI-assisted development: Code generation, review, and suggestion tools that integrate directly into Git-based pull request workflows.
• DevSecOps integration: Security scanning, secret detection, and policy enforcement embedded into Git-hosted CI pipelines rather than applied as a post-deployment afterthought.
• Scalability improvements: Continued work on sparse checkout, partial clones, commit graph acceleration, and other features to keep Git performant as repositories grow.

“It’s been quite a journey. No one really knew 15 years ago just how big an impact the repository would have on software development.”

Ido Green, Vice President of Technology, JFrog

Key Takeaways

• Git was created by Linus Torvalds in 2005 and has been maintained by Junio Hamano ever since.
• Its distributed model, fast branching, and non-linear history support made it a natural fit for DevOps workflows.
• Git now underpins a multi-billion-dollar platform ecosystem spanning GitHub, GitLab, Bitbucket, and beyond.
• Active development — including partial clone support contributed collaboratively by major vendors — shows the project is far from stagnant.
• For most engineers entering the field today, Git is simply assumed — a sign of how completely it has displaced alternatives.

The ten barriers below represent the most common obstacles enterprises encounter, along with practical approaches for overcoming each one.

1. Resistance to the Unknown

People default to familiar processes, especially when they cannot see clear evidence that a new approach will make their working lives better. Sceptical employees need concrete proof — data, real-world case studies, and peer examples — before they will commit to change.

One effective tactic is creating a DevOps champion role or a small champion team. These are subject-matter experts embedded within the business whose job is to build awareness, answer questions, and demonstrate practical wins. The first question a DevOps champion should ask any team is straightforward: What are your current pain points? Automation of repetitive, low-value tasks is frequently the quickest way to generate early enthusiasm.

2. Collaboration Challenges Between Dev and Ops

The classic tension in software delivery is between development teams — who want to push new features to production quickly — and operations teams — who prioritise stability and resist rapid, potentially destabilising changes. Finance and management stakeholders add another layer of resistance, often pushing back on the cost of enterprise-grade tooling.

Breaking down these silos requires visible, sustained executive sponsorship. DevOps cannot succeed as a grassroots-only initiative. C-level leaders must communicate clearly that the organisation is committed to this shift, and that development, operations, and business functions are expected to collaborate rather than compete. A DevOps champion or team can act as an active mediator, translating priorities across departmental boundaries and keeping momentum alive.

3. Obstacles to Experimentation

Fear of failure is a significant brake on DevOps adoption. Engineers and operators who have experienced production incidents — and the performance reviews or customer escalations that follow — are understandably cautious about experimenting with unfamiliar tools or processes.

The answer is to create safe, isolated environments for experimentation: sandboxes where automation tools and new workflows can be tested without affecting production systems. DevOps champions can help assign teams to run these proof-of-concept exercises. When people experience firsthand how automation reduces manual toil and eliminates error-prone steps, resistance tends to drop significantly.

4. Monitoring and Observability Risks

Traditional operations relied on administrators manually parsing plain-text log files — a slow, error-prone process poorly suited to the pace of continuous delivery. Modern DevOps environments require automated, integrated monitoring across the entire CI/CD pipeline, covering coding, testing, integration, and production stages.

Enterprise-grade observability platforms go well beyond log aggregation. They detect anomalous failure patterns, provide visual dashboards of system health, and correlate signals across multiple data sources to surface actionable insights. Selecting and embedding the right monitoring toolchain early in a DevOps transformation prevents observability gaps from becoming production risks later.

5. Architectural Complexity

Enterprise systems are rarely greenfield. Most organisations operate a hybrid landscape: a mix of on-premises infrastructure, multiple cloud providers, and services built across different generations of technology. Integrating these environments into coherent DevOps pipelines is technically demanding.

Interoperability between systems — enabling development and operations teams to work across these boundaries without needing deep expertise in every underlying platform — is a core requirement. Microservices architectures can help by decomposing monolithic applications into independently deployable units, but they require disciplined documentation, standardisation, and shared knowledge to manage effectively. Every service should be blueprinted and its interfaces documented in a centralised knowledge base accessible to all relevant teams.

6. Planning and Measuring Progress

DevOps adoption does not happen organically — it requires a deliberate plan with measurable milestones. Without a structured approach, initiatives lose momentum as competing priorities crowd in.

DevOps champions should be involved in existing project planning processes, ensuring DevOps requirements and metrics are embedded from the start rather than retrofitted later. Continuous monitoring of adoption progress — tracking deployment frequency, lead time for changes, mean time to recovery, and change failure rate — provides the evidence base needed to demonstrate value to stakeholders and to course-correct when adoption stalls.

7. Pipeline Design and Continuous Delivery Constraints

A core DevOps objective is reducing time to market. Continuous delivery (CD) pipelines automate the process of getting validated code into production. However, pipelines that are designed without input from the engineers who use them often create friction rather than removing it.

Developers must be included when deployment workflows are designed. Pipeline templates that standardise how delivery is implemented across teams reduce inconsistency and make it easier to track progress against milestones. The goal is not just speed — it is consistent, measurable progress toward deployable software at every stage of development.

8. Budget and Tooling Costs

Open source tooling is often assumed to be free, but that assumption overlooks the real costs: staff training, integration effort, ongoing maintenance, and the absence of vendor support when issues arise. Enterprises that assemble a DevOps toolchain by adopting individual open source tools piecemeal can end up with a fragmented, expensive-to-maintain environment.

A thorough total-cost-of-ownership analysis — comparing integrated enterprise platforms against a collection of single-purpose tools — should be presented to finance and executive stakeholders before tooling decisions are made. For smaller organisations with strong engineering capacity, open source solutions may indeed be more cost-effective. For large enterprises, the support, integration, and compliance features of commercial platforms often justify the higher licence cost. DevOps champions are well placed to model these trade-offs and present credible ROI projections.

9. Communication Across Distributed Teams

Global enterprises routinely operate with development teams distributed across multiple time zones, often supplemented by remote contractors or consultants. Without deliberate communication practices, distributed teams become siloed — the same “us and them” problem that DevOps seeks to solve at the organisational level reappears at the team level.

The tooling for effective remote collaboration — asynchronous communication platforms, shared documentation systems, video conferencing, and version-controlled wikis — is mature and widely available. The harder challenge is cultural: establishing shared norms around how decisions are documented, how async and sync communication are balanced, and how remote contributors are kept as informed as co-located colleagues. This became an acute issue for many organisations navigating the shift to fully remote working, and the lessons learned continue to apply as hybrid working becomes standard.

10. Legacy Systems and Technical Debt

Legacy applications are among the most stubborn barriers to DevOps adoption. These systems frequently lack modern APIs, do not integrate cleanly with CI/CD toolchains, and are often maintained by a shrinking pool of engineers familiar with older programming languages and architectures.

Ignoring legacy systems in a DevOps transformation plan is not an option — they underpin critical business processes. A pragmatic approach is to bring in specialists with deep knowledge of the legacy stack to document how these applications interact with modern systems and to identify realistic integration or migration paths. Incremental strangler-fig patterns — gradually replacing legacy components with modern services — can reduce risk compared to big-bang rewrites. The key is making the legacy landscape visible and explicitly accounting for it in planning and resource allocation.

Building a Realistic DevOps Adoption Roadmap

The barriers described above rarely appear in isolation. A large enterprise will typically face several simultaneously, and the relative weight of each will vary depending on the organisation’s size, industry, existing culture, and technical maturity. A successful DevOps adoption roadmap acknowledges this complexity and sequences interventions deliberately — starting with cultural foundations, establishing early wins through automation and sandboxed experimentation, and progressively tackling harder structural challenges like legacy integration and toolchain consolidation.

DevOps champions, sustained executive commitment, and a metrics-driven approach to measuring progress are the common threads that run through every successful enterprise DevOps transformation. None of these barriers is insurmountable, but all of them require deliberate, sustained effort to overcome.

What Is a Spinnaker Pole?

A spinnaker pole is a spar used on sailing vessels to extend the foot of a spinnaker sail away from the mast, allowing the sail to fill with wind on downwind or reaching points of sail. Unlike a boom, which is attached to the mast and the foot of the mainsail, a spinnaker pole is typically clipped to the mast at one end and to the spinnaker’s tack at the other, and it is removed and stowed when not in use. The pole must be strong enough to handle significant compressive and lateral loads while remaining as light as possible to minimise the effect on the vessel’s centre of gravity.

Material Types: Composite vs. Metal

Spinnaker poles are broadly manufactured in two material categories:

Composite Poles

Carbon fibre and fibreglass composite poles have become the dominant choice in performance and racing applications. Carbon fibre poles offer an exceptional strength-to-weight ratio, allowing sailors to carry longer poles without the associated weight penalty. The reduction in polar moment of inertia at the bow of the boat can make a meaningful difference in light-air performance and boat handling. Composite poles are also more resistant to corrosion in salt water environments, reducing long-term maintenance demands.

Metal Poles

Aluminium alloy poles remain widely used in cruising and club-racing contexts where cost, repairability, and durability take priority over minimum weight. Aluminium is easier to machine and repair than carbon fibre, fittings can be replaced or modified in the field, and the material is less susceptible to catastrophic failure from impact. For amateur leisure sailors or budget-conscious club racers, an aluminium pole represents a practical and affordable solution.

Application Segments

The market is generally divided into two end-use segments:

• Professional Sports: Offshore racing classes, grand prix inshore racing, and fully crewed ocean races such as the Rolex Fastnet Race or Jules Verne Trophy campaigns demand the highest-specification poles. Budgets in this segment are less constrained, and teams routinely commission custom-built poles engineered to specific class rules and structural load calculations.
• Amateur Leisure: Club racers, cruiser-racers, and coastal cruising sailors make up the larger volume segment by unit count. Price sensitivity is higher, replacement cycles are longer, and the emphasis is on reliability and ease of use over marginal weight savings.

Key Manufacturers in the Spinnaker Pole Industry

The following companies were identified in the original market research teaser as notable participants in the global spinnaker pole market. Brief descriptions are based on publicly available information about each manufacturer’s positioning; no claims about market share or revenue are made.

• AG+ Spars: A specialist spar manufacturer known for carbon fibre masts and poles for racing yachts.
• Allen Brothers: A UK-based marine hardware and rigging company supplying components and poles across cruising and racing markets.
• Axxon Composites: A composite spar builder focused on high-performance racing applications.
• Competition Composites Inc. (CCI): A Canadian manufacturer of carbon fibre spars with a long history supplying offshore and grand prix racing teams.
• CST Composites: An Australian composite manufacturer producing carbon tubes and spars for the marine industry.
• Forespar: A US-based company well known for aluminium and carbon spinnaker poles as well as associated hardware, popular in the cruising market.
• Hall Spars & Rigging: A high-end spar builder with a strong presence in grand prix racing and superyachts.
• Heol Composites: A French composite manufacturer supplying performance sailing hardware and spars.
• Offshore Spars: A specialist in offshore racing spar solutions.
• Optiparts – Windesign: A Dutch company primarily known for dinghy and one-design class equipment, supplying poles for smaller racing classes.

Regional Dynamics

Demand for spinnaker poles is closely correlated with sailing participation rates and the density of racing and cruising fleets. The following regions represent the primary markets:

• United States: A large base of cruiser-racers and a well-established offshore racing scene support consistent demand across both composite and aluminium poles.
• Europe: Home to some of the most competitive offshore racing fleets in the world, including the IRC Grand Prix circuit and the IRC offshore championships. European markets — particularly the UK, France, Germany, and the Netherlands — are strong consumers of high-specification composite poles.
• China and Southeast Asia: Growing sailing participation and an expanding recreational boating sector represent longer-term growth opportunities, though the market remains at an earlier stage of development compared to Western Europe and North America.
• Japan: A mature sailing market with established racing circuits and a preference for quality marine hardware.
• India and Central & South America: Emerging markets where coastal recreational sailing is growing, though these regions currently represent a smaller share of total spinnaker pole demand.

Factors Influencing the Market

Several structural factors shape the competitive landscape and purchasing decisions in the spinnaker pole market:

• Class rules: Many racing classes prescribe pole length, diameter, or material constraints, which directly limits the specification manufacturers can target for those fleets.
• Carbon fibre supply chain: The cost of aerospace-grade carbon fibre prepreg and raw tube stock has a direct impact on composite pole pricing, making the segment sensitive to broader aerospace and materials market conditions.
• Advances in resin systems: Improvements in epoxy and toughened resin systems continue to improve the impact resistance and fatigue life of composite poles.
• Self-tacking and furling sail systems: On some modern cruising designs, asymmetric spinnakers launched from a bowsprit are replacing traditional symmetric spinnakers entirely, reducing demand for conventional poles on new builds.

Summary

The spinnaker pole market is a specialised segment of the broader marine hardware and rigging industry. It is characterised by a clear division between composite products targeting performance racing applications and aluminium products serving the larger cruising and club-racing base. Manufacturers range from specialist composite spar builders serving grand prix racing to broad-line marine hardware companies whose pole ranges form part of a wider cruising hardware catalogue. Demand is geographically concentrated in established sailing markets in North America and Western Europe, with emerging growth in Asia-Pacific.

For specific market sizing, forecast data, or competitive share analysis, consult a specialist marine industry research provider directly.

Background: AWS Executive Moves to Google Cloud

Amazon has settled a lawsuit against Philip Moyer, a former Amazon Web Services (AWS) sales executive who left the company in 2019 to join rival Google Cloud. The case drew significant attention in the tech industry as an example of how aggressively cloud providers defend proprietary knowledge and customer relationships through non-compete agreements.

Amazon hired Moyer in 2017. Before joining AWS, he had spent 15 years at Microsoft and served as chief executive of software-as-a-service companies Edgar Online and Cassiopae. After approximately two years at AWS, Moyer grew dissatisfied with what court documents described as a lack of growth potential and accepted a role at Google Cloud as Vice President of Sales for Healthcare and Life Sciences.

Amazon’s Lawsuit and Core Arguments

Amazon filed suit against Moyer in July 2019, arguing that his move to Google Cloud threatened the disclosure of Amazon’s highly confidential information and constituted a breach of his non-compete agreement. The company’s concern centered on the fact that Moyer’s expertise at AWS was in financial services — a sector in which Google Cloud was actively competing.

Moyer’s legal team countered that his new role — focused on healthcare and life sciences customers — served an entirely different customer base from his AWS work, and therefore did not violate the terms of his non-compete agreement.

Federal Judge Limits Moyer’s Role, Criticizes Amazon’s Policies

In October 2019, U.S. District Court Judge Ricardo Martinez took a middle-ground approach: rather than fully enforcing or fully rejecting the non-compete, he placed significant limitations on Moyer’s activities at Google Cloud. Specifically, Moyer was prohibited from:

• Working on any financial services projects at Google Cloud
• Contacting any existing AWS customers
• Contacting any potential financial services customers

These restrictions were set to remain in place until the lawsuit was fully resolved or until Moyer’s non-compete agreement expired in November 2020. Notably, Judge Martinez also took the opportunity to criticize Amazon’s broader non-compete policies.

This outcome is consistent with Washington state law, which allows courts to “reform” — rather than void outright — a non-compete agreement, narrowing its scope to what is considered reasonable rather than simply invalidating it entirely.

Settlement and Dismissal

U.S. District Court Judge Ricardo Martinez dismissed the case on March 2, 2020, with no award of fees or costs to either party — a typical outcome in a negotiated settlement. Because the parties reached a private agreement, the specific terms of the settlement are not publicly disclosed. Amazon declined to comment on the decision.

Washington State’s Non-Compete Law: Key Provisions

The Moyer case played out against the backdrop of Washington state’s 2019 legislation tightening restrictions on non-compete enforcement. The law introduced several important limits:

• Salary threshold: A non-compete agreement is only enforceable if the employee earns more than $100,000 per year.
• Duration cap: Non-compete agreements cannot extend longer than 18 months.
• Court reformation: Courts may narrow — not just void — overly broad non-competes to a scope they deem reasonable.

Amazon reportedly lobbied to have the salary threshold lowered during the legislative process, a position that drew criticism given the company’s scale and the number of employees it could potentially subject to non-compete restrictions.

Broader Implications for Cloud Industry Talent Competition

The Moyer case is a high-profile example of a wider trend: as AWS, Microsoft Azure, and Google Cloud compete intensely for enterprise customers, they are also competing fiercely for experienced sales and technical talent. Executives with deep relationships in sectors like financial services, healthcare, and government are particularly valuable — and particularly at risk of being subject to aggressive non-compete enforcement when they change employers.

Critics of non-compete agreements argue they suppress worker mobility, stifle innovation, and disproportionately benefit large corporations that can afford prolonged litigation. In sectors like cloud computing, where institutional knowledge and customer relationships are central to competitive advantage, these tensions are especially acute.

Google underscored its commitment to competing with Amazon in Seattle by opening a large new campus for its cloud division adjacent to Amazon’s Seattle headquarters — a visible statement of intent in the talent market as well as the enterprise sales market.

Key Takeaways for DevOps and Cloud Professionals

• Non-compete agreements at major cloud providers are enforceable under certain conditions, even when you move to a nominally different role or vertical at a competitor.
• Washington state law gives courts flexibility to narrow — not simply void — overly broad agreements, which can result in partial restrictions rather than a complete block on employment.
• The salary threshold ($100,000 as of the 2019 Washington law) and duration cap (18 months) are important limits to understand if you are employed in Washington state.
• The specific industry vertical or customer base you work with can be a deciding factor in how courts interpret whether a competing role truly conflicts with a prior non-compete.
• Settlement terms in these cases are typically confidential, so public outcomes may not reflect the full picture of what either party agreed to.

Continuous updates and features are key to delivering a consistent and reliable user experience. Software companies need to go the extra mile to compete long-term and build strong relationships with their user base. This is where DevOps comes in.

DevOps is a culture philosophy and agile methodology that combines development and operations. It’s clear that DevOps has a strong presence over at Apple headquarters; on any given day, you’ll find plenty of DevOps engineers positions listed on the Apple market.

In a LinkedIn post, the company stated, “We are passionate about continuously improving the way we enable the software development lifecycle and push the envelope to reimagine cutting edge solutions to engineering problems of scale.”

Here’s how DevOps plays a role over at Apple—from its early heyday to modern times.

Apple’s Minimum Viable Product

Apple has had a lengthy reputation for its secretive nature, which makes it difficult to understand what’s happening behind closed doors in Cupertino. However, you can make some conclusions about their lean approach and agile methodology by analyzing their product history.

For instance, Steve Wozniak built the first Apple computer as a minimum viable device—aesthetically, it resembled more a typewriter than a modern computer.

Since then, the product has gone through a vast number of iterations and code changes.

At the time, however, there were no solid DevOps tools on the market. Integration tools from companies like JFrog weren’t yet in place, and Kubernetes and Helm were far from inception.

Without a structured process, Wozniak and Jobs had to take a manual route to continuous integration and continuous development. Engineer Bill Atkinson even used a Polaroid camera to take a photo of each milestone in the interface development process.

In the book, “Revolution in the Valley: The Insanely Great Story of How the Mac Was Made,” Andy Hertzfield stated, “Instead of arguing about new software ideas, we actually tried them out by writing quick prototypes, keeping the ideas that worked best and discarding the others. We always had something running that represented our best thinking at the time.”

Leveraging the CI/CD Pipeline

Continuous integration / continuous delivery plays a key role in Apple’s software development. This practice is comprised of processes that allow teams to push code changes quicker, re-enforce code integrity and security, and automate build and deployment steps.

There’s no doubt that Apple utilizes this agile methodology. In 2018, they acquired BuddyBuild, a CI/CD service for mobile apps. With this tool, developers are able to build a smoother workflow in terms application beta testing. Buddybuild was quickly rolled into Xcode, an integrated development environment for Apple’s product suite.

The acquisition falls in line with Apple’s approach to integrating tools that build upon its software agenda, and the company has a reputation for buying smaller startups in an effort to leverage new technology. Back in 2014, they also acquired TestFlight, a beta deployment and analytics platform.

Continuous Testing

Under Tim Cook’s management, iOS update frequency increased by 51%. Test automation helps engineers boost test coverage. Armed with support from CI/CD tools, test scripts can automatically generate builds, deploy those builds, and test them.

Mobile features and applications have become increasingly robust and complex, requiring a more thorough and in-depth testing process. Still, bugs will inevitably slip past automation detection, even if these cracks are notably smaller than those you’d find in a software company that relied on traditional forms of siloed testing. Apple needs to consistently release quick patches when major bugs—and even small vulnerabilities—are discovered.

With these key factors in mind, testing is arguably an important part of the DevOps process, and indeed one of the most notable benefits of implementing DevOps in the first place. And when it comes to software with multiple iterations and nuances, there’s no denying that automated testing—coupled with a much smaller percentage of manual testing—is key.

For instance, when Apple hosted its WWDC conference in San Jose in June 2018, they announced that iOS 12 would be compatible with devices dating back to 2013. This was big news for the tech giant, who has received backlash regarding old devices no longer working and increasing pressure to invest in newer devices for a better user experience. This meant that DevOps teams would have to expand their testing capabilities to include running new operating systems on older devices. With this expanded testing environment grounded in DevOps, Apple became better positioned to run programs flawlessly regardless of the device.

Why Cloud Skills Are Increasingly Valuable

Enterprise adoption of cloud services has accelerated significantly over the past decade. Organisations are migrating workloads, retiring on-premises data centres, and building cloud-native applications at a pace that consistently outstrips the supply of skilled professionals. This demand-supply gap makes cloud expertise one of the most sought-after skill sets in information technology today.

For professionals, this translates into strong job prospects and competitive salaries. For organisations, it means that finding, developing, and retaining cloud talent is a strategic priority — not just an HR exercise.

The Talent Gap: A Persistent Challenge for Organisations

Hiring cloud specialists — particularly those with hands-on experience in advanced or open-source technologies — is both difficult and expensive. Three trends are driving this challenge:

• Rapid platform evolution: AWS, GCP, and Azure each release dozens of new or updated services every year. Keeping a team current requires continuous, structured learning — not a one-time certification push.
• Breadth of required skills: Modern cloud roles span infrastructure-as-code, security, cost optimisation, containerisation, serverless architectures, and more. Few professionals are experts across all areas.
• Competition for talent: Technology companies, financial institutions, healthcare organisations, and retailers all compete for the same limited pool of experienced cloud engineers.

Many organisations are responding by investing in internal upskilling programmes, partnering with training providers, and building structured learning paths so that promising generalists can grow into specialist roles.

Why Cloud Is a Strong Career Choice

Cloud computing consistently appears near the top of employer skill-demand surveys and salary benchmarking reports. Key reasons include:

• Broad applicability: Cloud skills are relevant across almost every industry vertical — from retail and media to finance and government.
• Multiple career pathways: Cloud knowledge underpins roles such as cloud architect, cloud engineer, DevOps engineer, site reliability engineer (SRE), security engineer, and data engineer.
• Certifications with market recognition: Vendor certifications from AWS, GCP, and Azure are well-recognised by hiring managers and provide measurable proof of competency at various levels.
• Convergence with adjacent technologies: Cloud platforms are the primary delivery mechanism for machine learning, big data pipelines, IoT workloads, and DevOps toolchains — making cloud skills synergistic with other high-growth areas.

Key Cloud Platforms to Know

While the cloud market includes many providers, three platforms dominate enterprise adoption and drive the majority of job demand:

• Amazon Web Services (AWS): The longest-established hyperscaler, with the broadest service catalogue. AWS certifications are widely held and widely respected.
• Microsoft Azure: Particularly strong in organisations already invested in the Microsoft ecosystem, including Active Directory, Windows Server, and Office 365.
• Google Cloud Platform (GCP): Known for its strengths in Kubernetes (which originated at Google), data analytics (BigQuery), and machine learning (Vertex AI).

Many organisations operate in a multi-cloud or hybrid-cloud model, so familiarity with more than one platform — and with abstraction tools such as Terraform or Kubernetes — adds significant value.

How to Build Cloud Skills Effectively

Theoretical knowledge alone is not enough. The most effective cloud learning programmes combine structured instruction with hands-on lab work. When evaluating any cloud training option, look for:

• Hands-on labs: Real-environment exercises (not just simulations) where you deploy, configure, monitor, and troubleshoot actual cloud resources.
• Coverage of core services: Compute, storage, networking, identity and access management (IAM), databases, and monitoring are foundational across all platforms.
• Pathway to certification: A quality programme should align its curriculum with the official exam objectives for at least one recognised vendor certification.
• Exposure to adjacent technologies: DevOps tooling (CI/CD pipelines, containers, Kubernetes), big data services, and security fundamentals are increasingly expected alongside core cloud skills.
• Up-to-date content: Cloud platforms evolve rapidly. Check that course material is actively maintained and reflects current service offerings.

Free and Low-Cost Learning Resources

Before committing to a paid programme, explore the substantial free resources available from the cloud providers themselves and from the broader community:

• AWS Skill Builder: AWS’s official learning portal offers free and paid digital training, including role-based learning paths and exam preparation.
• Google Cloud Skills Boost (formerly Qwiklabs): Provides hands-on labs and learning paths, with some content available free of charge.
• Microsoft Learn: Microsoft’s self-paced learning platform covers Azure services, certifications, and broader DevOps topics at no cost.
• Linux Foundation and CNCF: For open-source cloud-native technologies, including Kubernetes and service mesh, the Linux Foundation and the Cloud Native Computing Foundation offer courses and certifications.
• Community resources: Blogs, YouTube channels, and forums such as the AWS subreddit and the CNCF Slack workspace provide peer learning opportunities.

Choosing a Structured Training Programme

For learners who prefer a guided, end-to-end curriculum — particularly those transitioning from non-cloud backgrounds — a structured programme offered by a university, bootcamp, or accredited training provider can provide accountability, mentorship, and a recognised credential.

When comparing programmes, consider the following criteria:

• Duration and time commitment per week
• Instructor quality and industry experience
• Hands-on lab hours versus lecture hours
• Platform coverage (single-cloud vs. multi-cloud)
• Alignment with industry certifications
• Alumni outcomes and employer partnerships
• Cost and available financing options

Staying Current After Your Initial Training

Cloud knowledge has a shelf life. Services are deprecated, new managed offerings replace self-managed stacks, and best practices evolve. Maintaining relevance requires ongoing effort:

• Follow official cloud provider blogs and release notes for the services you use.
• Renew or upgrade certifications on the schedule required by the vendor (typically every two to three years).
• Participate in community events such as re:Invent (AWS), Google Cloud Next, and Microsoft Ignite — many sessions are available free online after the event.
• Build side projects or contribute to open-source infrastructure projects to maintain hands-on proficiency.
• Join professional communities and local user groups (AWS User Groups, GDG Cloud, Azure Meetups) to exchange knowledge with peers.

Summary

Cloud computing skills represent one of the most durable investments a technology professional can make. The demand for skilled practitioners spans every industry and shows no sign of slowing as organisations deepen their dependence on cloud infrastructure and cloud-native development patterns. Whether you are starting from scratch or deepening existing expertise, the combination of structured learning, hands-on practice, recognised certifications, and ongoing community engagement is the most reliable path to staying competitive in this field.

ETF managers appeared on CNBC’s ETF Edge to discuss which investment themes were gaining the most traction and why financial advisors were increasingly treating ETFs as a primary portfolio tool rather than a supplementary one.

Cloud Computing: A Theme Driven by Big Tech, Not Just ETF Marketing

Jay Jacobs, then head of research and strategy at Global X ETFs, made the case that cloud computing stood out as the single hottest investment theme at the time—and argued that the signal was coming from the technology sector itself, not from fund marketers.

“One of the hottest themes right now is cloud computing. And you don’t have to listen to us. Look at what the big tech companies are talking about in their earnings. AWS is most of what Amazon’s focusing on. IBM is replacing their CEO with the head of their cloud unit. Microsoft? All they want to talk about is Azure and their 60% revenue growth. Alphabet is now breaking out their cloud revenue from the rest of their revenue reporting.”

Jay Jacobs, Head of Research and Strategy, Global X ETFs

Global X positioned its Cloud Computing ETF (ticker: CLOU) to capitalize on this shift. Rather than including large-cap technology conglomerates like Amazon or Alphabet—which derive only a portion of their revenue from cloud services—the fund was deliberately tilted toward pure-play Software-as-a-Service (SaaS) companies built on and around cloud infrastructure. Top holdings at the time included Shopify, Paycom, Paylocity, and Zscaler.

As of mid-February 2020, CLOU had climbed more than 15.5% year to date and held approximately $476 million in net assets. Jacobs emphasized the appeal of recurring, subscription-based revenue models that SaaS companies typically employ—describing them as sticky, growth-driven business structures that distinguish pure-play cloud names from broader technology conglomerates.

Robotics and AI: Giving Investors Access to Companies They Don’t Yet Know

Global X extended the same thesis to robotics and artificial intelligence through its Robotics & Artificial Intelligence ETF (ticker: BOTZ). The fund’s top holdings included Nvidia, European industrial automation company ABB, and Intuitive Surgical—names that many retail investors in the US may not immediately associate with the robotics space.

Jacobs argued that this unfamiliarity was precisely the problem a thematic ETF is designed to solve. Investors may be convinced that automation and AI adoption are accelerating, but identifying the specific companies best positioned to benefit—particularly non-US manufacturers and specialized hardware providers—requires research that most retail investors don’t have time to conduct.

“They see that automation is getting more powerful, that companies are investing in robotics, they’re investing in bringing in AI systems, but they don’t really know where to start. Who are the big robotics companies? They’re not common knowledge to U.S. investors. The ETF is a perfect example of giving people that exposure to the companies best positioned in the space.”

Jay Jacobs, Global X ETFs

BOTZ was up more than 3% year to date at the time of the interview and held more than $1.5 billion in net assets—reflecting its more established track record compared to the newer CLOU fund.

Fixed Income ETFs: A Trillion-Dollar Market Still Growing

While thematic equity funds attracted attention, larger ETF issuers were seeing their own wave of inflows—in fixed income. Armando Senra, then head of iShares Americas at BlackRock, noted that a low-rate environment was pushing investors toward emerging market debt and high-yield bonds as yield-pickup strategies.

“We do believe rates are staying lower. That’s why we’re also recommending emerging market debt and high yield as a way to pick up yield, because we have a moderate-constructive view on market risk. With fixed income ETFs, what you see is the replacement of bonds for fixed income ETFs.”

Armando Senra, Head of iShares Americas, BlackRock

Over half of 2019’s net ETF inflows had gone into fixed income ETFs, a category that had grown to approximately $1 trillion of the overall market. Senra had previously stated, in a September 2019 appearance on ETF Edge, that the fixed income ETF market could double within five years—a projection that reflected the broader institutional shift away from holding individual bonds toward using ETFs as a more liquid fixed income vehicle.

Advisor Adoption: The Broader Force Behind ETF Growth

Ed Rosenberg, then head of ETFs and senior vice president at American Century, framed the overall surge in ETF interest as a function of momentum within the financial advisory community. As more advisors incorporate ETFs into their standard toolkits, demand naturally flows into a wider variety of fund types—both thematic and broad-market.

“As the landscape shifts and advisors want more and more ETFs, they’re going to look to different versions, whether it’s thematic or whether it’s basic. They’re just going to come more into play. We’ve never been off to the start that I’ve seen and, quite frankly, it looks like we could be in for a great year for all of us.”

Ed Rosenberg, Head of ETFs, American Century

Key Takeaways for Investors and Advisors

• Thematic ETFs like CLOU and BOTZ allow investors to express conviction in long-term technology trends without needing to identify individual winners.
• Pure-play focus matters: funds that concentrate on companies whose core business is cloud or robotics behave differently from broad tech ETFs that include these as side businesses.
• Fixed income ETFs are increasingly replacing direct bond holdings, particularly in low-rate environments where investors seek yield through emerging market debt or high yield.
• Advisor adoption is a structural tailwind for ETF growth across all categories—thematic, factor-based, and plain-vanilla index funds alike.
• Liquidity and transparency are core reasons institutional and retail investors prefer ETF wrappers for fixed income exposure over holding individual bonds.

Note: All figures, fund performance data, and AUM figures cited in this article reflect information reported as of mid-February 2020 and are included for historical context only. They do not represent current fund performance or holdings.

Three Pillars of Continuous Delivery Success

Ten years after the publication of Continuous Delivery by Dave Farley and Jez Humble, the two authors took the stage at DeliveryConf to reflect on progress made and lay out what they believe the next decade must look like for CD to mature across the industry. Their central argument: succeeding with CD is not a purely technical problem. It demands simultaneous progress across three deeply interrelated dimensions—technical performance, organizational performance, and cultural performance.

Research from DORA (DevOps Research and Assessment) supports this framing. Technical practices can lead the way, but they cannot drive lasting change on their own. Organizations that neglect the human and structural dimensions of delivery will hit a ceiling regardless of how sophisticated their tooling becomes.

What the Deployment Pipeline Actually Means

A common misreading of Farley and Humble’s original book is that teams should build a separate pipeline for each environment. Farley called this an anti-pattern. The deployment pipeline is meant to be a single mechanism: changes enter at one end, and releasable software emerges at the other. The goal is the continuous delivery of ideas—fast, validated feedback from real users telling you whether your assumptions were correct.

In the decade since the book was published, several practices have grown up around this core model, including distributed tracing, chaos engineering, and traffic shifting (canary releases and feature flags). These techniques all serve the same underlying purpose: reducing the risk and cost of change while accelerating the feedback loop.

“Teams need to have a great story on these technical practices to have great technical performance, which is a necessary driver for CD.”

— Dave Farley, DeliveryConf

Technical Performance: Engineering Discipline at the Core

Farley frames software development as fundamentally about two things: learning and managing complexity. Effective CD practices must optimize for both.

• Optimizing for learning: Use fast feedback loops, work incrementally, and run controlled experiments. The smaller the batch size, the quicker you learn whether a change delivers value.
• Managing complexity: Apply sound architectural principles—modularity, separation of concerns, high cohesion, and loose coupling. These properties make systems easier to change safely and independently.

“It’s about engineering—applying rational scientific thinking to solving practical problems within economic constraints.”

— Dave Farley, DeliveryConf

Organizational Performance: Structure Enables Autonomy

Even technically excellent teams will struggle to deliver continuously if the organizational structure works against them. Farley defines organizational performance as building team structures that enable genuine collaboration and sufficient autonomy. Teams that must constantly coordinate with other teams to ship a change are structurally constrained from practicing CD.

Farley referenced The Art of Action by Stephen Bungay as a useful model for understanding this challenge. Organizations pursue outcomes through plans and actions, but three gaps inevitably appear: a knowledge gap (not knowing enough to plan perfectly), an alignment gap (people acting on different interpretations), and an effects gap (actions not producing the expected outcomes). These gaps cannot be eliminated, but they can be reduced—through tighter feedback loops, smaller batches of work, and clearer intent communicated throughout the organization.

Cultural Performance: The Hardest Problem

Cultural performance—how teams behave, how diversity of thinking is valued, and how technical rigor is maintained day-to-day—is the dimension most frequently underestimated. Farley referenced a Harvard Business Review article arguing that the biggest impediment to adopting agile practices is not a lack of methodology, evidence, or proof of concept. It is executive behavior.

“Organizations can’t succeed at doing CD on one of these aspects without the others.”

— Dave Farley, DeliveryConf

The audience discussion at the end of the session surfaced practical strategies for influencing executive behavior:

• ROI and cost analysis: Quantifying the business value of CD—reduced lead time, lower failure rates, faster recovery—gives executives a concrete case to evaluate. This is often a necessary starting point.
• Reframe the conversation: Farley argued that you will not win senior leaders by talking about deployment pipelines. You win them by talking about the organization’s ability to evolve and respond to market change.
• Generate an emotional response: One audience member pointed out that ROI alone rarely changes culture. The classic observation applies here: culture eats strategy for lunch. Leaders need to feel the urgency of change, not just see a spreadsheet justifying it.

Humble’s Expectation: Real Continuous Integration First

Jez Humble stressed that one of his most important expectations for the next decade is straightforward but widely ignored: teams should actually practice Continuous Integration as it is defined. That means developers integrate their work into a shared mainline branch—or merge feature branches into the mainline—at least once per day. When the build breaks, it is fixed within approximately ten minutes. Reliable, automated tests validate every change.

Without this foundation, the rest of the CD pipeline is built on unstable ground. Long-lived feature branches, infrequent merges, and flaky test suites are among the most common reasons CD initiatives stall before they deliver value.

Feedback as the Engine of Innovation

Humble also emphasized that fast feedback is not just an operational concern—it is critical to innovation. Most new ideas turn out to be wrong. The faster an organization can find that out, the less waste it produces and the sooner it can pivot to something better.

In Accelerate, Humble, Nicole Forsgren, and Gene Kim describe the goal of modern product delivery this way:

“Product delivery is about building an engine that gives you quality feedback promptly, enabling a deterministic flow from development to production—this is the engine where product ideas bake in.”

— Accelerate, Forsgren, Humble, and Kim

Key Takeaways for Practitioners

• A deployment pipeline is a single end-to-end mechanism, not a separate pipeline per environment.
• Technical, organizational, and cultural performance are inseparable. Invest in all three or expect diminishing returns.
• Reduce knowledge, alignment, and effects gaps by working in smaller batches and communicating intent clearly.
• Architects and engineers should optimize for learning (fast feedback, incremental work) and for managing complexity (modularity, loose coupling).
• Genuine CI—daily integration into a shared mainline with fast automated tests—is a prerequisite for everything else.
• To influence executives, speak in terms of business agility and market responsiveness, not deployment frequency metrics alone.

Source: InfoQ coverage of DeliveryConf, featuring Dave Farley and Jez Humble.

DevOps Is a Process Change First, a Technology Change Second

When organizations embark on a DevOps transformation, the instinct is often to reach for tools: CI/CD pipelines, infrastructure-as-code frameworks, container orchestrators. Technology is genuinely important, but it is not the hardest part. The hardest part is changing how people think, collaborate, and work. Without breaking down organizational silos and realigning individual incentives, even the most sophisticated toolchain will fail to deliver the expected benefits.

Process change either gets embraced and succeeds, or it gets rejected and fails. That binary outcome is driven almost entirely by people and culture, not by which tools are on the approved vendor list.

The Infrastructure Delivery Gap

A recurring symptom of immature DevOps adoption is slow, ticket-driven infrastructure delivery. Industry surveys have repeatedly found that a large share of IT organizations still rely on manual, ticket-based processes to provision infrastructure, meaning developers wait days or weeks for environments rather than minutes. When self-service infrastructure is unavailable, time-to-market suffers and productivity drops across the entire software delivery chain.

The goal of DevOps—complete automation and seamless integration across development and operations—is well understood. Achieving it in practice, however, means replacing legacy workflows that have existed for years, which is a significant organizational undertaking.

Four Key Challenges That Go Beyond Technology

1. Lack of a Clear Vision

Without a clear definition of what problems DevOps is meant to solve and what success looks like, teams quickly find themselves circling the same issues without making progress. A vague vision makes it impossible to set meaningful milestones or define deliverables. Teams end up choosing tools reactively rather than strategically, which adds confusion and risk.

The skill gap compounds this problem. There are far more DevOps tools available than there are practitioners with deep expertise across all of them. When leadership lacks a clear vision, that imbalance leads to poor tooling decisions and wasted investment.

2. Cultural Resistance

People default to familiar methods, especially when those methods have historically produced acceptable results. The cultural shift DevOps demands—shared ownership between development and operations, continuous feedback loops, collective accountability for reliability—runs counter to the blame-oriented, siloed culture common in traditional IT organizations.

Resistance is not irrational. Changing established workflows carries real risk of disruption, and individuals naturally protect their established routines. Recognizing this resistance as a legitimate organizational challenge, rather than simply inertia to be pushed through, is essential for sustainable change.

3. Insufficient Tool Knowledge

DevOps introduced the principles of continuous integration, continuous delivery, automated testing, and collaborative monitoring. But teams that are deeply familiar with traditional tools often struggle to adopt newer ones, particularly when those tools involve architectural shifts—such as moving from on-premises infrastructure to cloud-native patterns or adopting declarative infrastructure-as-code.

When teams lack tool knowledge, they make poor tooling choices, under-utilize the capabilities they do have, and create fragile pipelines that require constant manual intervention—exactly the opposite of what DevOps aims to achieve.

4. Risk Analysis and Change Management

Replacing established processes with new methodologies introduces real operational risk, and that risk must be managed deliberately. Business stakeholders often need extensive dashboards, metrics, and reporting to feel confident approving changes. Building that reporting infrastructure takes time and expertise. Teams frequently find that getting started is straightforward, but maintaining momentum as complexity grows is significantly harder.

Six Practical Ways to Minimize These Challenges

1. Establish a Clear Productivity Goal

Ground your DevOps initiative in a specific, measurable productivity outcome—reduced deployment frequency, shorter lead time for changes, lower mean time to recovery. Automation and monitoring tools are the mechanisms; a concrete goal is the reason to adopt them. When developers have a lighter manual burden, error rates fall and delivery speed increases.

2. Embrace Team Diversity

DevOps teams that bring together people with diverse backgrounds—development, operations, security, QA—consistently outperform those composed of specialists working in isolation. This diversity of perspective surfaces blind spots early and accelerates problem-solving. As full-stack engineering becomes more common, building cross-functional habits into your team structure from the start pays long-term dividends.

3. Normalize Learning From Failure

In blame-oriented cultures, people hide mistakes to protect their careers. In mature DevOps organizations, incidents and errors are treated as learning opportunities. Blameless post-mortems, shared failure retrospectives, and psychological safety are not soft concepts—they are engineering practices that drive systemic improvement. When teams feel safe surfacing problems, those problems get fixed before they become critical outages.

4. Integrate Security Early and Continuously

Security practices that are bolted on at the end of the delivery cycle create bottlenecks and ship vulnerabilities. Integrating automated security scanning, static analysis, and dependency checking directly into the CI/CD pipeline—the DevSecOps approach—allows teams to catch issues early when they are cheapest to fix. Security ownership must be shared across the team, not delegated entirely to a separate security group.

5. Focus on Team Capability, Not Just Tool Selection

New tools accelerate DevOps adoption only when the team using them understands how to apply them correctly. Prioritize integrating new tooling thoughtfully into existing infrastructure and validate that each addition meets your security and compliance requirements. More importantly, invest in ensuring your team has the knowledge to use those tools effectively—a well-understood simpler tool almost always outperforms a complex tool used poorly.

6. Invest in Ongoing Education and Training

DevOps tooling and practices evolve rapidly. Structured, regular training—whether through internal workshops, external courses, or community participation—is not optional overhead; it is a core investment in your delivery capability. Teams that stay current with evolving practices adapt faster, make better architectural decisions, and are more resilient when facing new challenges.

Final Thoughts

Successful DevOps implementation is not an overnight project, and it is not primarily a technology project. It requires sustained advocacy, strong leadership, deliberate cultural change, and an organizational commitment to continuous learning. The teams that succeed are those that address the human and process dimensions of DevOps with the same rigor they apply to their pipelines and infrastructure. Acknowledge the challenges, invest in the people, and build the culture—the technology will follow.

What Is the DevOps Market?

“Development to Operations” (DevOps) refers to a set of cultural practices, processes, and tools designed to tighten the feedback loop between software development and IT operations teams. By emphasizing automation, continuous integration and delivery (CI/CD), collaboration, and shared accountability, DevOps helps organizations ship software faster, with fewer defects, and at lower operational cost.

As enterprises increasingly treat software delivery as a core business capability, analyst coverage of the DevOps tooling and services market has grown significantly. The figures below are drawn from a Trusted Business Insights report covering the period 2019–2026.

Market Size and Growth Rate

According to the report, the global DevOps market was valued at approximately USD 2.77 billion in 2016 and was projected to expand at a compound annual growth rate (CAGR) of 18.60% through the forecast period ending in 2026.

The primary growth drivers identified include:

• Cloud adoption: Enterprises migrating workloads to cloud platforms accelerate demand for containerization, microservices, and Platform-as-a-Service (PaaS) tooling—all tightly coupled with DevOps practices.
• Automation investment: Reducing manual intervention in build, test, and release pipelines lowers cost and improves release frequency.
• IoT, mobility, and BYOD: Expanding device ecosystems increase software complexity, making automated lifecycle management more valuable.
• Regulatory pressure in financial services: Faster, auditable delivery pipelines help organizations meet changing compliance mandates.

Key restraints cited in the report include the complexity of DevOps adoption within legacy-heavy organizations and the lack of universally standardized tooling, which can lead to fragmented, hard-to-maintain toolchains.

Market Segmentation

By Deployment Model

• On-premises: Preferred by highly regulated industries (finance, healthcare, government) that require strict data sovereignty and audit controls.
• Cloud: The faster-growing segment, driven by the scalability and managed-service economics of public and hybrid cloud environments.

By Enterprise Size

• Small and Medium Enterprises (SMEs): Often adopt SaaS-delivered DevOps tools to minimize upfront infrastructure investment.
• Large Enterprises: Tend to deploy multi-tool, integrated DevOps platforms with significant customization and governance requirements.

By Vertical

Regional Outlook

North America — Dominant Market

North America held the largest regional share at the time of the report. The concentration of major DevOps vendors (IBM, CA Technologies, Cisco, Hewlett Packard Enterprise, Chef, Puppet Labs, Docker) in the United States, combined with high enterprise IT spending and mature cloud infrastructure, underpins continued leadership.

Asia-Pacific — Fastest Growing

The Asia-Pacific region was projected to grow the fastest over the forecast period, driven by rising investment in cloud and IoT infrastructure, smartphone penetration, and growing demand for digital services across India, China, Japan, and Southeast Asia.

Europe, Middle East & Africa, Latin America

These regions show increasing adoption, particularly in financial services (Europe) and telecommunications (MEA), though growth rates lag North America and APAC. GDPR and similar data-residency regulations influence deployment model choices in Europe.

Key Vendors and Competitive Dynamics

The DevOps tooling market is highly competitive. Vendors named in the report include:

• IBM Corporation
• CA Technologies (acquired by Broadcom in 2018)
• Cisco Systems
• Hewlett Packard Enterprise (HPE)
• Docker, Inc.
• Puppet Labs
• Chef (now Progress Chef)
• EMC Corporation (now part of Dell Technologies)
• Clarizen

The report notes that vendors are pursuing both organic and inorganic growth strategies:

• Mergers and acquisitions: CA Technologies’ acquisition of Automic (IT automation and service orchestration) was cited as a representative example of portfolio expansion through M&A.
• R&D and innovation labs: Major players are establishing centers of excellence and collaborating with research institutions to accelerate product development.
• Strategic partnerships: Smaller specialist vendors are partnering with platform providers to extend reach and integration depth.

What This Means for DevOps Practitioners

Market sizing reports like this one are primarily aimed at investors and business strategists, but the underlying trends carry practical implications for engineers and platform teams:

• Toolchain consolidation pressure: As vendors acquire each other, integrated platforms (GitLab, GitHub Actions, Azure DevOps, AWS CodePipeline) increasingly bundle capabilities that once required separate point solutions. Evaluate build-vs-buy trade-offs accordingly.
• Cloud-native is the default: The market’s shift toward cloud deployments validates investments in container orchestration (Kubernetes), infrastructure-as-code, and managed CI/CD services.
• BFSI acceleration: Financial services teams face growing pressure to adopt DevSecOps practices that satisfy both speed-to-market and compliance requirements simultaneously.
• Standardization still matters: The report’s citation of “lack of standardized tools” as a barrier remains relevant. Establishing internal platform engineering teams and golden-path templates can reduce toolchain fragmentation.

Limitations of This Data

This article is based on a 2019 market research report with a base year of 2016–2017. The DevOps landscape has changed substantially since publication:

• Several named vendors have been acquired (CA Technologies → Broadcom; Chef → Progress; EMC → Dell).
• New entrants—particularly GitHub Actions, GitLab CI, and cloud-native equivalents from AWS, Azure, and GCP—have materially altered competitive dynamics.
• Forecast figures (CAGR, market size) should not be cited as current without verification against a more recent primary source.

For current market sizing, consult up-to-date analyst reports from firms such as Gartner, IDC, or Forrester before making investment or vendor-selection decisions.

Overview

At the DevOps Enterprise Summit (DOES) 2019, BMW’s Ralf Waltram (Head of R&D) and Dr. Frank Ramsak (Head of IT Governance) presented the state of their ongoing IT transformation—described internally as the largest transformation in BMW’s history. The initiative, which began in 2016, is driven by a strategic shift from being purely a car manufacturer to becoming a mobility provider. Their session offered candid lessons for any large organization undertaking a major Agile and DevOps transformation.

The Problem: Two Speeds, Two Cultures

Before the transformation, BMW IT operated a classic waterfall delivery model, shipping large projects with tightly coupled application dependencies. Releases were so risky they were regularly scheduled for weekends to minimize business disruption.

BMW had adopted a bimodal IT model as an interim step, but it created as many problems as it solved:

• 20% of teams were working in Agile (two-week sprints).
• 80% of teams were still operating on annual waterfall release cycles.
• Agile teams were consistently blocked waiting on waterfall teams, negating the speed advantage of sprinting.
• Two distinct working cultures emerged, creating friction rather than collaboration.

Two structural silos compounded the problem: one between development and operations, and another between IT and the business. Both silos slowed delivery and made it difficult to prioritize customer value.

The Solution: Products, BizDevOps, and 100% Agile

To break down these silos, BMW IT made two foundational decisions:

1. Move from projects to products — organizing work around long-lived product teams with persistent ownership rather than temporary project structures.
2. Adopt BizDevOps — extending the DevOps model to formally include business stakeholders, ensuring transparency and shared accountability across IT and business functions.

The goal was 100% Agile adoption: a single, unified way of working that is customer-centric, value-driven, and flexible enough to support BMW’s evolving mobility business model.

The Four Cornerstones of BMW’s Transformation

BMW designed a holistic transformation framework built on four cornerstones:

1. People and Culture

Waltram and Ramsak identified people and organizational culture as the single most important factor in the transformation’s success. BMW rolled out organization-wide training on Agile values and practices before making structural or tooling changes. Cultural readiness was treated as a prerequisite, not an afterthought.

2. Structure

Development and operations were brought together into integrated DevOps teams. At the portfolio level, the IT landscape was reorganized around products and value streams rather than functional departments. This restructuring aimed to deliver:

• Minimum governance overhead at the portfolio level
• Maximum synchronization and team autonomy

3. Process — Changing How Work Is Funded

One of the most impactful process changes was how BMW funds its IT work. Historically, projects and operations were funded through separate budget streams—a model that reinforced the project-vs-product divide. Starting in 2019, BMW shifted to funding products and teams directly, tying investment to business value rather than project scope. This is a common enabler of Lean portfolio management and a critical step for sustaining long-lived product teams.

4. Technology

To support the new ways of working, BMW introduced technologies enabling microservice and cloud-based architectures, gradually replacing legacy monolithic applications. The team also developed a unified Agile software development toolchain now used by approximately 20,000 employees, providing end-to-end development visibility and synchronization across the organization.

Measurable Results

The business recognized and validated the transformation’s impact. Key outcomes reported by Waltram and Ramsak include:

• Release frequency increased from 12 releases per year to approximately 2 per month.
• Defect rates and time-to-resolution decreased significantly (specific metrics were not published in the summarized source).

Key Lessons and Recommendations

Waltram and Ramsak closed their presentation with practical guidance for organizations facing similar transformations:

• Set a bold transformation vision, but resist the urge to execute it all at once. Start small, deliver in increments, and scale what works.
• Embrace iterative learning. Small increments allow rapid inspection and course correction—something that is genuinely difficult to sustain in organizations with a deeply ingrained culture of perfection and high performance, as BMW openly acknowledged about itself.
• Learn from the community. Waltram and Ramsak encouraged organizations to participate in DevOps and Agile communities, share transformation experiences openly, and learn from peers rather than treating transformation approaches as proprietary.

Why This Matters for Enterprise DevOps

BMW’s transformation is a relevant case study for any large, traditional enterprise modernizing its software delivery. Several of their decisions reflect proven patterns in enterprise DevOps literature:

• Eliminating bimodal IT in favor of a single operating model
• Moving from project to product funding to sustain long-lived teams
• Extending DevOps to include business stakeholders (BizDevOps)
• Using value streams as the organizing principle for portfolio management
• Treating culture change as a prerequisite to process and tooling changes

For organizations still running hybrid waterfall/Agile models, BMW’s experience illustrates that the two speeds create more drag than the waterfall baseline they were meant to replace.

The Gap DevOps Was Supposed to Close

In theory, DevOps exists to bridge the cultural and operational divide between software developers and IT operations (ITOps) teams. Shared tooling, shared pipelines, shared responsibility — that is the promise. In practice, however, the conversation around DevOps culture often tilts heavily in one direction: ITOps engineers are encouraged to write more code, learn programming languages, and speak the language of developers, while comparatively little pressure flows the other way.

This asymmetry is not just a cultural nuisance. It is a structural problem that undermines the core goals of DevOps: faster, more reliable software delivery through genuine collaboration.

Why Developers Receive More Recognition Than ITOps

The IT industry — and broader society — tends to celebrate creators over maintainers. Software developers are frequently portrayed in popular media as near-magical problem solvers. Coding boot camps have proliferated across every major city. Developer salaries consistently rank among the highest in the technology sector.

ITOps engineers, whose core responsibilities include deploying, monitoring, patching, and sustaining production systems, receive comparatively little of that recognition. Help-desk and junior operations roles are often among the lowest-paid positions in IT. There are no boot camps specifically designed to train the next generation of infrastructure operators. No one is making prestige films about an engineer who prevented a production outage at 2 a.m. by applying the right kernel patch.

This is not a pattern unique to IT. Across many industries — architecture, automotive, construction — the people who design things are held in higher regard than the people who keep them running. Architects outrank roofers. Car designers outrank mechanics. The IT world simply mirrors a much wider social norm: creation is glamorous; maintenance is invisible.

DevOps Is Exacerbating the Problem

The cult of programming would likely exist with or without DevOps. What DevOps sometimes does, however, is give that bias a formal framework and a job description. Beneath a great deal of DevOps advocacy is an implicit assumption: if ITOps engineers just wrote more code, everything would be faster, higher quality, and easier to automate.

Infrastructure-as-Code tools, configuration management frameworks, and CI/CD pipelines are all valuable — but the way they are sometimes introduced to ITOps teams can feel less like empowerment and more like a requirement to become a developer or become irrelevant. The message, spoken or not, is often: learn to code or fall behind.

Contrast that with the expectation placed on developers. Very few DevOps advocates actively push developers to spend meaningful time provisioning infrastructure, responding to on-call incidents, or managing the operational health of systems in production. When that suggestion is made, it is often met with resistance — the argument being that requiring developers to perform operational tasks is a distraction from higher-value engineering work. There is a revealing double standard at work here.

The Risk: Erasing ITOps Expertise

The danger in this imbalance is not abstract. When organizations treat ITOps engineers purely as developers-in-waiting rather than domain experts in their own right, several things can go wrong:

• Loss of operational expertise: Deep knowledge of networking, storage, security patching, and system performance does not come from a coding boot camp. Devaluing that expertise means organizations lose institutional knowledge that is hard to replace.
• Morale and retention problems: Operations teams that feel undervalued or pushed toward roles they did not sign up for are more likely to leave. Turnover in ITOps can directly degrade system reliability.
• False confidence in automation: Automating operations tasks without the input of people who truly understand those tasks leads to brittle pipelines and missed failure modes. Good automation is built on operational expertise, not in spite of it.
• Shared responsibility becomes one-sided accountability: When incidents happen, the implicit bias toward blaming the operations side rather than the development side undermines psychological safety — a prerequisite for effective post-mortems and continuous improvement.

Where Workflow Automation Fits In

One of the most compelling arguments for workflow automation in DevOps is that it can reduce the need for either side — developers or ITOps — to become fluent in the other’s core discipline. Well-designed automation abstracts the operational complexity without requiring ITOps engineers to become software engineers, and without requiring developers to master infrastructure management.

For ITOps teams specifically, automation platforms can:

• Codify runbooks and operational procedures into repeatable, auditable workflows — without requiring deep programming knowledge.
• Integrate monitoring, alerting, and remediation into a single automated loop, reducing manual toil.
• Surface operational data in ways that make it easier for developers to understand and account for production constraints during design.
• Enable self-service infrastructure provisioning, freeing ITOps from repetitive tickets while maintaining guardrails and governance.

The key distinction is that workflow automation, when implemented correctly, should amplify ITOps expertise rather than replace it. The engineer who understands why a particular service requires a specific firewall rule or memory allocation is still the person who needs to design that automated check. The automation just executes it consistently and at scale.

Toward a More Equitable DevOps Culture

Sustainable DevOps practice requires genuine parity between development and operations — not just in tooling, but in culture, recognition, and organizational investment. That means:

• Recognizing operational work as engineering work. Designing a resilient deployment pipeline, writing runbooks, and maintaining production SLAs are engineering tasks that deserve the same organizational respect as feature development.
• Creating reciprocal expectations. If ITOps engineers are expected to understand code and pipelines, developers should be expected to understand — at least at a meaningful level — what happens to their software after it ships.
• Investing in ITOps career development on its own terms. Not every ITOps engineer needs to become a software developer. Organizations should create career paths that reward deep operational expertise alongside paths that reward cross-functional development skills.
• Measuring shared outcomes. Deployment frequency, change failure rate, mean time to recovery, and availability are team metrics, not individual metrics. Tying both developers and ITOps to shared reliability goals is a structural way to rebalance incentives.

The Bottom Line

The promise of DevOps was collaboration between equals. That promise is undercut when ITOps teams are implicitly asked to assimilate into development culture while developers remain largely insulated from operational concerns. Workflow automation has real potential to accelerate DevOps delivery — but only if it is built with ITOps expertise at the center, not as a mechanism for rendering that expertise redundant. Getting the culture right is a prerequisite for getting the automation right.

Edureka Adds 20 New Technology Certification Programs

Edureka, a global online learning platform focused on technology education, announced the addition of 20 new certification programs to its course catalog. The new programs target high-demand areas including Automation, Artificial Intelligence (AI), DevOps, Cloud Computing, and Data Visualization — disciplines where the gap between industry demand and available talent has grown sharply.

What’s Covered in the New Programs

The newly launched courses span a range of modern technology disciplines. Key additions to the catalog include:

• Robotic Process Automation (RPA) — targeted at software testing professionals looking to adopt next-generation automation skills
• Automation Testing — designed to help QA engineers modernize their skill sets
• Microsoft Azure — expanding Edureka’s existing cloud computing portfolio
• Salesforce — covering CRM platform development and administration
• DevOps and AWS DevOps — combining DevOps methodology with Amazon Web Services tooling
• Artificial Intelligence and Machine Learning — foundational and applied programs for data-driven roles

Each program is delivered as an instructor-led, live online course and includes real-world case studies and practical demonstrations — a format common to Edureka’s broader catalog.

Why These Technologies, and Why Now

The course additions reflect industry trends that were gaining momentum in 2019 and have continued to accelerate. RPA platforms automate repetitive rule-based tasks, reducing manual workload in business operations. Cloud platforms such as Microsoft Azure and AWS enable organizations to scale infrastructure without heavy capital investment. DevOps practices compress software delivery cycles and improve reliability, while AI and Machine Learning are increasingly embedded in product development and data analytics workflows.

Vineet Chaturvedi, Co-Founder of Edureka, commented on the rationale behind the rapid expansion:

“The IT industry is growing at a rapid pace, and businesses are incessantly dependent on different technologies that can drive strategic business decisions. To help bridge this gap between industry needs and talent availability, we focus on constantly introducing certifications that are not only affordable but also relevant for IT professionals. In fact, we launch a new course or an upgrade to an existing course every fortnight; that’s how fast technologies and their applications are evolving. Technologies such as Robotic Process Automation, Azure, Testing, DevOps, Artificial Intelligence, Machine Learning are going to be the biggest job creators in the coming years and the right choice for tech professionals.”

— Vineet Chaturvedi, Co-Founder, Edureka

Context: Skills Gaps Driving Online Tech Education

The launch is part of a broader trend in which online education platforms respond to rapidly shifting enterprise technology adoption. Organizations implementing cloud-native architectures, CI/CD pipelines, and intelligent automation often struggle to hire professionals already trained in those specific toolchains. Instructor-led online programs — particularly those offering structured projects and recognized certifications — have become a practical route for working engineers to upskill without interrupting employment.

The 20 new programs bring Edureka’s total catalog to more than 200 courses at the time of this announcement, covering technologies in active global demand.

Key Takeaways for IT Professionals

• RPA and Automation Testing courses are specifically aimed at software testing professionals seeking career transitions or skill upgrades.
• Azure and Salesforce additions strengthen cloud and CRM coverage in the catalog.
• AWS DevOps courses bridge the gap between DevOps methodology and AWS-specific tooling — a combination increasingly required in job postings.
• All programs are instructor-led and online, making them accessible to professionals in distributed teams or remote locations.
• The course-every-fortnight release cadence is worth noting for engineers who want to track new learning opportunities aligned with emerging technologies.

For the most current course offerings, visit edureka.co directly, as the catalog has continued to evolve since this announcement.

The Hybrid Cloud Promise vs. Reality

Cloud computing was supposed to lower the cost of IT. For many organisations, the opposite has happened. Operating multiple cloud platforms in parallel with existing on-premises infrastructure has introduced a new layer of operational complexity — and with it, unexpected expense. IT leaders who thought they were trading capital expenditure for predictable operational costs are discovering that managing a fragmented multi-cloud estate can cost more than the environments it was meant to replace.

This tension is the defining IT management challenge of the current era, and understanding its root causes is the first step toward addressing it.

The Multi-Cloud Reality: Adoption Without Integration

Research from International Data Corp. (IDC) illustrates the scale of the problem. According to the survey cited in the original reporting:

• 64% of customers are already using multiple clouds.
• Only 24% have achieved a high degree of interoperability between those cloud environments.
• Another 40% report low interoperability between their clouds.
• Just 7% have built a true hybrid cloud — one in which multiple IT environments are managed through a single control plane.

That last figure is the critical one. Managing disparate cloud and on-premises environments in isolation from each other drives up operational overhead significantly. Without a unified management layer, teams end up context-switching between platforms, duplicating monitoring tooling, and applying inconsistent security and governance policies.

Ad-Hoc Migration Is Driving Up Costs

A separate survey of 900 IT professionals conducted by Syncsort (a provider of data management software) reveals a related problem: most organisations lack a coherent cloud strategy.

• Only 29% of IT organisations have a centralised strategy and a centre of excellence for proactively planning and managing cloud migrations.
• 42% admit they migrate applications to the cloud on an ad-hoc basis.
• 57% report that management costs exceeded expectations.
• 62% identified data and application migration costs as a significant challenge.

Syncsort CTO Tendü Yoğurtçu points to lift-and-shift migrations as a common culprit: organisations move legacy applications to the cloud without re-architecting them, and then discover that cloud unit economics do not favour workloads designed for static, on-premises hardware. The result is a cloud bill that surprises finance teams and undermines the business case for migration.

“They lift and shift applications to the cloud. But costs are higher than expected.”

— Tendü Yoğurtçu, CTO, Syncsort

Cloud Fundamentals Are Still Not Solved

Even with years of cloud adoption behind them, many IT organisations are still working through foundational questions. A survey of 200 IT executives commissioned by Insight Enterprises identifies four major hurdles to cloud implementation:

• Determining which workloads should move to the cloud — cited by 72% of respondents.
• Need for new tools to support and monitor cloud applications — 70%.
• Internal resistance to change — 70%.
• Choosing the right cloud deployment model — 69%.

Despite these obstacles, 75% of organisations surveyed have a “cloud-first” policy for new workloads. But only 45% have a cloud-only strategy, with 30% adopting what they describe as a “cloud priority” approach — signalling that many are retaining significant on-premises footprints by design rather than by inertia.

Steve Zipperman, general manager for cloud consulting services at Insight Enterprises, frames the core principle simply:

“It’s all about the workload. Not every workload can be deployed in a private cloud.”

— Steve Zipperman, General Manager, Cloud Consulting Services, Insight Enterprises

DevOps Adoption Is Happening in Silos

Cloud transformation almost always requires organisations to modernise their internal delivery processes, and DevOps adoption is central to that effort. However, Zipperman notes that in most organisations this transition is occurring in isolated pockets rather than as a coordinated, enterprise-wide programme. Teams in one business unit may be operating mature CI/CD pipelines while others still rely on manual change management processes.

This uneven adoption creates inconsistency in how applications are built, deployed, and operated across environments — which in turn makes unified hybrid cloud management harder to achieve. Broad, organisation-wide DevOps maturity is likely still several years away for most enterprises.

The Hybrid Cloud Is the Agreed Destination

Despite the implementation challenges, the industry has largely converged on hybrid cloud as the target architecture. A survey of 2,300 IT professionals published by Nutanix (a provider of hyper-converged infrastructure software) finds that 91% of respondents identify the hybrid cloud as their ideal IT model. The top driver — cited by 97% — is the desire to move applications freely between cloud environments.

That flexibility is, in essence, a cost-control strategy. Organisations want the leverage to shift workloads between cloud providers based on price, performance, or compliance requirements — playing providers off one another rather than being locked in to a single platform’s pricing model.

Cloud Cost Optimisation Tooling Matures

A category of cloud cost optimisation tooling has emerged to help organisations right-size their cloud spending. These tools analyse consumption patterns, identify idle or over-provisioned resources, and — increasingly — apply machine learning to recommend or automate rightsizing decisions.

Consolidation is already underway in this space. As one example cited in the original reporting, Apptio (a provider of IT cost management tools) acquired FittedCloud, a cloud optimisation platform using machine learning algorithms. Apptio CEO Sunny Gupta describes the goal as allowing organisations to right-size workloads dynamically rather than relying on periodic manual reviews:

“IT organizations want to be able to right-size workloads in real time.”

— Sunny Gupta, CEO, Apptio

This points to a broader trend: as hybrid cloud environments grow in complexity, the tooling required to manage them is becoming a competitive market of its own.

How Major Vendors Are Responding to Hybrid Cloud Demand

The scale of enterprise demand for hybrid cloud management has not been lost on the major platform vendors. Several significant strategic moves reflect this:

• IBM and Red Hat: IBM’s acquisition of Red Hat (valued at approximately $34 billion at the time of reporting) was positioned explicitly around enabling hybrid cloud strategies, leveraging Red Hat’s open-source middleware and OpenShift Kubernetes platform.
• AWS Outposts: At AWS re:Invent 2018, Amazon Web Services announced plans to deliver AWS-managed infrastructure for on-premises environments — effectively extending the AWS control plane into customer data centres.
• Google and Anthos: Google moved to extend its cloud reach by enabling Kubernetes workloads to run on VMware infrastructure in on-premises environments, the initiative that would become Google Anthos.
• Microsoft Azure: Microsoft has promoted Azure Arc and Azure Stack as mechanisms for running Azure services consistently across cloud and on-premises deployments.
• VMware and Dell Technologies: VMware — and its parent Dell Technologies — have pursued a strategy of extending the VMware management plane into multiple public clouds, arguing that organisations with existing VMware investments can achieve hybrid cloud without replacing their on-premises management tooling.

“IT organizations are looking for ways to rationalize the management of multiple clouds. All the cloud savings are being eaten up by increased operational costs.”

— Matt Baker, SVP Strategy and Planning, Dell EMC

Practical Takeaways for IT and DevOps Teams

The pattern across all of this research and vendor activity points to a set of actionable principles for teams navigating hybrid cloud adoption:

1. Start with workload classification. Not every application benefits from the cloud. Assess workloads for cloud suitability before migrating, rather than defaulting to lift-and-shift.
2. Avoid ad-hoc migration. Establish a cloud centre of excellence — even a small one — to bring consistency and governance to migration decisions.
3. Prioritise a single management plane. The organisations achieving the most interoperability are those managing multiple environments through unified tooling. Evaluate platforms that span your entire estate rather than deploying separate tools per cloud.
4. Instrument cost from day one. Cloud cost optimisation is significantly easier when tagging, cost allocation, and budget alerting are in place before workloads are deployed.
5. Expand DevOps practices organisation-wide. Siloed DevOps adoption creates inconsistency that compounds the complexity of multi-cloud operations. Treat cultural and process change as equal in importance to tooling.
6. Plan for portability. Architect applications to be portable between environments where possible, using container orchestration and abstraction layers to avoid deep platform-specific coupling.

Conclusion

The hybrid cloud is not a future state — it is already the operational reality for most enterprise IT organisations. The challenge is that the majority are managing it reactively, with fragmented tooling, inconsistent processes, and costs that continue to exceed projections. Closing the gap between multi-cloud sprawl and a genuinely managed hybrid environment requires deliberate strategy, unified management tooling, and organisation-wide process maturity. The vendors are building the platforms; the harder work is internal.

What shapes the long-term success of your CI/CD effort? A faster, more automated pipeline for software development? We recently outlined 4 success factors when getting started with CI/CD – and all led back to culture.

That’s helpful, but it’s also productive to look at the downsides – not of CI/CD itself, but of common mistakes organizations make, especially when they’re just starting out.

“If done right, proper continuous delivery and integration can lead to great customer experiences,” says Joy Scharmen, director of DevOps at Optimizely.

In the interest of doing CI/CD right, we asked Scharmen and other IT leaders to share some of the common ways teams go wrong. Here’s what they had to say.

1. Don’t follow the recipe for tool salad

I could walk into a Home Depot today and buy a bunch of expensive tools and materials; I’d walk out still not knowing how to build a new back deck on my house. Thankfully, I have just enough common sense to not spend money loading up my garage with a bunch of stuff that I don’t really understand.

IT teams need to apply the same common sense when determining the right tools and technologies for their CI/CD pipelines, or they risk ending up with what Nate Berent-Spillson, senior director of delivery at Nexient, calls “tool salad.” (Mmm, sounds delicious.)

“I’ve seen companies go on a buying spree, picking up this tool, that platform, and that system over there, yet in the end, they weren’t equipped to build an iOS app,” Berent-Spillson says. “The unspoken idea was that if they bought enough tools, the capabilities they wanted would have to be in there somewhere.”

Choosing the right platforms and tools is indeed an important part of your CI/CD plan, but your needs should dictate the tools, not vice versa.

“Instead of thinking about what tools you need, think first about the capabilities you want, like ‘build pipeline for iOS,’ ‘build pipeline for Android,’ ‘mobile app distribution for both platforms,’ or ‘signing certificate security and management,’” Berent-Spillson advises. “That way, you’re focusing on how to move value through the system. The choice of tools will follow from that.”

2. Don’t mess up on metrics and feedback

Continuous measurement is an important success factor for CI/CD, but it comes with a downside: Picking the wrong things to measure.

“One of the biggest pitfalls to watch out for is picking the wrong metrics to test,” Scharmen at Optimizely says. “Businesses can easily guide their products down the wrong direction if they choose the wrong metrics to track and measure.”

Because CI/CD and DevOps often go hand-in-hand, there can be some overlap in the metrics you use to evaluate their impacts. The key principle here: Track what actually matters to your organization. As Gordon Haff, technology evangelist, Red Hat, wrote previously about DevOps metrics: “A metric is properly thought of as a key performance indicator for data – a measurement that’s important to you in some fundamental way.”

The same idea applies to your CI/CD pipeline: Make sure you know what’s important, not just to you but to the organization.

“Different members of an IT organization or team have different priorities, so it’s important to assess which data everyone wants and needs from the start,” Scharmen says.

Scharmen notes another related pitfall: Getting duped by data via misinterpreting it, confirmation bias, or other reasons. This applies not only to your ongoing measurement but to testing itself in your pipeline.

“Misinterpreting a test can be worse than not running one at all and can quickly negate the value of an experimentation by injecting uncertainty and fear into a process that’s meant to provide clarity and confidence,” Scharmen says.

Finally, don’t forget about your actual production application or service. CI/CD doesn’t actually come with a defect-free guarantee as code moves into production. You still need a feedback loop there.

“Avoid the pitfall of having automated the delivery of software from source code to end user but not automating the collection of live, passive feedback, either from end users or automated tests,” says Maxwell Bloch, consultant at Applied Information Sciences (AIS). “For example, instrument your application to provide telemetry and error occurrences. Many bugs will be detected earlier in the CI/CD process, but some bugs will only occur with real usage.”

3. Don’t give people a way to bypass the CI/CD pipeline

Don’t enable team members to bypass the pipeline other than under the most extraordinary of circumstances. This can be particularly important if you’re dealing with skepticism or cultural stasis in the earlier stages of your shift to CI/CD.

“If your CI/CD platform is not the only way, excluding an emergency break-glass method, to deploy code to your production environment, it will become tempting for teams to work around it when your testing [finds] code issues that are not easily solvable,” says Jerry Gamblin, principal security engineer at Kenna Security.

A promise of CI/CD is that it will enable application teams to move faster than before, but there may still be real reasons to slow down, and that can cause some frustration or feelings of failure. (This is another reason why cultural health is as important as technical decisions and architecture: A healthy culture can handle the speed bumps.)

You might automate your pipeline iteratively or in small chunks, and that’s fine. Similarly, you might build a CI/CD pipeline for a specific application team – also fine. But no matter your approach, don’t effectively give people the chance to opt out of your CI/CD pipeline if they decide it doesn’t suit them for some reason.

4. Don’t treat automation as an infallible hero

Automation is intrinsic to CI/CD; a CI/CD pipeline laden with cumbersome manual processes isn’t much of a CI/CD pipeline.

“CI/CD is all about automation,” says Meera Rao, senior principal consultant at Synopsys Software Integrity Group.

That doesn’t mean “automate all the things” is literally the goal, though. Rao notes that while automated testing is an enormous part of CI/CD, it doesn’t actually eliminate the need for manual testing or other forms of human intervention.

“No single automated testing tool can find all the defects in an application. For example, static analysis tools cannot understand business logic,” Rao says. “Likewise, no automated security tool is effective in discovering architecture and design flaws in deployed applications. The only effective way for an organization to discover these types of flaws is to perform a manual architecture risk analysis.”

It’s a later-stage byproduct of Berent-Spillson’s tool salad: Assuming your technology will take care of everything almost certainly means there will be issues in your pipeline and, as a result, in your production code.

“On top of automation and continuous testing, you must make sure to have intelligence built within your CI/CD or DevOps pipeline to know when human intervention is required,” Rao says. “Recognize that tools need hand-holding.”

5. Don’t shortchange your CI environment

A truly robust CI/CD pipeline is the sum of its parts; if you skimp on the integration piece, that can have compounding effects later,  especially when code deploys to production.

“Ideally, the continuous integration environment for a software product mimics the production environment as closely as possible,” Bloch says. “Continuous integration will not prevent end users from encountering bugs if the software was not able to be tested under realistic conditions.”

Bloch shares a handful of examples where discrepancies might occur between integration and production environments, increasing the likelihood of missed issues.

• The allocation of process resources such as CPU and RAM.
• The number of distributed servers running a web application.
• The scale of web traffic encountered during testing.
• When applied to mobile apps, Bloch says making your CI environment as production-like as possible “means that the most accurate environment for testing and continuous feedback is a physical device and not an emulator.”

6. Don’t silo development and testing

Just as DevOps success required the breakdown of traditional walls between development and operations, CI/CD success depends upon bringing dev and testing into closer alignment.

“Watch out for persisting the separation between development and testing, even after automating the integration of code and the delivery of the latest version,” Bloch says. “If development reaches a checkpoint where a CI build occurs, the developers are not separate from the next steps in the process. If bugs are identified, developers must respond quickly and provide the fix into the CI process, or else the build may not be considered releasable.”

You don’t need to start doing trust falls with your developers and testing pros; rather, you need to start eliminating conflicting goals and incentives.

“The ability to deliver continuously is jeopardized if development and testing activities do not share priorities,” Bloch says.

Why Custom Software Development Needs a New Approach

Market demands shift fast. Businesses commissioning custom software no longer have the luxury of locking down requirements for months, handing them to a development team, and waiting for a big-bang release. Users expect frequent updates, new features, and near-zero downtime. That pressure exposes a structural problem that has plagued the industry for decades: development teams and operations teams working in silos, each optimising for different — and often conflicting — goals.

DevOps directly addresses that structural problem. For organisations building custom software, adopting DevOps principles is no longer optional; it is quickly becoming the baseline expectation from clients and end users alike.

What Is DevOps?

DevOps is a portmanteau of Development and Operations. At its core it is a cultural and technical movement that breaks down the wall between the teams who write software and the teams who run it in production. Rather than throwing code over a metaphorical fence and hoping operations can keep it stable, DevOps encourages shared ownership of the entire software lifecycle — from writing the first line of code to monitoring the service in production.

Key pillars of a DevOps practice include:

• Collaboration and shared responsibility — developers, QA engineers, security specialists, and operations staff work toward the same release goals.
• Automation — repetitive tasks such as building, testing, and deploying software are automated so that human effort is focused on higher-value work.
• Continuous Integration and Continuous Delivery (CI/CD) — code changes are integrated and verified frequently, and deployable artefacts are always ready to ship.
• Monitoring and feedback loops — production metrics flow back to the development team so problems are caught and resolved quickly.

How DevOps Applies to Custom Software Development

Traditional waterfall or heavyweight process models were designed for stable, well-defined requirements. Custom software projects rarely enjoy that luxury. Requirements evolve as stakeholders learn more about the problem, and the software must keep pace. DevOps makes that evolution manageable in several concrete ways.

Faster, More Reliable Releases

With a CI/CD pipeline in place, every code commit triggers an automated build and test run. Defects are caught at the point of introduction rather than weeks later during a manual testing phase. The result is a deployable artefact that the team can release at any point with confidence, shrinking the gap between when a feature is built and when it reaches users.

Reduced Communication Silos

In a custom software engagement, communication failures between client-side stakeholders, developers, QA, and operations are a leading cause of project overruns. DevOps encourages shared tooling — issue trackers, chat platforms, dashboards — and shared rituals such as joint retrospectives. When everyone can see the same deployment pipeline, conversations shift from blame to collaborative problem-solving.

Automated Quality Gates

Custom software delivered without adequate testing is a liability, not an asset. DevOps promotes embedding quality checks — unit tests, integration tests, static analysis, security scanning — directly into the delivery pipeline. A release cannot proceed until it passes every gate. This gives clients confidence that what they receive has been verified systematically, not just spot-checked.

Cost Efficiency Through Automation

Manual provisioning, manual deployments, and manual rollback procedures are expensive. Infrastructure-as-Code tools allow environments to be provisioned consistently and repeatably. Deployment automation eliminates error-prone manual steps. Over the lifetime of a custom software product, these savings are significant and can be passed on to the client or reinvested in feature development.

The Importance of DevOps for Custom Software Teams

Adopting DevOps is not just a competitive advantage — it increasingly determines whether a custom software business can retain clients at all. Consider the following business outcomes that a mature DevOps practice enables:

• Higher deployment frequency — teams can push small, low-risk changes regularly instead of infrequent, high-risk big-bang releases.
• Lower change failure rate — automated testing and staged rollout strategies such as blue-green deployments or canary releases catch problems before they affect all users.
• Faster mean time to recovery (MTTR) — when incidents do occur, automated rollback and clear observability mean problems are resolved in minutes rather than hours.
• Better stakeholder alignment — shared visibility into the pipeline means clients and internal teams have a common understanding of project status.

From the end user’s perspective, the benefit is straightforward: software that is more stable, updated more frequently, and responsive to feedback. Features they request actually reach them in a reasonable timeframe rather than waiting for the next annual release cycle.

Core Goals of DevOps in a Custom Software Context

Organisations that adopt DevOps for custom software development typically pursue the following goals:

1. Identify bottlenecks early. DevOps practices surface pain points in the development-to-operations handoff — slow builds, flaky tests, manual approvals — so they can be systematically eliminated.
2. Enable faster innovation with lower risk. Smaller, more frequent releases mean each change carries less risk. Teams can experiment, gather feedback, and iterate without fear of destabilising the whole product.
3. Align priorities across teams. Shared goals and shared metrics prevent the classic situation where development optimises for feature velocity while operations optimises for stability, at the expense of each other.
4. Improve deployment frequency and reduce failure rates. Automation and rigorous testing pipelines directly improve both metrics, which are widely accepted as indicators of software delivery performance.
5. Enhance security, predictability, and maintainability. Embedding security scanning (DevSecOps), enforcing infrastructure standards through code, and maintaining comprehensive observability all reduce long-term operational risk.

Choosing a Custom Software Partner with DevOps Maturity

If your organisation is procuring custom software development services, DevOps maturity should be a key evaluation criterion. When assessing vendors, look for evidence of:

• A documented CI/CD pipeline used on real client projects.
• Infrastructure-as-Code practices for repeatable environment management.
• Automated test coverage as a standard deliverable, not an afterthought.
• Defined incident response and rollback procedures.
• Monitoring and alerting set up as part of the delivery, not bolted on post-launch.

Conclusion

DevOps is not a product you buy or a title you assign. It is a sustained cultural and technical practice that fundamentally changes how development and operations teams collaborate. For custom software development — where requirements evolve, timelines are tight, and clients expect high quality — DevOps provides the framework to deliver reliably, iterate quickly, and reduce the risks that sink traditional projects.

Organisations that embed DevOps principles from the start of a custom software engagement are better positioned to meet client expectations, outpace competitors, and build software that remains maintainable long after the initial release.

Introduction

Since Puppet published its first State of DevOps Report in 2012, the annual survey has accumulated nearly 30,000 responses from practitioners around the world. That body of data makes it possible to look beyond global averages and ask more granular questions: Do DevOps adoption patterns differ by geography? Does industry vertical influence IT performance? And where does automation actually begin?

The State of DevOps Market Segmentation Report — Puppet’s first attempt at slicing the data by peer group — was designed to help organisations benchmark themselves against companies of similar size, region, and industry rather than against an undifferentiated global average.

Automation as the Primary DevOps On-Ramp

One of the report’s clearest findings is that most organisations begin their DevOps journey by targeting their most acute pain points — and that automation is the most common first step. Rather than starting with lean process design or metrics visualisation, teams typically reach for automation tools first.

The three most common starting points are:

• Continuous integration (CI) — automating the build and test cycle triggered by code commits.
• Deployment automation — reducing the manual steps required to move a build from a passing test suite into a target environment.
• Infrastructure automation — codifying server and environment configuration so it can be provisioned repeatably and at scale.

The motivation is straightforward: every manual handoff in a release pipeline is a potential delay, a source of inconsistency, and a drain on engineering time. Automation removes those friction points, shortens lead times, and frees teams to focus on building features rather than shepherding releases.

However, the data also shows that automation is far less pervasive than industry conversation might suggest. Despite widespread discussion of CI/CD and infrastructure-as-code, most companies report significant amounts of manual work remaining across their software delivery lifecycle. Automation is relieving the sharpest pain points, but few organisations have achieved end-to-end automated pipelines.

Measuring IT Performance: Throughput and Stability

To compare DevOps maturity across segments, the 2017 State of DevOps survey measured IT performance along two dimensions:

• Throughput — how frequently a team commits code and how quickly that code moves from commit to production deployment.
• Stability — how fast a system recovers from unplanned downtime (mean time to recovery, or MTTR) and the ratio of successful changes to failed ones (change failure rate).

High performers excel on both dimensions simultaneously. According to the report’s figures, high-performing organisations deploy code 46 times more frequently than low performers and achieve a 96 times faster mean time to recovery. They also have shorter lead times from commit to deployment and lower change failure rates — demonstrating that speed and stability are complementary outcomes of mature DevOps practice, not trade-offs.

Regional Performance Differences

Segmenting by geography reveals meaningful variation in the distribution of high, medium, and low performers:

• India, Japan, and Northern Asia had the highest proportion of high-performance IT organisations at 24%.
• Mexico, Central America, and South America followed with 20% of organisations rated as high performers.
• Central and Eastern Europe had the highest proportion of medium performers at 53%.
• The United States and Canada had the highest proportion of low performers at 45%.

A notable finding across all regions: more than half of surveyed organisations met at least a medium performance threshold. The widespread narrative that DevOps is still a niche practice does not fully hold up — adoption is broad, even if high performance remains concentrated.

Industry Performance Differences

When the data is broken down by industry vertical, the picture at the top is surprisingly uniform: most industries had roughly the same small share of high performers, clustered around 15%. The more significant variation appears in the low-performance tier.

Industries with the lowest proportion of low performers (i.e., doing relatively well):

• Media and entertainment — only 23% of organisations rated as low performers, the best result of any industry.
• Retail — 31% low performers.

Industries with the highest proportion of low performers (i.e., lagging behind):

• Financial services — 54% of organisations rated as low performers.
• Insurance and industrial/manufacturing — each at 53%.

Heavily regulated industries like financial services and insurance face additional constraints — compliance requirements, audit trails, and risk-averse change management cultures — that can slow DevOps adoption even when the technical appetite is present.

The Automation Ceiling: Change Approval Remains Manual

Even among organisations actively investing in DevOps, automation does not penetrate every stage of the software delivery pipeline equally. The data shows a clear pattern across industries:

• Configuration management and software deployment are the areas most commonly automated.
• Testing retains more manual steps than deployment, with many organisations yet to achieve comprehensive automated test coverage.
• Change approval is the stage most resistant to automation. Even in the media, entertainment, and technology sectors — the industries with the lowest rates of manual work elsewhere — more than half of organisations still rely on manual change approval processes.

This is a meaningful insight for teams planning their automation roadmaps. Organisations are willing to automate execution but remain reluctant to remove human judgement from the decision to release. Whether this reflects genuine risk management, organisational culture, regulatory obligation, or simply inertia will vary by company — but the pattern is consistent across sectors and company sizes.

The practical takeaway: if your organisation is automating builds and deployments but still routing every release through a manual change advisory board (CAB) or approval ticket, you are in good company. The data suggests that even high-performing organisations blend automated execution with human oversight at the approval gate.

Key Takeaways for DevOps Practitioners

• Start with pain points. Automation of your most manual, error-prone processes is a validated entry point for DevOps adoption — not just a theoretical best practice.
• Measure throughput and stability together. Teams that optimise only for speed risk instability. High performers achieve both.
• Benchmark against your peer group. Global averages can be misleading. Regional and industry context matters when assessing where your organisation sits on the performance spectrum.
• Expect automation gaps in testing and change approval. These are industry-wide challenges, not just yours. Prioritise incremental progress rather than waiting for a fully automated pipeline before starting.
• Regulated industries face additional headwinds. If you work in financial services, insurance, or manufacturing, the data confirms that your environment is more challenging — but it also shows room for significant improvement.

For teams looking to improve, the segmentation data offers a useful mirror: knowing where your region and industry sit on the performance curve is the first step toward identifying which practices to prioritise next.

In the ever-changing world of technology, the need to be agile is crucial. Businesses are innovating at a fast pace to keep up with the demands of their consumers. In times of such rapid innovation, the need to have successful and speedy software development is of primary importance. And here’s where DevOps comes into the picture.

DevOps brings together software development and software operation for faster processes; it prioritises the organizational changes required for the same.

Bringing together the best of the names in DevOps from across the world was the DevOps India Summit 2018 – India’s biggest DevOps conference. The conference set the tone for the future of DevOps in India. The summit was held on September 1, 2018 at the Marriott Hotel, Whitefield, Bengaluru and saw participation from around 500 professionals including corporate leaders from across the country.

Setting the Stage For the Future

With DevOps, the idea is to bring in the future of automation and artificial intelligence for better work processes and organizational changes. The summit too worked on the same with experts sharing their valuable insights on all phases of IT transformation. The main objective of the event was to create a platform where people can interact and learn from each other and thrive within today’s software-driven economy.

Experts gave a sneak peek into DevOps adoption in India and the increase in the possibility of success of those initiatives and technical practices which will further help organizations attain the highest levels of performance.

The world class summit was organized by Xellentro in partnership with DevOps Institute, Crevise Technology, Confinity Consulting, GitLab, Datamato, Sumologic, Zoomcar, MongoDBand PEOPLECERT. Participants of the event got an opportunity to connect with the industry pioneers and learn more about the emerging DevOps practices which they can apply in their own organization.

Mukta Aphale, Founder & CEO at Crevise Technologies explained that the need of DevOps is to change the way software is built and delivered. Aphale added that today a considerable amount of automation is done to achieve certain goals, but this will go to an unprecedented level in the future with a lot of AI in DevOps. There is a need of doing more automation since the future of automation will invite AI, machine learning, robotic process automation. “Say about in 5 years from now, imagine a world where you may not need a Devops engineer to build automation, as the automation will be self-learning. From DecSecOps, RPA, Serverless and Microservices in the near future we will unfold to rock solid AI-Ops.So clearly, there is a lot of thing which can be done in DevOps space through Artificial Intelligence,” said Aphale.

Insightful Sessions for All

The Pre-event also witnessed technical session by GitLab Team concluding with a G2G3DevOps Simulation by Niladri Choudhuri, Xellentro whereas the main event was studded with keynote speeches from eminent speakers, Panel Discussions, Lightning Talks and Table Talk sessions.

The summit saw experts from across the world share their knowledge, talking about the importance of proper implementation of DevOps. One of them was Mark Hornbeek who delivered an impactful session on “How to Architect Continuous Delivery”.  He said that the Indian IT community has really embraced DevOps and the IT teams in the country are very competitive. He added that this in itself is a positive indication to further the DevOps skills in India and instead of outsourcing in parts, it is very important to outsource the entire function to see real efficiency of DevOps and hence the outlook needs to be opiniated in terms of taking a complete project as compared to working on small segments. “It is a great platform for people to connect and meet people who are willing to learn and ask many important relevant questions. In the near future, Devops will go through transformation in terms of patterns of practice which will be recognised as high performance that has transformed business,” he said.

The event made way for people to understand the importance of DevOps  and also interact with the biggest names from across the industry. Speaking at the event, John Willis – President, DevOps and Digital Practices, SJ Technologies said, “It was a great feeling to attend this summit as we get to meet new people who have been in this industry for a while. I have come across people who are smart, aggressive learners and are eager to know more,”

It became a platform for people to come together and work as a team to promote the real essence of DevOps. Niladri Choudhuri, who conceptualised the event said, “This is the first ever DevOps event in India in such large scale with prime focus on the core content and quality of speakers who bring value to organisation. This is a start to more such future initiatives and I thank everyone for their support.”