Despite being deemed as a typical tech buzzword, “DevOps” – the process of combining software development and information technology operations to shorten development lifecycle – brings clear benefits. Faster lead times from commitment to deployment, greater customer responsiveness and the ability to scale and respond to market changes are just a few advantages businesses can expect by embracing DevOps transformation.

However, whether an organisation is contemplating a minor improvement on its current software delivery pipeline or a major transformation, the process of DevOps is often overlooked. So, why isn’t every business using DevOps practices? Gordon Cullum, chief technology officer of digital services firm Mastek, reflects on the matter below.

In reality, it is rare, these days, for an organisation not to have adopted any of the technologies and practices that have become part of DevOps. But often a company can be unsure of where to start, how to continue, and equally afraid of failure at any point along the journey. This article summarises the typical stages that, in my experience, most organisations pass through as they adopt DevOps strategies in the attempt to improve their technology and processes. Every business will have unique needs and challenges, but there are recognisable stages common to most.

Fail to prepare – prepare to fail
Before setting out on a DevOps transformation an organisation needs to be prepared. One of the most important elements of this stage is ensuring that the goals of the transformation have been communicated across the organisation, that there is buy-in, that management will support staff in the challenges ahead and that this is transparent to staff.

Scaling up effectively by embracing DevOps transformation

A successful DevOps transformation relies on a business’s most valuable resource: its workforce. Organisational and technical change will often put significant demands on them and so having their confidence that the transformation will succeed and their willingness to change old processes and attitudes, is vital.

Before setting out on a transformation path, it is therefore essential that a business clearly communicates the goals of the process with its staff. Essentially, the primary DevOps goal is to optimise the flow of value from idea to end user, and with this, comes a cultural change that must take place for a company to be successful. Whilst culture is a big focus, the DevOps goal is to make the delivery of value more efficient and effective whether that’s reliability, predictability or maximising skill re-use. Getting expert support, to not only answer concerns but also run workshops to increase understanding of DevOps practice can also be pivotal to success.

Visibility will be key
Before a business can start the process of change, it is essential to have a clear and comprehensive picture of existing technologies and an assessment of their complexity. This list can then be used to identify ways to remove unnecessary complication, for example by eliminating duplication where different tools or processes do the same thing, getting rid of in-house products that are no longer fit for purpose and moving to standard technologies, tool sets and configuration methods across the organisation.

It’s important to help create clear schedules for the review and consolidation of technologies and let teams take the initiative in choosing which technologies to keep and how to manage the migration with agreed priorities and realistic deadlines.

At this part of the process it’s also essential to turn migration goals into milestones and celebrate their success. Early wins can deliver measurable cost and time savings to reassure senior stakeholders and also provide a less-pressured stage to build collaborative and constructive processes. Use this as opportunity to boost team morale and secure longer term buy-in before the more ambitious transformation begins.

Streamlining DevOps processes
The success of the consolidation and standardisation process can typically cause a range of problems that are often a surprise to the organisation. For instance, increased efficiency can place unprecedented strain on parts of the business, its processes, the application architecture and the infrastructure. Meanwhile, removing known bottlenecks can reveal previously unknown inefficiencies, while if improvement is uneven (as is likely), morale and collaboration between teams may fluctuate as the finger of blame is pointed.

These issues can be addressed through the improvement of DevOps processes and culture. Many staff, at this stage, are likely to see technical remedies as far more important than culture improvements, but it is vital to show them that cultural change enables technical improvement. The business must therefore reduce bureaucracy, give teams autonomy to decide on solutions and encourage a blame-free culture. Ultimately, cultural change has to happen from the top down.

“Managing a DevOps culture is not the same as creating one; processes must be put in place that boost new attitudes and behaviours.”
– Gordon Cullum, CTO of Mastek

Automating infrastructure
As efficiency and productivity continue to increase, there will be increasing strain on the infrastructure. This is not least due to fact that the application of development good practice to infrastructure code is a relatively young and immature discipline. It is also usually the trickiest to address and the hardest to make scalable. Even moving to the cloud does little to help if infrastructure provisioning is not sufficiently automated.

A high level of automation must be developed and applied to infrastructure configuration and provisioning. The infrastructure also needs pervasive monitoring and logging, with automated responses to alerts about significant state changes and good data analysis to reveal trends. Without this, substantial time and money can be lost through inefficiency and inappropriate scaling.

Upskilling the workforce
A business should put its regular automation and monitoring to the test by providing teams with self-service capabilities when it feels its challenges have been solved. Team productivity will increase with self-service infrastructure automation and in time free up operations staff, so that they can focus more time on developing automation solutions. Businesses need to bear in mind though that to achieve this level of automation, staff will need to be upskilled or people with relevant skills recruited. However, it’s important to note that the upskilling of staff isn’t just the upskilling of technologies (AWS, Azure), it’s also about security, financial accountability and technological and architectural adherence.

If at this stage the disciplines of immutable infrastructure haven’t been adopted, now is the time to do so. Re-evaluate infrastructure automation and configuration patterns, looking for things that are no longer appropriate or necessary on immutable infrastructure, and enforce a discipline of no manual intervention for maintenance of servers/virtual machines/network infrastructure. Automated testing and monitoring should also be reviewed to ensure complete confidence in both.

The next step for DevOps transformation…
When embracing DevOps transformation, as with any technological advancement, new challenges and opportunities will be presented. Market growth and innovation will eventually generate more technical change, but the cultural changes should be long lasting and a permanent gain, however, this can only be accomplished if they are preserved. Managing a DevOps culture is not the same as creating one; processes must be put in place that boost new attitudes and behaviours.

A business will continue to reap the rewards of DevOps transformation by demonstrating to staff that the sustained duration of change will result in more space to think and use their initiative. With people being at the heart of any successful business, having employees onboard will be vital when scaling up effectively.

What Is Container Orchestration?

Container orchestration refers to the automated management of containerized workloads and services. It covers scheduling, scaling, networking, load balancing, health monitoring, and rolling updates across clusters of host machines. Kubernetes is currently the dominant open-source platform in this space, but competing and complementary platforms include Amazon Elastic Kubernetes Service (EKS), Amazon ECS, Google Kubernetes Engine (GKE), Azure Kubernetes Service (AKS), Docker Swarm, and HashiCorp Nomad, among others.

Orchestration has moved from an advanced operational concern to a mainstream infrastructure requirement as organizations adopt microservices architectures and need to manage hundreds or thousands of containers in production.

Why the Container Orchestration Market Matters to DevOps Teams

Understanding the competitive landscape and adoption trajectory of container orchestration platforms helps engineering and platform teams make better tooling decisions. Market research in this space typically analyzes:

• Vendor ecosystem health — which platforms are receiving sustained investment and community contributions
• Enterprise adoption rates — how quickly organizations are moving workloads to orchestrated container environments
• Regional adoption differences — adoption patterns vary across North America, Europe, Asia-Pacific, and the Middle East and Africa (MEA)
• Segment growth by use case — differences in adoption between industries such as financial services, healthcare, retail, and telecommunications

Key Players in the Container Orchestration Market

The container orchestration market is dominated by major cloud providers and enterprise software vendors. Commonly cited participants in market research include:

• Amazon Web Services (AWS) — offers ECS (Elastic Container Service) and EKS (Elastic Kubernetes Service), with deep integration across its cloud platform
• Google Cloud — originated Kubernetes internally and offers GKE as a managed service
• Microsoft Azure — provides AKS with tight integration into its enterprise identity and DevOps tooling
• Red Hat — offers OpenShift, an enterprise Kubernetes distribution with additional developer and security tooling
• Docker — the original container runtime company; Docker Swarm remains in use, though Kubernetes has largely displaced it for large-scale deployments
• VMware (Tanzu) — provides Kubernetes-based platforms targeting enterprise vSphere users
• Rancher Labs (now part of SUSE) — offers multi-cluster Kubernetes management

Market research reports typically segment vendors by revenue, product offerings, geographic presence, and strategic partnerships.

Market Segmentation: How Analysts Break Down the Space

Container orchestration market reports generally segment the market along three axes:

By Type

• Platform-as-a-Service (PaaS) orchestration tools
• On-premises orchestration software
• Managed cloud Kubernetes services

By Application / End-User Industry

• Banking, Financial Services, and Insurance (BFSI)
• Healthcare and life sciences
• Retail and e-commerce
• Telecommunications and IT
• Government and defense

By Region

• North America
• Europe
• Asia-Pacific
• Latin America, Middle East, and Africa (LAMEA / MEA)

Key Market Drivers

Several structural forces are driving growth in the container orchestration market:

• Microservices adoption — breaking monolithic applications into independently deployable services creates a direct need for orchestration to manage service lifecycle and communication
• Cloud-native development mandates — enterprise digital transformation programs increasingly specify cloud-native architectures, making Kubernetes a default infrastructure requirement
• DevOps and CI/CD pipeline integration — container orchestration platforms integrate with CI/CD tools (Jenkins, GitLab CI, Argo CD, Tekton) to enable automated deployment pipelines
• Multi-cloud and hybrid cloud strategies — organizations using multiple cloud providers rely on Kubernetes as a common abstraction layer
• Operational efficiency — orchestration reduces manual intervention in scaling, failover, and resource allocation, directly lowering operational overhead

Market Limitations and Challenges

Despite strong growth, the container orchestration market faces real adoption barriers that DevOps practitioners should be aware of:

• Complexity of Kubernetes — Kubernetes has a steep learning curve. Many organizations underestimate the operational expertise required to run production clusters safely
• Security configuration challenges — misconfigured RBAC policies, exposed API servers, and insecure container images remain common sources of incidents
• Skill shortages — demand for engineers with Kubernetes expertise outpaces supply in most markets
• Vendor lock-in concerns — managed Kubernetes services from cloud providers often include proprietary extensions that complicate portability
• Cost management — without proper resource requests, limits, and autoscaling configuration, container clusters can generate unexpectedly high cloud spend

How Market Research Reports Are Structured

Third-party market research reports on container orchestration typically follow a standard structure. Understanding this structure helps DevOps leaders extract useful information when evaluating such reports for procurement or strategic planning purposes:

• Executive summary — high-level findings and market size estimates
• Market landscape — competitive positioning of key vendors
• Trend analysis — technology and adoption trends driving the market
• Industry chain analysis — upstream and downstream relationships (cloud providers, ISVs, system integrators, end users)
• Regional breakdowns — historical adoption data and forecasts by geography
• Vendor profiles — revenue, product portfolios, partnerships, and strategic direction for major players
• SWOT analysis — strengths, weaknesses, opportunities, and threats at the market level
• Forecast tables — projected market value and volume by segment and region over a multi-year horizon

What DevOps Engineers Should Take Away

Market research reports are primarily useful to platform architects, CTOs, and vendor evaluation committees rather than individual contributors. However, the broader market signals are relevant to practitioners:

• Kubernetes has consolidated as the de facto standard for container orchestration. Investing in Kubernetes expertise has a high return relative to platform-specific alternatives
• Managed services (EKS, GKE, AKS) continue to absorb complexity that previously required dedicated SRE teams, making orchestration accessible to smaller engineering organizations
• The competitive pressure between major cloud providers continues to produce rapid feature development — following release notes for your chosen managed service is worthwhile
• Security and cost optimization tooling (Falco, Kyverno, Kubecost, OpenCost) are growing sub-segments of the ecosystem worth evaluating alongside the core orchestration platform

When evaluating commercial market research reports in this space, verify the methodology (primary vs. secondary research, sample sizes, data collection dates) before treating specific figures as authoritative inputs to business cases.

In today’s digital era, mastering the customer experience through a continuous delivery of applications is a must. Hence, more and more organisations are focusing on adopting DevOps principles. Many Australian companies – such as Commonwealth Bank and AMP – have already embraced a DevOps model, and we anticipate many more organisations will join them as DevOps is likely to become mainstream within the next few years.

In fact, a recent survey of almost 2,000 senior managers at large organisations revealed that more than 80 per cent of Australian respondents claimed the rise of DevOps was a major factor driving the move to a cloud-first approach.

However, the excitement may not be shared by all — 87 per cent of attendees surveyed during Gartner conferences between 2015 and 2016 admitted that DevOps had not delivered on their expectations. In addition, the most recent Hype Cycle showed it edging towards the trough of disappointment.

The early stages of DevOps

The stats above might confuse teams looking to adopt a DevOps model comparing this sentiment to the enthusiasm demonstrated by so many businesses. But the reality is adopting a DevOps approach comes with significant effort, especially because the entire business needs to go through several cultural changes in order to make adoption fully successful.

In its early stages, DevOps generally consist of a merged development and operations team working separately from the rest of the business. However, in order to achieve true success, development, operations and the wider business should all work in collaboration and towards the same goals. Leaving the teams in silos is likely to lead to modest improvements or results lower than the business expects. Rather than seeing DevOps as a simple process of placing these two teams together in yet another silo, DevOps should be considered an ongoing process that sees a radical change in culture, creating more integration.

Creating a cultural shift

Organisations are increasingly seeking to restructure their IT delivery models away from the short-term, cost-focused, project-based models to full lifecycle, innovation-focused, product-centric models based on cross-functional DevOps-enabled teams. DevOps is considered a major driver of digital transformation, as it enables organisations to develop better applications more frequently, integrate teams working towards the same goals, avoid one team blaming another when things go wrong, share learnings, etc.

However, success is only possible with cultural change, and this is typically the number one barrier. What’s needed is a cultural shift from command and control management to true leadership, surrendering centralised control to autonomous teams, as well as learning a raft of new technical skills in order to stay relevant in this new world.

Companies that adopt a DevOps culture will foresee agile teams that collaborate more seamlessly and are able to maximise results working as a one-team. This concept should be applied gradually and must have buy-in from the top. Executive buy-in and the ability to enforce change from the top of the organisation can go a long way toward greasing the skids to make this successful.

It’s also essential to hire effective and experienced IT leaders. These leaders are charged with empowering practitioners while acting as a go between with senior management to evangelise success while making sure the work being done aligns with business goals. Without leadership, it can be easy for roles to become undefined and different interpretations to take hold. It may be the case that specific DevOps roles are created, emphasising the importance of skills that can be applied across the required tools, databases and other areas.

Role-setting

Developers and operations team should have a clear vision of their new roles and desired behaviours. Previously, developers could focus almost exclusively on writing code. Now they’re expected to dedicate more time to testing, deploying and understanding the impact on the rest of the team.

On the other hand, operations should learn new languages, tools and architectures such as containers and micro-services which would allow them to play a bigger role in the development process. Training and restructuring may demand an adjustment time, but teams should remain aware of the wider vision and benefits in the long term.

Data-driven DevOps

You can’t improve what you can’t measure so it is crucial to set appropriate measurements. Having clear metrics will allow teams to spot the root cause of problems and avoid the risk of blaming the other side.

It goes without saying that organisations are increasingly data centric in nearly all respects: from evaluating where to invest to win new customers, to “Smart” Algorithmic IT Operations (AIOps) and data-driven development. DevOps should follow this. Having shared KPIs will enable benchmarking with peers and enhance a culture of collaboration.

Some of the most important points to monitor include frequency of deployment, to assess the rate at which new code is released, and mean time to resolution, to ensure issues are being fixed quickly, and the amount of time taken from development to production.

Furthermore, metrics on application performance and a record of the number of failed deployments give an essential overview of the quality of the code being released. Insights from the application performance perspective will remain critical in understanding the customer experience and the exact nature of each business transaction, not to mention that metrics will help demonstrate small improvements, reducing the chance of disappointment from those expecting results straight away.

Achievable success

Making DevOps a success is not as simple as buying the right tools. Building culture takes time, especially if you’re starting with a culture that is more attuned to waterfall release cycles. However, the critical importance of fast, high-quality releases means businesses will come under more pressure to make the switch to DevOps. Once they decide to jump on a rollout, businesses must be ready for a long journey that will run into obstacles along the way. Although it won’t happen overnight, organisations that commit the time and effort to making DevOps work will certainly reap the benefits. Key point is DevOps won’t disappoint when rolled out thoroughly.