Like so many other innovators across the globe, forward-thinking organisations in the Asia-Pacific region are reinventing themselves with a goal to fuel renewed digital business growth. As economic activities return to pre-COVID pandemic levels, these savvy leaders are building technology-enabled business models.

Cloud computing has emerged as the core foundation of this renewed business technology focus, leading to Asia-Pacific public cloud services spending growth of over 38 percent to $36.4 billion in 2020, according to the latest market study by International Data Corporation (IDC).

“Cloud services have addressed more than cost management challenges during the COVID-19 pandemic. Cloud services and technologies have been the basis for the rapid introduction of new digital services to support remote workers and online customers, and it’s been the speed of implementation and low up-front costs that have enabled that,” said Chris Morris, vice president at IDC.

Cloud computing market development
Cloud Infrastructure as a service (IaaS) has been the top contributor to the overall public cloud spend during 2020, making up around 48 percent of the overall cloud investment — and it is expected to remain the highest throughout the forecast period of 2021-2024.

IaaS spending across compute, storage, and networking will remain steady throughout the forecast with compute taking the major share of spending followed by storage. Software as a Service (SaaS) is positioned as the second largest in terms of spending on cloud computing with a share of around 40 percent, followed by Platform as a service (PaaS) with an 11 percent share in 2020. The majority share of SaaS spending is coming from enterprises spending on cloud-hosted applications. Software Applications and System Infrastructure Software (SIS) is also contributing to SaaS spending.

This is expected to further grow as enterprises leverage SaaS solutions that cover collaboration, productivity, and IT security to support ‘remote working’ and the ‘hybrid workforce’ phenomena. PaaS spending will be led by Data Management Software, which will record a five-year CAGR of 41.2 percent during 2019-2024.

IDC expects this trend to continue due to the focus on business scalability, increased performance, improved security, and optimising IT operations to create business resiliency and cap on-premises infrastructure costs. Moreover, cloud-based security benefits are driving enterprises in the region to migrate to public cloud service offerings with new enthusiasm.

Regarding industry growth projections, Professional Services (15 percent share), Banking and Discrete Manufacturing (around 10 percent share) are the top three industries accounting for one-third of the overall public cloud services spending throughout the forecast period of 2021-24.

However, Construction and Professional Services — due to increased focus on external-facing interactions and customer experience — will see the fastest growth in public cloud spending with a five-year CAGR of 39 percent and 35 percent respectively. Regarding commercial segment growth, very large businesses will account for 37.1 percent, medium-sized businesses will deliver around 30.2 percent, and large businesses with 20.8 percent are the three segments that accounted for the Asia-Pacific total 2020 public cloud spending.

Both small and medium-size businesses show the fastest growth during the forecast period of around 34 percent in cloud investment. These segments were the hardest hit organisations during the global pandemic, and have an immediate need for business continuity, resiliency, and eventually new digital growth.

Outlook for public cloud services adoption
From a geographical perspective, China was the largest market for public cloud services in 2020 with its $19.4 billion investment that accounted for about 53.4 percent of the Asia-Pacific total. The openness of enterprises to adopt cloud technology, supplemented by government initiatives and the presence of home-grown cloud service providers, is boosting the continued adoption and growth.

Australia ($5.2 billion) and India ($3.5 billion) will be in second and third place respectively in terms of cloud infrastructure and service spending in the region, driven by fast adoption across enterprises and the presence of global hyperscale public cloud providers.

That said, I anticipate that cloud computing trends in this region will be reflected in other regions as a post-pandemic economic recovery emerges, and the thriving organisations accelerate their digital transformation agenda. Therefore, forward-thinking CIOs and CTOs will have a unique opportunity to further influence digital business growth strategies.

New Delhi: The Atal Innovation Mission (AIM), NITI Aayog, and Amazon Web Services (AWS) today announced new initiatives to strengthen the innovation and entrepreneurship ecosystem in India, by empowering school students with cloud computing skills, and enabling entrepreneurs to build innovative education technology (EdTech) solutions on the cloud.

A Statement of Intent (SoI) was signed between NITI Aayog and Amazon Internet Services Private Limited (AISPL), which undertakes the resale and marketing of AWS Cloud services in India.

As per the SoI, AIM will leverage AWS Educate, Amazon’s global program that provides resources for students and educators to accelerate cloud-related learning. This program will introduce the fundamentals of cloud computing such as cloud storage, virtual compute power, web hosting, artificial intelligence (AI), machine learning (ML), and virtual reality (VR), to students at more than 7000 Atal Tinkering Labs (ATLs) in India. AWS will also conduct Faculty Development Programs (FDPs) for the personnel in-charge at the ATLs, and provide resources and tools at each ATL to expedite student learning, and enable them to create and build solutions on the cloud.

AIM will also adopt AWS EdStart, a virtual startup accelerator program that enables EdTech startups to develop innovative teaching and learning solutions on AWS. EdTech startup entrepreneurs and founders in more than 80 Atal Incubation Centers (AICs) and Atal Community Innovation Centers (ACICs), will be able to apply for AWS EdStart program benefits, such as AWS Promotional Credits, mentorship, and technical trainings, to help speed their growth.

Mission Director – Atal Innovation Mission, R. Ramanan said the collaboration with AWS will equip the talented youth of the country with digital and web-based tools that can enhance their creative and innovative capabilities, in turn helping the nation to grow manifold in its innovation and entrepreneurship network. “The education and tools will establish a strong foundation in cloud computing for students of ATLs across India, while the support of AWS EdStart for startups from AICs and ACICs will accelerate their productization and potential commercialization,” he said.

President, Public Sector – AISPL, AWS India and South Asia, Rahul Sharma asserted that India will need nine times as many digital skilled workers by 2026, according to the report Unlocking APAC’s Digital Potential: Changing Digital Skill Needs and Policy Approaches, prepared by strategy and economics consulting firm AlphaBeta, and commissioned by AWS. “AWS is committed to bridging the digital skills gap in cloud computing, and empowering entrepreneurs to build innovative products and services on the cloud. We are focused on helping customers deliver transformational change and experiential learning at scale. It is a privilege to team up with Atal Innovation Mission to foster ideation, curiosity, and innovation among India’s students and youth,” he added.

Other areas of collaboration between AIM and AWS include joint workshops, tech marathons, and national challenges to develop solutions on the cloud, while solving local community problems, or sustainable development goals (SDGs).

Open source has permanently altered how we work and conduct business. Linux, and thousands of other open source projects and open standards, now dominate the software landscape, supporting emerging technologies like artificial intelligence and edge computing. Without open source, the DevOps tooling ecosystem would lack Docker, Kubernetes, service mesh, popular databases, and many CI/CD tools used by DevOps teams daily.

Now, more than ever, companies are searching for ways to meet escalating user demands. The pandemic has amplified this urgency, accelerating existing digital transformation initiatives. Arguably, open source is the engine that now powers the digital innovation required to compete. Leveraging open source could also help check rising cloud costs. With proprietary solutions falling out of favor, many enterprise leaders are adopting open source alternatives for infrastructure modernization and application development.

Red Hat recently released its third annual State of Enterprise Open Source report. The report surveyed 1,250 IT leaders worldwide on their open source adoption and usage patterns. The findings validate what most of us already know — open source is now fundamental to most technology stacks. Without it, most development projects would fall flat in an instant.

Open Source Use Cases
Open source is at the heart of modern software development. According to the report, 90% of enterprise IT leaders are using open source. So, where is open source being applied? Well, 64% of enterprises use open source software for IT infrastructure modernization. The report surmised that this could be due to Linux and open source infrastructure replacing proprietary systems.

The report also found 54% of enterprises use open source for application development. This is no surprise, as engineers routinely adopt open source libraries and packages to construct B2B and user-facing experiences. In a digital-only environment, applications are the lifeblood for many businesses, and open source is critical scaffolding.

The third top use case for enterprise open source is digital transformation, at 53%. This figure has increased by 11 percentage points in the last two years alone. Open source will likely continue to replace non-digital or manual processes with software-based, automated processes.

In the enterprise, open source is used in networking, adopted by 54% of enterprises, databases, at 53% and security, at 52%. Other areas mentioned in the report include big data analytics and cloud management tools.

In recent years, multi-cloud has become a notable trend. The idea is that organizations will seek out multiple cloud vendors to support different use cases. The Red Hat report confirmed that hypothesis, finding that 69% of respondents prefer to use multiple vendors for their cloud. As hybrid, multi-cloud setups profligate, cloud expertise and smart multi-cloud economic practices continue to gain importance.

Containers and K8s
Open source components are the foundation for containers and container management utilities. As reliance on containers grows, so will the dependence on open source technology. The report found just under half of enterprises now use containers in production. An additional 37% also use containers for development-only purposes.

To orchestrate these containers, IT teams have coalesced around Kubernetes. Sixty-six percent of respondents view Kubernetes as very or extremely important. As Kubernetes becomes ubiquitous, growth in container usage is slated to continue — about one in three respondents reported their container usage will increase significantly in the next 12 months.

“Kubernetes has become the de facto standard for Linux container development,” said Michael Hinterland, team lead, ICS cloud & automation and ICS system & middleware, Porsche Informatik.

While Kubernetes is flourishing, there are certainly variances across industries. For example, 62% of financial services and telecommunications respondents adopted containers in production, while other sectors, such as health care and retail, saw a lower adoption of containers in production, at 47% and 50%, respectively. The highly-regulated financial services sector also scored high on Database DevOps, a separate report recently concluded.

Open Source Benefits and Barriers
There are numerous benefits to using enterprise open source software. For one, a commitment to open source brings transparency and collaboration improvements. Respondents also cited higher quality software, access to the latest innovations and improved security as being among the top benefits to adopting open source software.

But open source has its drawbacks, too; 42% of tech leaders reported a lack of support as a top hurdle to enterprise open source adoption. This checks out – community-driven projects don’t typically offer traditional support systems. Without accessible frameworks for learning, creating a Center of Excellence at scale becomes difficult.

Other top barriers to enterprise open source adoption include compatibility, code security and a lack of internal skills. Introducing open source within an enterprise means upskilling the workforce and encouraging secure-by-default settings to avoid costly misconfigurations. It could also mean working with trusted allies that further open source initiatives, the report recommended.

Open Source Fuels Emerging Tech
“Open source has solidified itself as an innovation engine for the software industry,” wrote Paul Cormier, president and CEO, Red Hat.

Indeed, open source is at the heart of most cutting-edge emerging technologies. For example, 55% of respondents report using enterprise open source in edge computing and internet of things (IoT) settings. Simultaneously, 48% of respondents use open source for artificial intelligence and machine learning (AI/ML). Amid open source projects like OpenAI and GPT–3, AI is eating the software world, Forbes reported.

Both categories are slated to increase by nearly 20 percentage points in the next two years, whereas the use of proprietary solutions for AI/ML will decrease. Open source will continue to affect buying decisions, as 83% of IT leaders are more likely to choose a vendor that has contributed to the open source community.

Within a COVID-19-influenced world, “the problems are too big for one person, one company or one organization to solve,” said Cormier. “But it’s in moments like this where open source truly shows its power.”

Digital.ai, the creator of the industry’s first intelligent Value Stream Platform, today announced that it has been granted four U.S. patents for advances in AI-powered analytics. The patents represent industry-leading innovations in applying artificial intelligence (AI), machine learning (ML), and automation techniques to address key challenges business and IT leaders face in driving higher levels of performance within their organizations. These four new patents bring the company’s total to more than 45 patents granted and further establish Digital.ai as the innovation leader in value stream management for the Global 5000.

Digital.ai’s four new patents pertain to the application of artificial intelligence and machine learning techniques to predict change and service disruption risk, in addition to automation innovations embedded in Digital.ai’s Value Stream Platform. According to Gartner’s recent Market Guide of DevOps Value Stream Management Platforms (VSMPs), “predictive analytics will be a key capability offered by DevOps VSMPs,” as “organizations are increasingly embracing the value of analytics to ensure successful deployments and demonstrate reduced production defects.”

“These new patents strengthen the AI-powered engine that serves as the foundation of the Digital.ai Value Stream Platform and give our customers peace of mind regarding the reliability of their application infrastructure,” said Gaurav Rewari, CTO and GM of VSM at Digital.ai. “Given today’s volatility, many enterprises have either slowed down or paused updates to their applications. However, their customers are relying on them to innovate more now than ever before. The capabilities represented by these patents enable IT organizations to continue to rapidly drive value for their customers while mitigating risk to the business.”

Digital.ai’s newest patents include:

Automated Health Assessment and Outage Prediction System (US Patent No. 10,613,525 ) Enables IT departments to increase change velocity while minimizing business service interruptions. The patented techniques use IT service management (ITSM) data in conjunction with application performance management (APM) and machine data to score changes, monitor the impact of changes post execution, and evaluate the health of a configuration item (CI). The technology is part of Digital.ai’s Change Risk Prediction and Major Incident Prediction solutions.

Warehouse-Based Reporting and Operational Reporting Integration (US Patent No. 10,614,091 ) Enables the unification of operational and warehouse reporting for analysis of real time content side by side with historical content, and turns data discrepancies between real-time and historical content into useful information for trend identification and proactive alerting.

Input Gathering System and Method for Defining, Refining, or Validating Star Schema for a Source Database (US Patent No. 10,599,678 ) Enables programmatic analysis of documentation, operational reporting setups, and query logs in conjunction with data profiling for identifying the inputs needed for creating and updating star schemas that are required for warehouse-based reporting. These automated techniques minimize the need for domain experts and enable Digital.ai’s analytic solutions to leverage a large number of data sources that are part of typical value stream chains in a cost-effective manner.

Model-Driven Reporting (US Patent No. 10,713,609 ) Enables programmatic generation of reports for multiple business intelligence (BI) tools using a declarative BI tool agnostic model for reporting which also enables lineage and change impact analysis all the way from data sources to the reporting layer.

The addition of these patents brings Digital.ai’s total to over 45 patents granted with several additional patents pending. The patented technologies are the foundation of Digital.ai’s Value Stream Platform and reflect the company’s expertise across agile, security, DevOps, AIOps and advanced analytics. The Digital.ai intelligent Value Stream Platform provides a unified value stream solution, including enterprise agile planning with continuous delivery and release orchestration, continuous testing and application security, that enables organizations to align software development value streams to strategic business outcomes.

Digital.ai

Digital.ai is an industry-leading technology company dedicated to helping Global 5000 enterprises achieve digital transformation goals. Using value stream management as its cornerstone, Digital.ai combines innovative technologies in agile planning, application protection, software testing and delivery, and artificial intelligence into a unified Value Stream Platform. Digital.ai makes it possible to connect software development and delivery efforts to strategic business outcomes and create secure digital experiences customers trust

Gartner Market Guide for DevOps Value Stream Management Platforms, by Hassan Ennaciri, Manjunath Bhat, Daniel Betts, Chris Saunderson, Joachim Herschmann, and Thomas Murphy- 29-Sept-2020.

GARTNER is a registered trademark and service mark of Gartner, Inc. and/or its affiliates in the U.S. and internationally and is used herein with permission. All right reserved.

This year was great for public-private partnerships, especially in the space technology industry. Supported by the Indian government’s liberal policies, several private companies made inroads into this sector.

One of them is AWS, the cloud arm of Amazon, which has swiftly tapped on the multi-billion dollar opportunity with the announcement of a new business segment, ‘Aerospace and Satellite Solutions’ which will now be brought to India. This unit will overlook the innovations in the global aerospace and satellite industry.

AWS’ New Business Segment For India
Teresa Carlson, Vice President for Public Sector and Regulated Industries, AWS, said that the new business segment will help India in reimagine space system architectures and launch new initiatives to process the humongous amount of space, and will provide a secure, scalable, and cost-effective solution for government-sponsored missions and companies. Carlson also said that with India opening the space sector for private players and startups, AWS has placed the country on its priority list.

“We’ll be listening to ISRO (Indian Space Research Organisation) and our partners in India in terms of what we can provide them but from everything we know, they need a humongous data storage and to make sense of huge space datasets, they need edge computing and have to work on their virtual mission operations just like NASA is doing,” she elaborated further.

Notably, AWS already has a fully managed AWS Ground Station that provides satellite owners and operators with global access to their space workloads. This Ground Station is already being effectively used by NASA’s Jet Propulsion, among others.

With AWS Ground Station, users can upload satellite commands and data and can also quickly download a large amount of data using the high-speed AWS Ground Station Network and process it in the Amazon Cloud. It can help save 80 percent of the ground station costs by providing antenna access time on demand.

Speaking of the satellite industry, Carlson said that the world has graduated to a new and daring age in space, with new companies taking bold steps of launching more satellites and launching humans into the orbit, much more than seen before.

Casting a prediction for the future, she said that with low-latency internet, high-resolution, and IoT, in next five years, companies will launch thousands of new satellites which will provide sensing capabilities to customers around the world.

Govt’s Support To Public-Private Partnership
Finance minister Nirmala Sitharaman, in May this year, announced that a level-playing field will be provided to Indian private sector to emerge as ‘co-traveller’ in India’s space sector journey through support for building and launching satellites and also for developing other space-based services. She also added that private companies will be allowed to use ISRO’s facilities and other assets to add to their capabilities. Some of the front running space technology-based startups include Agnikul, Pixxel, Bellatrix Aerospace, and Vesta Space.

Currently, the government is working on a new launch vehicle policy and space exploration policy. Amends are also being introduced to the existing Satellite Communication Policy and Remote Sensing Data Policy to make them more transparent.

Supporting the government’s stance, ISRO chief K Sivan has also said that India’s share in the global space sector market, valued at $350 billion, is just 3 percent. According to him, the situation will not improve if ISRO continues to be the sole player.

NITI Aayog along with AWS has established a Frontier Technologies Cloud Innovation Center (CIC) to help address societal challenges through digital innovation. This will be the first AWS CIC in India, the 12th around the world, and the first AWS CIC that will address societal challenges at a national level. Other countries which has a CIC are Australia, Bahrain, Canada, France, Germany, South Korea, and United States.

The press briefing was attended by Max Peterson, Vice President – International Sales, Worldwide Public Sector, Amazon Web Services, Inc., Anna Roy, Senior Adviser, NITI Aayog, Rahul Sharma, Regional Head, AISPL Public Sector, AWS India and South Asia, among others.

The AWS Cloud Innovation Centers Global Program provides an opportunity for government agencies, nonprofits, and education institutions, to collaborate on pressing challenges, apply design thinking methodology, test new ideas, and access technology expertise from AWS.

“We are seeing public sector organizations around the world use cloud technology to innovate in a fast and agile manner, address problems at scale, and transform public services for citizens,” said Peterson in the press briefing. He further added that the CIC program is designed to be a catalyst for innovation in the public sector. “We are excited to collaborate with NITI Aayog, and support its public sector mission in India,” he added.

“Through the CIC program, we have the opportunity to experiment with the latest technology and access world-class innovation expertise that will help us advance citizen services, and better understand how frontier technologies can address the unique needs of our country,” said Roy. She hopes that the NITI Aayog CIC with AWS will bring together government stakeholders, startups, and local organizations in India to innovate and create new approaches to solving problems.

The cloud innovation center will allow collaboration with local leaders, including subject matter experts at the state and district level, to solve critical societal challenges. It will allow local enterprises, startups, researchers and universities to experiment and build prototypes on AWS Cloud and contribute along with the global CIC community dedicated to accelerating societal innovation.

“We are deeply committed to help public sector organizations in India achieve transformational economic and societal impact, and look forward to sharing our global experiences to accelerate digital innovation in the country,” said Rahul Sharma.

What Is DataOps?

According to Gartner’s Innovation Insight for DataOps (December 2018), “DataOps is a collaborative data management practice focused on improving the communication, integration, and automation of data flows across an organization.”

DataOps is a relatively new discipline that applies lean and iterative practices to the data lifecycle. Where DevOps brought developers and IT operations teams closer together to accelerate software delivery, DataOps targets a different cast of stakeholders: data engineers, data analysts, data scientists, and the business users who consume their output. The goal is to stream reliable, timely data through pipelines to consumers — whether those consumers are people, analytics dashboards, or machine-learning models.

DataOps vs. DevOps: More Than Just “DevOps for Data”

It is tempting to describe DataOps simply as “DevOps applied to data analytics,” but that framing undersells the differences. Both methodologies attack the same root problem — siloed teams, slow delivery, and poor feedback loops — but they do so in different domains with different constraints.

• DevOps addresses the challenge of continuously building and deploying software applications by bridging development and IT operations.
• DataOps addresses the challenge of continuously developing, validating, and delivering data flows and analytical insights across an organization.

Understanding both the shared principles and the meaningful differences helps teams decide which practices to adopt and how to adapt them to their specific context.

Three Core Similarities Between DataOps and DevOps

1. Continuous Integration and Continuous Delivery (CI/CD) Architecture

DevOps popularized CI/CD pipelines for software: code is integrated frequently, tested automatically, and deployed rapidly. DataOps applies the same cadence to data. Traditional extract-transform-load (ETL) workflows built around monolithic enterprise data warehouses were designed for stable, predictable data in long release cycles. That model struggles to keep pace with the speed at which data sources, schemas, and business requirements change today.

Cloud platforms have become the enabling infrastructure for both movements. Just as DevOps teams measure success partly by time to market for a product feature, DataOps teams measure success by how quickly accurate insights reach the people and systems that need them. Shortening that cycle is a direct competitive advantage.

2. Cross-Team Collaboration

A foundational DevOps principle is eliminating the handoff friction between development and operations. Containerization (Docker, Kubernetes, and similar technologies) was transformative here: a container packages an application with its entire runtime environment, so the classic “it works on my machine” problem is largely solved. Containers became a shared language that both developers and operations engineers could work with.

DataOps requires its own common language. Gartner describes this as data literacy — sometimes called “data as a second language.” Self-service data preparation tools that offer visual, low-code or no-code interfaces allow data analysts and business users to collaborate with data engineers on building and validating data pipelines, without requiring every participant to be a Python or SQL expert. This shared tooling plays the same bridging role that containers play in DevOps.

3. Large-Scale, Global Provisioning and Monitoring

DevOps at enterprise scale demands centralized management: monitoring dashboards, logging, usage metrics, and catalog management that span multiple geographies and user bases. DataOps has the same requirement. A unified catalog of data assets, versioning of data preparation workflows, and environment monitoring are all necessary to operate data pipelines reliably at scale. Without a centralized control plane, teams lose visibility into data lineage, quality, and access patterns.

Three Key Differences Between DataOps and DevOps

1. Relevance and Timeliness of the Artifact

Software code, once deployed, can continue to serve users for months or years with minimal change. Data has a much shorter shelf life. A business report based on last quarter’s data may still be useful; a fraud-detection model trained on data that is six months stale may cause real harm.

This means data pipelines cannot be static. They must continuously re-discover sources, detect schema drift, identify anomalies, and adapt to new business logic. Augmented data preparation tools — those that use machine learning to surface new patterns, flag anomalies, and suggest transformations — are gaining importance in DataOps precisely because they reduce the manual effort required to keep pipelines current.

2. Stakeholder Alignment and Competing Goals

In a typical DevOps model, both developers and operations engineers share a broadly aligned technical goal: ship a high-quality, scalable product. In DataOps, the stakeholder map is more complex. Business analysts and domain experts care primarily about data discovery, self-service exploration, and fast insight delivery. Central data engineering or governance teams care about data integrity, security, lineage, and the auditability of data assets used in decision-making.

These goals are not inherently in conflict, but they require deliberate tooling and process design to keep both groups productive. Technologies that combine self-service data preparation (for business users) with centralized governance and operationalization controls (for technical teams) are necessary to serve both constituencies without forcing a compromise on either side.

3. Ecosystem Maturity

DevOps has a fifteen-year head start. Since roughly 2009, a rich ecosystem of tooling has developed around it: source control systems (Git), CI/CD platforms (Jenkins, GitHub Actions, GitLab CI), container orchestration (Kubernetes), monitoring stacks (Prometheus, Grafana), incident management platforms, and more. Organizations have well-established patterns for adopting these tools together.

The DataOps ecosystem is younger and still maturing. Categories like data observability, data cataloging, pipeline orchestration, and data quality monitoring are all active areas of product development and consolidation. Teams adopting DataOps today should expect to assemble more of their own toolchain and to see significant market evolution in the coming years.

Bringing It Together: Why DataOps Matters Now

The business context for DataOps and DevOps is analogous: both exist because the pace of change has outgrown the processes that organizations traditionally used to manage complexity. Whether the artifact is a software product or a data-driven insight, speed to delivery and reliability in production are competitive differentiators.

For engineering teams building or evolving a data platform, DataOps is worth taking seriously as a cultural and architectural framework — not just a rebranding of existing practices. The practical starting points include:

• Treat data pipelines as code — version them, test them, and deploy them through automated pipelines.
• Build cross-functional squads — pair data engineers with domain experts and analysts rather than operating in separate silos.
• Invest in observability — monitor data quality, freshness, and lineage as rigorously as you monitor application uptime.
• Enable self-service carefully — provide business users with governed sandboxes where they can explore and prepare data without bypassing quality controls.
• Plan for ecosystem immaturity — evaluate tools critically and build integrations thoughtfully, knowing the market is still evolving.

As data volumes grow and organizations rely more heavily on analytics and machine learning to drive decisions, the gap between teams that have adopted DataOps practices and those that have not will become increasingly visible in both speed and data quality.

The Pace of Modern Software Delivery

Continuous integration and continuous delivery (CI/CD) have fundamentally changed the rhythm of software releases. According to a survey of 500 IT executives released by Capgemini and Sogeti in collaboration with Broadcom, 58% of enterprises deploy a new build daily, and 26% do so at least hourly. When software ships that fast, quality assurance can no longer be an end-of-cycle event—it has to be woven into every stage of the pipeline.

That is the core argument for continuous testing: fast, automated validation of software releases that keeps pace with agile development. The survey found that nearly one-third of IT executives (32%) reported their IT departments had “fully embraced” continuous testing—a meaningful milestone, though it also means the majority have not.

Automation Gap: The Elephant in the Testing Room

It might seem self-evident that continuous testing demands heavy automation. The survey data, however, reveals a significant shortfall between aspiration and practice:

• Only 24% of test cases were being executed through automation.
• Only 24% of end-to-end business scenarios were covered by automated tests.
• Only 25% of required test data was being generated automatically.

Perhaps most telling: more than one-third of respondents (36%) said that the majority of their testing time is currently consumed by searching for, managing, maintaining, and generating test data. Test data management is frequently an afterthought in CI/CD strategy, yet here it emerges as one of the biggest drains on engineering time.

AI and Machine Learning: Potential, Not Yet Reality

Artificial intelligence is frequently cited as a solution to test optimization challenges, and the survey reflects this optimism—with caveats. At least 28% of executives reported an intent to introduce AI to manage their continuous testing processes. The survey authors note that machine learning capabilities could eventually allow systems to automatically determine which tests are required in each release and production cycle, reducing manual triage and prioritization effort.

However, the survey did not clearly quantify how deeply AI was already embedded in active testing cycles at the time of publication. The distinction between planned adoption and live deployment matters: intent is not implementation. Teams evaluating AI-assisted testing tools should look for concrete capabilities such as failure prediction, test case prioritization based on code change analysis, and self-healing locators for UI tests.

Transparency and Pipeline Visibility Are Non-Negotiable

Speed without visibility creates risk. The survey highlights that executives recognize this: 35% identified a “complete audit trail of testing activities” and a “consolidated test and release pipeline” as the most important test orchestration capabilities. A further 32% pointed to the need for a “single place for cross-team collaboration” and “continuous delivery pipeline visibility.”

These findings underscore that continuous testing is not only a technical challenge—it is an organizational one. When multiple teams contribute to a shared pipeline, siloed test results and opaque quality gates create bottlenecks and finger-pointing. A shared, real-time view of test status across the delivery pipeline reduces ambiguity and accelerates decision-making.

Capgemini’s Recommendations for Continuous Testing Success

Based on the survey findings, the Capgemini authors put forward four practical recommendations for organizations looking to mature their continuous testing practice:

1. Create visibility of quality processes by implementing customized QA dashboards that surface test results and quality metrics across CI/CD pipelines in real time.
2. Establish automated testing cycles early in the development lifecycle so that defects are caught as close to their point of introduction as possible—reducing the cost and effort of remediation.
3. Leverage AI and machine learning to optimize test cycles, prioritize high-risk test cases, and reduce redundant test execution.
4. Automate the self-provisioning of test data to eliminate the manual bottleneck that, per the survey, consumes over a third of testing time for many organizations.

What This Means for DevOps Teams

The survey paints a picture of an industry in transition. CI/CD adoption is widespread enough that daily and even hourly deployments are now common. Yet the testing infrastructure needed to validate that velocity safely has not kept pace. Automation coverage remains low, test data management is largely manual, and AI-assisted testing is still mostly aspirational.

For DevOps and platform engineering teams, the takeaway is clear: investing in test automation and test data infrastructure is not a quality-of-life improvement—it is a prerequisite for sustainable delivery speed. Without it, the pace of CI/CD becomes a liability rather than an advantage.

The original ZDNet article covering these survey findings can be found at zdnet.com.

The State of Enterprise Cloud Heading into 2019

By the start of 2019, enterprise cloud computing had moved far beyond its origins as a simple server hosting platform. Driven by digital transformation initiatives, cloud adoption was accelerating across organizations of every size. Analyst firm Gartner projected the worldwide public cloud market would grow 17.3%, reaching approximately $206.2 billion in 2019—a figure that reflected both expanding workload migration and the proliferation of cloud-native services.

A LogicMonitor survey from that period identified digital transformation as the primary driver behind public cloud engagement, with the same research forecasting that 41% of all enterprise workloads would run on public cloud platforms by 2020. When public, private, and hybrid deployments were counted together, roughly 83% of enterprises were expected to rely on cloud infrastructure by the end of the decade.

The IDG 2018 Cloud Computing Survey added further weight to these projections, reporting that 73% of organizations had already shifted mission-critical workloads and computing infrastructure into the public cloud, while approximately 17% planned a full migration to public cloud platforms within the year.

Hybrid and Multi-Cloud Solutions Dominate Enterprise Strategy

A full lift-and-shift to a single public cloud proved difficult and costly for most enterprises. Hybrid cloud—combining the scalability of public cloud with the control of on-premises or private infrastructure—emerged as the pragmatic middle path. It allowed organizations to migrate resources incrementally, manage risk, and maintain compliance requirements for sensitive workloads.

At the same time, enterprises were not confining themselves to a single vendor. According to the RightScale 2018 State of the Cloud Survey, 81% of enterprises had adopted a multi-cloud strategy, spreading workloads across providers such as AWS, Microsoft Azure, and Google Cloud. This vendor diversification reduced lock-in risk and allowed teams to select best-of-breed services for specific use cases.

The practical outcome was a cloud architecture for most large organizations that blended on-premises infrastructure, private cloud resources, and multiple public cloud vendors—a pattern that has only deepened in the years since.

Cloud Service Models: SaaS, IaaS, and BPaaS Growth Projections

Gartner’s worldwide public cloud service revenue forecast for 2019 broke down growth expectations by service model:

• IaaS (Infrastructure as a Service) was the fastest-growing segment, with projected growth of 27.6%, expected to reach approximately $39.5 billion in revenue.
• SaaS (Software as a Service) remained the largest segment overall, with 17.8% projected growth to reach roughly $85.1 billion.
• BPaaS (Business Process as a Service) was forecast to achieve around 7.9% growth, reaching approximately $50.3 billion.

A KPMG report titled Journey to the Cloud projected that enterprise investments in PaaS (Platform as a Service) would grow to 56% in 2019. Together, these forecasts pointed to a cloud services market expanding in both breadth and depth, with enterprises consuming a broader mix of delivery models rather than converging on a single one.

GDPR and the Intensifying Focus on Cloud Security

Security consistently ranked as the top concern for enterprises moving workloads to public cloud platforms—a finding LogicMonitor reported in its research. The introduction of the EU General Data Protection Regulation (GDPR) in May 2018 significantly raised the stakes. With substantial fines for non-compliance and breach notification requirements, organizations operating in or serving customers in the EU had strong regulatory incentives to audit their cloud security posture.

Key security considerations for enterprise cloud teams in 2019 included:

• Data residency and sovereignty — ensuring data was stored and processed in jurisdictions that met GDPR requirements.
• Shared responsibility clarity — understanding where the cloud provider’s security obligations ended and the customer’s began.
• Access management — enforcing least-privilege access controls, multi-factor authentication, and robust identity management across multi-cloud environments.
• Breach detection and response — implementing monitoring and incident response plans aligned with GDPR’s 72-hour breach notification window.

While major cloud vendors incorporate enterprise-grade security capabilities into their platforms, compliance responsibility under GDPR ultimately rests with the data controller—typically the enterprise itself. CIOs and security architects needed to verify that their chosen platforms and configurations genuinely met regulatory requirements, not simply assume vendor defaults were sufficient.

Quantum Computing: Edging Toward Enterprise Relevance

Quantum computing was a major topic of discussion heading into 2019, even if commercially viable enterprise applications remained years away. Several technology companies had made notable investments and announced concrete milestones:

• IBM had released a 20-qubit quantum system in 2017 and made it accessible to researchers via IBM Q Experience.
• Alibaba, in collaboration with the Chinese Academy of Sciences, had developed an 11-qubit quantum computing system.
• Intel, Microsoft, and Google were all actively investing in quantum hardware and algorithms research.

The most compelling near-term opportunity lay in the intersection of quantum computing and cloud infrastructure. If cloud providers could offer quantum processing as a cloud service, enterprises could access quantum capabilities for specific computationally intensive problems—such as optimization, cryptographic research, molecular simulation for drug discovery, or financial modeling—without needing to own or operate quantum hardware directly.

In 2019, quantum cloud computing was still largely experimental, but the trajectory was clearly set toward offering it as a managed cloud service, a direction AWS (Braket), IBM (Q Network), and Microsoft (Azure Quantum) would all pursue in subsequent years.

What These Trends Meant for CIOs and DevOps Teams

The convergence of these trends placed clear demands on enterprise technology leaders and engineering teams:

• Adopt a multi-cloud architecture mindset — design systems to be portable and interoperable across providers rather than deeply coupled to a single vendor’s proprietary services.
• Treat security as a first-class engineering concern — bake compliance requirements such as GDPR into cloud architecture decisions from the start, not as an afterthought.
• Evaluate the full spectrum of service models — IaaS, PaaS, SaaS, and BPaaS each offer different trade-offs in control, cost, and operational overhead; choose per use case rather than defaulting to a single model.
• Monitor emerging capabilities — quantum computing and AI-powered cloud services were beginning to move from research labs toward early commercial availability, and staying informed positioned teams to evaluate them when ready.

Summary

The enterprise cloud landscape entering 2019 was characterized by rapid adoption, increasing architectural complexity, and mounting regulatory pressure. Hybrid and multi-cloud strategies emerged as the dominant approach, cloud service revenues across IaaS, SaaS, and BPaaS were on strong growth trajectories, GDPR was forcing a more rigorous approach to cloud security, and quantum computing was transitioning from research curiosity to a nascent cloud service category. For organizations that engaged thoughtfully with these trends, 2019 offered a genuine opportunity to mature their cloud strategy and build a more resilient, capable infrastructure for the years ahead.

I’ve gone head-first into the world of DevOps, and, it’s been an amazing ride. I’ve had many of my own misconceptions blown away after learning the deep culture and philosophy behind DevOps. That and surrounding myself with people who actually implement the concepts of DevOps have been absolutely enlightening as well.

If you still need a primer check out my DevOps 101 article for a bit more detail. Otherwise, just remember that DevOps isn’t just two words combined together. DevOps is all of the following:

• A cultural shift in how processes, code, and technology are delivered
• A philosophy around continuous development and integration with users, business, and even market dynamics
• A practice that continuously evolves
• A tool to help deliver services and applications at market-ready speeds
• A process to help companies innovate at a much faster pace than what traditional (or legacy) software tools and infrastructure could offer

Today, we look at another extremely critical concept: Security as it is “injected” into the entire DevOps process. Before we go on, it’s important to note that there’s already some level of security testing and validation happening even in traditional DevOps practices. However, DevSecOps takes this concept and development operations much further.

“When an organization adopts true DevSecOps practices, you’ll start to see noticeable change within the code and the production applications,” stated Adam Auerbach, vice president and co-head of DevTestSecOps Practice at EPAM, in a recent interview. “Operations teams will move from service providers to real enablers. This means spending more time on critical things like automation to enable developers to have more control over standing up new environments and promoting code.”

Let’s pause here. Injecting security into DevOps can be a contextual practice. What are you developing? What’s the environment? Is it on-premise or is it in the cloud? Are you dealing with sensitive data points? At a high level, you continue with your existing DevOps practice while introducing more concepts around “secure coding”. This means incorporating both governance and security controls into your development operations. So, you are building around code availability, integrity, and confidence.

From there, you focus on three core areas that bring the security into the development operations process:

Code, service, and data classification. Understanding the type of data that’s being used. Classifying zones and access perimeters. Types of services being leveraged. This can include microservices and containers.

Assurance and automation. Integrating full SDLC controls and audits, continuous code and artifacts scanning, integrated and intrusive security testing. This can also include some manual code reviews.

Policy and process. Analyzing business and resiliency metrics, understanding policies and compliance (GRC), and working with architecture and coding guidelines and best practices.

Code security analysis. Leverage tools that help catch security issues early during development, identify weaknesses in code at exact line locations, testing of dependencies and services. This can also include the identification of integrated and very complex vulnerabilities.

All of that being said, many will argue that one of the most important pieces of DevSecOps is the process of automating security practices within DevOps. The idea is to maintain short and frequent development cycles, integrate security measures with minimal disruption to operations, keep up with innovative technologies like containers and microservices, and all the while foster closer collaboration between commonly isolated teams. However, as RedHat points out, this can be a tall order for any organization. All of these initiatives begin at the human level — with the ins and outs of collaboration at your organization — but the facilitator of those human changes in a DevSecOps framework is automation.

However, you can’t get stuck on automation alone. In fact, one of the biggest mistakes when creating a DevSecOps practice is only looking at things like tools and automation to do the work for you. “DevSecOps is rooted in lean manufacturing and the theory of constraints,” states EPAM’s Auerbach. “While automation will create efficiencies, most likely the biggest improvements can be made when automation is aligned to changes in organizational structure and cultural patterns. The other mistake is leaving security and performance testing out of the equation. While they are more challenging to solve, they will restrict you at some point in the process.”

This means incorporating things like penetration testing, infrastructure audits, and even development processes reviews. Many organizations will go as far as creating ‘pen teams’ analyzing how a target tolerates real attacks, how far an attacker can actually go, analyzes governance and control, and even looks at vulnerabilities within the infrastructure (VPN, WiFi connections, servers, networks, etc.).

Final thoughts and some DevSecOps best practices

As you look at your own practice, how are you involving security with your development process? As a chef in your own kitchen, it might be best to sometimes get an outside opinion. This means working with partners and organizations that are deeply involved in the DevSecOps practices field and those that can guide you in the right direction.

But, to leave you with some food for thought. Here are three things to think about when working to go from DevOps to DevSecOps:

1. When you’re defining your own DevOps and DevSecOps practice, it’s absolutely critical to make sure that your InfoSec teams have a seat at the table. Their insight will prove valuable in designing safer and more secure applications.
2. Ensure that security and performance are treated with the same expectations as other quality gates.
3. “Help the teams understand how to interpret and be proactive with security and performance tuning and troubleshooting,” adds Auerbach. There needs to be a balance between user experience and the amount of security that’s injected into the DevOps process. This is where a good practice can create the right equilibrium to produce quality code, securely, while still focusing on tuning and experience

Open source libraries and frameworks play a crucial role in the DevOps environment that emphasizes the shorter development lifecycles, collaboration, and innovation. It’s important not to neglect the security of these open source components. Here we will talk about five things that one must consider concerning the safety of an open source project.

•  Security Automation

A significant driving force for DevOps is to automate as much as possible. DevOps automation emphasizes using technologies like virtual machines and containerization to repackage applications into reusable blocks, many of which consist of open source code.

Also, because of this automation and at the pace at which the updates occur, security teams are left behind quickly. Information Security teams need to find out ways of automating several of the most critical security procedures. Greater automation into security checks implies that it is less likely that DevOps practices will release software that contains vulnerable open source components.

•  Open Source Tools

Open source codes form the majority of the footprint of modern proprietary codebases and focus on the libraries and frameworks first.  Moreover, open source tools provide an excellent way to improve open source security in DevOps.

•  Incorporation of Open Source Code-Checking Tools Into Development

Shifting security to the left means that developers need to overcome the inherent tendency to focus on application functionality without considering safety. For this, the developers can integrate some open source code-checking tools into development environments.

•  Hackers Target- Open Source

One of the disadvantages with increased use of Open Source is that the malicious actors are aware of the components that contain vulnerabilities and they can use this knowledge to target companies developing software. Hackers are always in search of organizations that have become lax in their security checks; therefore it is advisable for the organizations to keep a regular check.

•  Policy and Governance

For DevOps and open source to work collaboratively, there is an urgent need to develop dedicated open source policies by DevOps organizations. When these developers are given free space to use open source libraries and frameworks without monitoring or documentation, the chances are high that vulnerabilities creep into the applications.

Hence it is evident that the open source model offers benefits to DevOps teams concerning achieving their goals. As security is of prime importance, many source tools are helping to enhance the safety of the applications developed in DevOps.

The Case for Moving Slowly Before Moving to the Cloud

Cloud migration is frequently treated as an urgent, all-or-nothing transformation project. Rob Howe, IT director at Guinness World Records (GWR), offers a markedly different perspective: tread carefully, understand your workloads thoroughly, and only then decide how cloud infrastructure can serve your business goals.

“Cherry pick the key elements — understand the changes you need to make to the infrastructure, and the behaviour of software, when you’re moving over,” says Howe. “Be aware of the differences and account for them. Not all systems will move easily. The cloud should not be viewed as a one-size-fits-all solution to your business challenges.”

Start by Listening, Not Planning

When Howe joined GWR in May 2012, he spent his first six months simply sitting with teams across the business to understand how they worked — without altering or even planning changes to IT systems. This deliberate observation period gave him a clear picture of actual day-to-day workloads before any transformation decisions were made.

“You can’t implement changes without understanding the day-to-day workloads of people across the business,” he explains. “If you’re not involved in the operational side of the organisation, then you’re probably going to fall over something further down the line.”

This approach directly informs one of the most common failure modes in cloud projects: IT teams that design migration plans in isolation, without accounting for how the business actually uses its systems.

A Staged Digital Transformation

Rather than attempting a big-bang migration, Howe led a phased digital transformation that built incrementally on solid foundations. Key milestones included:

• Implementation of a records management platform from SDL
• Deployment of a digital asset management system from Asset Bank
• Adoption of Salesforce CRM technology
• Finally, migration of business-critical IT architecture to Amazon Web Services (AWS), managed by partner Ensono

Cloud migration was treated as the final stage of transformation, not the starting point. That sequencing matters: GWR first consolidated its data management and customer relationship tooling before moving core infrastructure to a public cloud platform.

Managing a Multi-Partner Migration

One of the most underestimated challenges in cloud migration is vendor coordination. GWR’s transition to AWS involved Ensono as the primary partner, plus eight additional providers — including SDL and Asset Bank — all of whom needed to ensure their platforms functioned effectively on AWS.

“Some of these providers have to redesign their platforms to work more effectively on AWS,” says Howe. Managing that coordination across nine vendors simultaneously was, in his assessment, the primary operational challenge of the entire project.

Howe’s advice for other CIOs in this position is direct: find a trusted primary partner and let them lead the infrastructure conversation. In GWR’s case, Ensono — rather than advocating for its own private cloud — recommended migrating to AWS. That willingness to recommend the best-fit solution, rather than the most commercially convenient one, was a key factor in the partnership’s success.

Why Lift-and-Shift Fails

Howe is unambiguous on one point: simply replicating existing on-premises infrastructure in the cloud is a recipe for problems. During pre-migration research, he observed that organisations struggling most with their cloud transitions were those that had taken their existing infrastructure, replicated it as-is, and discovered a host of unexpected issues.

“Don’t just lift and shift — as part of the research I did prior to the move, I found all the people who were struggling had moved to the cloud by just literally taking their existing infrastructure, replicated it and found a bunch of problems.”

— Rob Howe, IT Director, Guinness World Records

A genuine cloud migration requires rethinking how software behaves in an on-demand environment: how it scales, how it fails, how it is monitored and how costs are attributed. Infrastructure that was designed for predictable on-premises conditions may need significant re-architecting before it is cloud-ready.

Real-World Scalability: Handling Unpredictable Traffic Spikes

GWR’s business model has shifted significantly. Historically, the organisation had predictable traffic peaks: the annual book launch each September and Guinness World Records Day in November. As GWR evolved from a publishing business toward a digital media and consultancy model, traffic patterns became far less predictable.

The value of cloud-native auto-scaling was demonstrated almost immediately after go-live. On the first day the new AWS infrastructure was live, a press release about a world record for the largest unlimited wave surfed by a woman went viral in the surfing community. Within hours, GWR’s web traffic reached four times its normal daily volume — a spike the new infrastructure handled comfortably using AWS auto-scaling, without manual intervention or emergency capacity provisioning.

This kind of elastic capacity is particularly valuable for media and content organisations, where a single viral moment can dwarf normal traffic volumes within minutes.

Operational and Financial Benefits

Beyond raw scalability, Howe identifies several operational improvements resulting from the cloud migration:

• Higher service levels across public-facing websites
• Ephemeral project environments: teams can spin up isolated infrastructure for a finite multimedia project and decommission it when complete, avoiding permanent capital expenditure
• Greater cost transparency: cloud billing models make it easier to understand and attribute infrastructure costs
• Improved team agility: IT can focus attention strategically rather than managing routine infrastructure capacity

The ability to provision temporary, isolated environments is particularly relevant for DevOps teams running short-lived feature branches, load tests, or client-specific demos — use cases where permanent infrastructure investment makes no financial sense.

What Comes After Migration: Microservices and Edge Computing

Howe views the AWS migration not as the destination, but as the foundation for continued evolution. His stated next steps at the time of the original interview were:

• Converting GWR’s API layer to a microservices architecture
• Evaluating which data should be distributed to edge locations to improve performance and reduce latency for global users

This progression — from monolithic on-premises infrastructure to public cloud IaaS, then toward microservices and edge distribution — reflects a broadly recognised maturity path for cloud-native engineering teams.

Industry Context: Vendors Embracing Hyperscale Platforms

GWR’s experience aligns with a broader market shift noted by Gregor Petri, research vice president at Gartner. Rather than competing head-on with hyperscale cloud providers such as AWS, Microsoft Azure and Google Cloud Platform, an increasing number of managed service vendors are opting to run their services on top of these platforms — combining their specialist expertise with the scale and reliability of hyperscale infrastructure.

This is precisely the model Ensono adopted with GWR: rather than advocating for its own private cloud environment, it guided the customer toward the platform most likely to meet long-term business needs. CIOs evaluating managed service partners should look for this kind of vendor neutrality as a signal of trustworthiness.

Key Takeaways for CIOs and DevOps Leaders

GWR’s cloud journey surfaces several principles that apply broadly to organisations of any size planning a cloud migration:

1. Understand before you act. Spend time learning how the business actually operates before designing any migration strategy.
2. Stage your transformation. Consolidate critical business systems first; treat cloud migration as a later step, not the starting point.
3. Choose partners carefully. A good partner will recommend the best solution for your situation — not just the one that benefits them most.
4. Don’t lift and shift. Replicating on-premises architecture in the cloud preserves its problems while adding new ones. Design for cloud-native behaviour from the outset.
5. Plan for the unexpected. Unpredictable traffic spikes, viral moments and business model changes are reasons to embrace elastic cloud infrastructure, not reasons to delay migration.
6. Stay ahead of the business. IT’s role is to enable business agility, not to react to it after the fact. Use the cloud’s flexibility to deliver faster, more responsive services.

Cloud migration is not a one-time project. Done well, it creates a platform from which teams can continuously improve services, adopt new architectural patterns, and respond to business change without the friction of fixed infrastructure constraints.

Original reporting by ZDNet. Full interview available at zdnet.com.

Why Methodology Selection Matters

Software development sits at the heart of how modern organisations compete. As companies grow, they need IT solutions that can absorb new customer demands, adapt to a changing market, and outpace competitors — all without overrunning budgets. Choosing the wrong project management framework is one of the most reliable ways to make all three of those goals harder.

Agile methodologies have become the dominant answer to this challenge, but “go agile” is not a single decision — it is the start of a more precise one. Scrum, Kanban, Extreme Programming, and Crystal Clear are all agile frameworks, yet each suits a different type of project, team size, and risk profile. Picking the right one from the start reduces rework, keeps costs predictable, and improves the odds of shipping something stakeholders actually want.

Why Projects Fail Without a Suitable Framework

Software projects fail for a cluster of related reasons, most of which a well-matched methodology directly addresses:

• Rapidly changing technology stacks that invalidate earlier design decisions
• Poor upfront planning that leaves scope undefined
• Weak communication channels between developers, business stakeholders, and customers
• Escalating costs driven by late-stage requirement changes
• Quality shortcuts taken under delivery pressure
• Competitive pressure that demands faster release cycles

Agile frameworks counteract these failure modes by breaking work into short, reviewable cycles, keeping stakeholders involved throughout, and making it structurally easier (and cheaper) to change direction before a bad decision compounds into a bigger one.

Core Benefits of Agile Project Management

Stakeholder Engagement and Customer Satisfaction

Regular sprint reviews create structured opportunities for genuine interaction between developers and clients. When a client can see and test a working increment every one to two weeks, misunderstandings surface early — not after six months of development work has been committed in the wrong direction.

Increased Transparency

Sprint planning and review sessions keep clients visible to progress and blockers. This visibility builds trust and creates the kind of collaborative relationship that makes difficult trade-off conversations easier later in a project.

Improved Software Quality

Continuous design, development, and testing means defects are caught in the same sprint they are introduced rather than discovered during a final integration phase. Iterative retrospectives also let teams continuously improve their own tooling and processes.

Risk Mitigation

Because a working (if small) product exists from the first iteration, the risk of total project failure is structurally lower than in waterfall delivery. Requirement changes are handled within sprint boundaries rather than triggering expensive change-control processes. Early delivery also means earlier return on investment with relatively low up-front commitment.

Predictable Cost and Schedule

With sprint durations fixed at one to four weeks, it becomes straightforward to estimate cost at the sprint level. Stakeholders can make prioritisation decisions each sprint rather than locking in a full project budget based on a speculative plan written before any code exists.

The Foundation: The Agile Manifesto’s Four Core Values

Every agile methodology draws from the same source: the four values established in the 2001 Agile Manifesto. Understanding these values makes it much easier to evaluate which framework fits your context.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a fixed plan

All four values share a common thread: prioritise the human and iterative elements of software delivery over rigid process and documentation. The twelve Agile Principles extend these values into more specific guidance on things like release frequency, technical excellence, and self-organising teams.

Common Agile Methodologies and When to Use Each

The four frameworks below cover the majority of use cases in software engineering teams. Each shares the agile foundation but differs in structure, ceremonies, roles, and suitability.

1. Scrum

Scrum is the most widely adopted agile framework. Work is organised into sprints — fixed iterations typically one to two weeks long — at the end of which a potentially shippable increment is delivered. Three defined roles divide responsibilities clearly:

• Product Owner — owns the product backlog, makes prioritisation decisions, and represents business value.
• Scrum Master — facilitates ceremonies (daily stand-up, sprint planning, sprint review, retrospective), removes blockers, and coaches the team on the framework.
• Development Team — self-organising group that selects backlog items each sprint and determines how best to deliver them.

Best suited for: Projects with evolving requirements and a team of roughly five to nine people. Scrum works across a wide range of industries and project types — software, hardware, marketing campaigns — wherever iterative delivery and regular stakeholder feedback are valuable.

2. Kanban

Kanban is a flow-based approach that emphasises continuous delivery rather than fixed sprint cycles. Work items move through a visual board (typically columns such as To Do → In Progress → Done), and the key constraint is a Work In Progress (WIP) limit on each column. This prevents the team from taking on more tasks than it can complete, reducing context-switching and bottlenecks.

Kanban’s three core principles are:

• Visualise work — make all tasks and their status visible to the whole team.
• Limit WIP — cap simultaneous work to maintain sustainable throughput.
• Improve flow — continuously analyse and remove bottlenecks so work moves smoothly through the system.

Best suited for: Operations, support, or maintenance work where tasks arrive continuously rather than in planned batches. Kanban has no prescribed team size, making it flexible for both small and large teams. It is also useful alongside Scrum (sometimes called “Scrumban”) for teams managing both feature development and ongoing support.

3. Extreme Programming (XP)

XP is an engineering-focused agile methodology that pairs short iterations (typically one to three weeks) with a strong emphasis on technical discipline. Its defining practices include pair programming, test-driven development (TDD), continuous integration, and collective code ownership. XP follows four core values:

• Simplicity — build only what is needed right now, not what might be needed later.
• Communication — frequent, direct collaboration between developers and customers.
• Feedback — automated tests and short release cycles generate constant feedback loops.
• Courage — willingness to refactor code, discard failing approaches, and raise difficult issues early.

Best suited for: Complex projects where technical quality is critical and requirements are expected to change frequently. XP works best with experienced, highly skilled teams of up to around ten developers who are comfortable with rigorous engineering practices. It is less appropriate for teams unfamiliar with TDD or where pairing is culturally difficult.

4. Crystal Clear

Crystal Clear is part of the Crystal family of methodologies developed by Alistair Cockburn. It prioritises people and communication over process overhead, and it scales its practices to fit the size and criticality of the project rather than imposing a one-size-fits-all structure.

Crystal Clear has three mandatory properties:

• Frequent delivery — shipping working software to real users regularly, even on long projects.
• Reflective improvement — the team regularly steps back to examine and improve its process.
• Osmotic communication — team members share the same physical (or virtual) space so that information flows naturally without the overhead of formal meetings.

Best suited for: Small co-located teams of six to eight people working on non-life-critical systems. Iteration length can extend up to four months for larger, more complex work within this team size. Crystal Clear is a good choice when teams want the benefits of agile without the ceremony overhead of Scrum.

How to Choose: A Practical Decision Framework

No single methodology is universally correct. Work through these questions to narrow your options:

1. What is your team size? Scrum and XP work well up to ~10 people. Crystal Clear targets 6–8. Kanban scales freely.
2. How stable are your requirements? Highly volatile requirements favour XP’s engineering rigour or Scrum’s sprint-based replanning. Stable, flow-based work suits Kanban.
3. How experienced is your team? XP demands mature engineering practices. Scrum’s ceremonies are easier to adopt incrementally. Crystal Clear reduces ceremony further for experienced small teams.
4. What is your delivery cadence need? If you need a fixed release every two weeks, Scrum’s sprint model aligns well. If delivery is continuous (e.g., a support queue or a SaaS product), Kanban is a better fit.
5. How involved can your stakeholders be? All agile methods require stakeholder participation. Scrum formalises this through the Product Owner role. If customer access is limited, factor that constraint into your choice — it will affect how well any agile framework performs.
6. What is your risk tolerance? For high-stakes, complex projects where quality failures are costly, XP’s test-driven approach and Scrum’s structured review cycles reduce risk most explicitly.

Summary Comparison

Final Thoughts

There is no universally correct agile methodology. The right choice is a function of your team’s size, skill level, the stability of your requirements, the degree of stakeholder access you have, and the criticality of the software you are building. What all four frameworks share is a commitment to frequent delivery, stakeholder collaboration, and continuous improvement — and those principles are non-negotiable regardless of which framework you adopt.

From a cost perspective, the most important step is to make a deliberate choice rather than defaulting to whichever framework a team member last used. A mismatched methodology generates waste — unnecessary ceremonies, poorly scoped sprints, or insufficient quality gates — that is far more expensive than the time it takes to evaluate your options upfront.

The Data Gravity Problem

The IT industry is in the midst of a fundamental shift in how data is generated, stored, and consumed. Data is no longer confined to the data center. It is distributed across on-premises infrastructure, private clouds, public cloud platforms, and increasingly the edge. This distribution creates a challenge that is easy to overlook in high-level architecture conversations: data gravity.

Data gravity is the tendency of large data sets to attract applications and services — and to resist being moved. The more data accumulates in one location, the more expensive, slow, and disruptive it becomes to relocate or replicate that data elsewhere. This is not a software problem or a networking problem in isolation; it is fundamentally a physics problem. Bandwidth costs money, latency is real, and data at rest has inertia.

Why Hybrid and Multi-Cloud Make This Harder

Public cloud computing delivers compelling value: dynamic resource provisioning, elastic capacity, and the elimination of large upfront capital expenditures. These benefits explain why most enterprise IT organizations have adopted some form of public cloud strategy.

However, public cloud adoption does not eliminate on-premises infrastructure. It supplements it. The result is a hybrid environment where:

• Some workloads run on-premises for latency, compliance, or cost reasons.
• Other workloads run in one or more public clouds for scalability and flexibility.
• Data must flow consistently and reliably between all of these environments.

This is where data gravity bites hardest. A real-time analytics pipeline that depends on data sitting in an on-premises storage array cannot simply be lifted to the public cloud without addressing how that data gets there — and how quickly, consistently, and affordably it can be accessed from multiple locations simultaneously.

Migration Is Necessary But Not Sufficient

Almost every enterprise storage vendor offers some form of data migration tooling. Cloud tiering, data replication, and snapshot-based offload are standard features. However, migration alone does not solve the data gravity problem for several reasons:

• Availability vs. timeliness: Moving data to the cloud improves availability in principle, but it does not guarantee that the data is current, consistent, or accessible with acceptable latency at the moment it is needed.
• Cross-site consistency: When the same data set is accessed from multiple environments simultaneously — on-premises and cloud — maintaining consistency without significant engineering overhead is non-trivial.
• Vendor lock-in: Many cloud-provider-native storage solutions make it difficult or expensive to move data back on-premises or to a different cloud provider.

The goal for any modern IT architecture should be seamless data mobility: the ability for hybrid applications and their associated data to move between environments without operational compromise or lock-in.

Storage Is the Right Layer to Solve This

Data accessibility in a hybrid environment is not primarily an application-layer concern. Applications consume data; they do not own its placement, replication, or tiering. The storage layer has a unique end-to-end view of data — from ingest through consumption — regardless of where those endpoints are located. This makes storage the correct place to enforce policies around availability, performance, data protection, and compliance.

An effective hybrid storage architecture should provide:

• Tiered availability from flash to cloud: Hot data stays on high-performance flash; colder data tiers to lower-cost cloud storage — with policies that can promote or demote data automatically.
• Unified management: A single management interface that abstracts the physical and geographic boundaries between on-premises and cloud storage.
• No compromise on resiliency or compliance: Data protection, encryption, and compliance controls must apply uniformly regardless of where data physically lives.
• Open APIs: Enabling application-specific integrations and automation without being locked into proprietary toolchains.
• Consistent data reduction: Deduplication and compression should work across the full data lifecycle, not just on-premises.

Where Converged Infrastructure Falls Short

Converged infrastructure (CI) and hyper-converged infrastructure (HCI) approaches — such as those offered by Dell EMC and Hewlett Packard Enterprise — abstract physical compute, networking, and storage into unified platforms. Composable infrastructure and active data fabric architectures extend these concepts further. These are genuinely useful for simplifying on-premises management and extending consistent operational models toward the cloud.

However, converged approaches optimise the compute and control plane. They do not inherently solve the underlying storage data gravity problem. Extending a converged infrastructure to bridge into a public cloud is valuable, but it does not automatically mean that data can move freely, consistently, and at acceptable performance levels between all environments.

Storage problems are best solved by purpose-built storage innovation, not as a by-product of compute or networking abstraction.

The Role of Software Abstraction Vendors

Software-defined and cloud management vendors — including VMware, Nutanix, and others — play a critical role in smoothing the control plane between on-premises environments and public clouds from providers such as AWS, Microsoft Azure, and Google Cloud. This work is essential for workload portability and operational consistency.

But control plane consistency and data plane consistency are not the same thing. You can have a unified management view of a workload running across environments while still facing severe data gravity constraints that make that workload slow, costly, or brittle. The storage industry must innovate in parallel — not wait for the control plane to catch up — if the full promise of hybrid cloud is to be realized.

What Good Looks Like

The end state that modern enterprises should expect from their storage infrastructure in a hybrid world is straightforward to describe, even if it is technically demanding to deliver:

• 24/7 real-time access to all data and applications, regardless of physical location.
• Data that moves freely and transparently between on-premises, private cloud, edge, and public cloud environments.
• No forced trade-off between on-premises performance and cloud flexibility.
• No vendor lock-in that penalizes data mobility.
• Uniform data protection, compliance, and performance guarantees across all environments.

Achieving this requires storage vendors to extend their architectures beyond the data center boundary and treat the cloud as a native storage tier — not an afterthought or a migration destination.

Final Thoughts

Hybrid cloud is the operational reality for most enterprise IT organizations. The economic and practical benefits of blending on-premises infrastructure with public cloud services are well established. However, the data gravity challenge is a genuine bottleneck that limits how fully those benefits can be realized.

The storage layer is uniquely positioned to solve this problem. Vendors with deep storage expertise — and the willingness to architect their platforms natively for hybrid and multi-cloud environments — have a significant opportunity to change how data moves and is accessed at enterprise scale. This is not a problem that public cloud providers will solve unilaterally, and it is not a problem that software abstraction alone will eliminate.

The storage industry must step up. For organizations planning or evolving their hybrid cloud strategy, storage architecture decisions made today will determine how much operational freedom — or data gravity constraint — they live with for years to come.

NetApp, the data authority for hybrid cloud, announced updates to Trident, its automated provisioner solving the persistent storage challenge for containers, a new verified architecture for Red Hat OpenShift Container Platform on NetApp HCI, as well as enhanced flexibility for DevOps on both NetApp Cloud Volumes for Google Cloud Platform and NetApp Cloud Volumes for AWS.

The announcement follows NetApp’s recent acquisition of StackPointCloud, an advanced Kubernetes-as-a-service platform that directly supports the application orchestration capabilities across clouds. Following the acquisition, NetApp launched the NetApp Kubernetes Service, a Universal Control Plane for Managed Kubernetes, which dramatically simplifies the deployment of a Kubernetes cluster to the cloud.

NetApp also recently announced new Ansible modules for Element, which provide integration for NetApp HCI and SolidFire solutions; ONTAP, which provides integrated solutions for NetApp AFF and FAS systems; and SANtricity®, which provides integrated solutions for NetApp E-Series systems. This new capability enables customers to use familiar tools to define and deploy consistent infrastructure for development, test, and production.

In-house developer teams play an important role in the ability of a business to pursue new revenue streams, but the long-standing cultural divide between development and operations has traditionally inhibited collaboration and led to slow development cycles. By creating data services that help build trust between developers and operations, NetApp aims to provide the tools that, together with DevOps techniques and methods, enable companies to transform this paradigm.

“Delivering business value from data often depends on developers’ ability to rapidly innovate through methods like DevOps, but organizations often lack the infrastructure to support the flexible, collaborative approach required for a true DevOps culture,” said Brad Anderson, SVP and GM, Cloud Infrastructure at NetApp.

“NetApp provides data products and services that are purpose-built to help developers and operations better align, while also enabling the technology independence that developers need to keep creating and driving value and strategic advantage for the business,” he added.

Intro

Continuous integration/continuous delivery (CI/CD) is the next logical step in the evolution of software development, packaging, and deployment. It utilizes automation to deploy software changes faster, safer, and more frequently than ever before. Next generation toolkits are now available to implement CI/CD methodology.

What’s the earliest build tool you remember using? Tools such as GNU Make, Scons,  and Autoconf date back to the 1990s and beyond. They give many seasoned developers unpleasant memories of hours of fruitless struggle and broken configurations. As infrastructure became more complex and dynamic, build tools needed to become more automated and sophisticated. This led to increasing automation, along with rapid development tools and methodologies.

Today’s toolkits handle everything from configuration to testing to packaging to deployment. In fact, modern build systems have enabled a new paradigm of software and configuration management: continuous integration and continuous delivery (CI/CD). In the eBook Modern App Builds for Modern App Builders, we explain where our complicated toolkits originated and how an organization can rethink their tools for CI/CD.

What is CI/CD?

The expectation for software has outgrown the old deployment models. Modern architecture is far more diverse and complex, and customers expect more frequent deployments. Instead of just deploying to a handful of servers, deployment targets clusters of VMs, clouds, and on-prem data centers. These changes in scope mean that reliability, flexibility, and scalability are more necessary than ever.

An infrastructure using CI/CD leverages the latest technology to keep deployed applications up to date. CI/CD integrates well with modern project management practices such as Scrum and Agile. These new tools and techniques have increased not only the speed of deployment but also the quality and adaptability of modern software.

Projects that benefit from CI/CD employ a wide variety of technology and deployment targets, including Docker containers, OS packages and bundled programming libraries. Modern automated application build tools manage all of these deliverables.

Continuous Integration

The first part of the CI/CD formula is continuous integration. This means that code and configuration changes from developers are frequently committed to the master branch of a project – sometimes multiple times per day. Every time a commit to the master branch occurs, a new build and test cycle is triggered to determine if the new code is ready to be packaged and released. With continuous integration, code freeze is a thing of the past.

Continuous integration used to be just a novel technique to avoid development headaches, a way to make sure that bad code wasn’t introduced to the master branch. Today, it has become an essential tool in the modern software development lifecycle. CI quickly determines if new show-stopping bugs have been introduced, or if code changes have caused regression failures and packaging issues. This prevents many bugs from being released in deployed code and, when done correctly, makes project development move swiftly and smoothly. Extreme programming (XP), an agile methodology introduced in the 1990s, was one of the first to embrace CI.

CI isn’t just a technique, however. It relies on sophisticated modern toolchains that help automate everything from source code change management to quality assurance to software builds. Integrating all of these moving parts to enable automation is a daunting task, but it’s necessary to achieve continuous integration.

Continuous Delivery

The other half of the CI/CD methodology is continuous delivery. This is the practice of automatically deploying successful builds to production environments. Once changes have passed the automated steps in the continuous integration phase, they are considered ready for deployment. As you can imagine, more automation is needed for this step.

The CI process is a critical prerequisite for CD. The automated testing and building that are core to CI inform the CD toolchain if new versions are ready for production deployment. Automation during the deployment phase can include everything from distributing packages to provisioning VMs, containers, and additional cloud resources. Thanks to modern DevOps automation techniques, CD can also include configuration changes down to the OS and networking levels of an application’s infrastructure.

In the past, products that were updated too often were viewed with suspicion, because they were frequently riddled with new bugs, faulty installations, and poor quality control. However, innovations in automated integration, testing, and packaging have changed our expectations for software. Frequently, continuous deployment happens so smoothly that end users are completely unaware. For example, today’s web applications and mobile apps update constantly, and these upgrades are now expected, rather than viewed with trepidation by users. Continuous deployment is vital to the success of a modern application.

Finding Your Path to CI/CD

Even with the best team of developers you can find, your application will never find a foothold in the market without the right build and deployment tools. You can’t skip steps in the journey to automated CI/CD. Start smart, with test-driven development, version control, and automated build and dependency systems. To drive innovation and build quality software for today’s world, you’ll need a good automation toolchain and a strong DevOps culture.

A modern CI/CD methodology will help your team shed the burdens of manual release processes and the headaches of dealing with complex IT environments. If you’re planning to implement CI/CD for your team, our eBook is a great place to start. Each manual process removed from the equation will improve not only the lives of your development team, but the final quality of your deployed software product.

The Digital Transformation Pressure on IT Teams

According to IDC figures cited in the original source, technology and services enabling digital transformation across the Asia-Pacific region were projected to grow by 15.3 percent annually, surpassing $386 billion (USD) in 2018. That growth trajectory placed enormous pressure on CIOs and IT departments to deliver applications faster, at lower cost, and with fewer defects than ever before.

The demand for new web, mobile, and enterprise applications reached a critical inflection point. According to the OutSystems State of Application Development 2018 report, 43 percent of IT teams in the Asia-Pacific region already anticipated delivering ten or more applications that year. Meeting that pace while maintaining high-quality, consistent user experiences across multiple devices and platforms is a challenge that purely hand-coded development struggles to satisfy.

The Core Challenges Slowing Application Delivery

Three interconnected problems hamper most organizations trying to accelerate application delivery:

• Developer shortages. Skilled developers who understand modern frameworks, mobile development, and API integration are scarce and expensive to hire or retain. Retraining existing staff is time-consuming and does not close the gap quickly enough.
• Application backlogs. The same OutSystems report found that 14 percent of IT teams in Asia still carried a backlog of more than ten applications. Average delivery times—47 percent of IT teams reported needing at least five months per application—compound this problem rapidly when demand keeps rising.
• Legacy system complexity. Hard-to-integrate back-office systems and inadequate APIs push IT teams into a maintenance-first posture. When keeping legacy systems operational consumes most available developer capacity, innovation stalls.

Taken together, these constraints make continuous delivery—delivering software updates in short, frequent cycles rather than annual releases—difficult to sustain without a significant rethink of development tooling and process.

What Low-Code Development Actually Does

Low-code development platforms replace large portions of manual, hand-written code with visual modeling tools, pre-built components, and drag-and-drop interfaces. Developers—and, depending on the platform, non-developers—assemble applications from reusable building blocks rather than writing every line from scratch.

The practical workflow typically looks like this:

1. Visual UI modeling. Responsive web interfaces and mobile app screens are designed visually, keeping user experience central from the first day of a project rather than as an afterthought.
2. Rapid prototyping. Interactive prototypes and mockups can be assembled quickly enough to gather real user feedback before committing significant engineering resources.
3. Iterative, collaborative design. Built-in feedback mechanisms allow developers and business stakeholders to iterate without requiring synchronous, co-located sessions.
4. Scale to production. The best platforms allow a prototype to evolve directly into a fully integrated, enterprise-grade application—eliminating the throwaway prototype problem that wastes time in traditional cycles.
5. Integration with existing systems. Modern low-code platforms expose connectors and API tooling so that enterprise applications can interface with legacy back-office systems without extensive bespoke integration code.

How Low-Code Addresses the Innovation Gap

The strategic value of low-code extends beyond simple speed. When application delivery accelerates, the risk-to-reward calculation for custom development changes fundamentally:

• More experiments become viable. If building a prototype costs weeks instead of months, organizations can test more ideas, fail cheaply on the ones that don’t work, and double down on the ones that do.
• Developer capacity is reallocated. Skilled engineers spend less time on repetitive scaffolding and boilerplate, freeing capacity for complex logic, security hardening, and performance optimization.
• Non-technical staff contribute meaningfully. Visual tooling can bring business analysts and domain experts closer to the development process, improving requirement quality and reducing costly misunderstandings late in a project.
• Continuous delivery becomes sustainable. Faster iteration cycles are compatible with continuous delivery pipelines, allowing teams to ship incremental improvements without the overhead of large, risky release events.

Organizational Readiness: Changing Risk Appetite

Technology alone does not deliver transformation. Organizations that invest in design thinking, lean startup methods, and customer journey mapping—but do not change their willingness to experiment and accept early failure—will see limited returns from any new development tooling.

Low-code platforms lower the cost of experimentation, but leadership still needs to create space for it. Bureaucratic requirements-gathering processes and overly risk-averse prioritization will neutralize the speed advantage that low-code provides. The organizational shift required is cultural as much as it is technical: teams must be willing to ship early, gather real feedback, and iterate—rather than pursuing exhaustive upfront specification before writing the first line of logic.

Evaluating a Low-Code Platform: Key Criteria

Not all low-code platforms are equal. When assessing options for enterprise use, IT leaders should examine the following dimensions:

• Integration capabilities. Can the platform connect reliably to your existing ERP, CRM, and data systems via standard APIs or pre-built connectors?
• Scalability and performance. Does generated application code perform acceptably under production load, or does visual abstraction introduce unacceptable overhead?
• Security and compliance controls. Does the platform support role-based access control, audit logging, and data residency requirements relevant to your industry?
• Deployment flexibility. Can you deploy to on-premises infrastructure, private cloud, or public cloud as your governance requirements dictate?
• Vendor lock-in risk. What is the portability of applications built on the platform if you need to migrate or switch vendors?
• Learning curve and training investment. How quickly can existing developers become productive, and does the platform support citizen developers from the business side?

Summary

Digital transformation demands faster application delivery than most organizations can achieve with traditional hand-coding alone. Developer shortages, legacy system complexity, and growing application backlogs create compounding delays that widen the gap between digitally mature competitors and those still catching up.

Low-code development platforms address these constraints by reducing the time and skill required to build, prototype, and iterate on applications. When combined with the right organizational mindset—one that embraces experimentation, values user feedback early, and accepts calculated risk—low-code can meaningfully accelerate digital transformation without demanding proportional increases in developer headcount or budget.

Everyone wants to do DevOps these days, but what does a well-humming DevOps environment really look like? What is the vision to strive for?

To date, DevOps has been popping up as a hodgepodge of activities and initiatives across companies, perhaps in the name of doing it because it’s the thing to do. As a result, companies really aren’t seeing the full potential of DevOps. Consistency in DevOps approaches is a rare thing indeed, relates Kurt Marko, citing a recent survey from Computer Economics. The survey finds “that although about a third of organizations dabble in DevOps, almost none do so formally and consistently across the organization or show any semblance of mastering of DevOps practices.”

That’s because DevOps is more than demanding that everyone get together and throwing some new tools into the mix. As Marko puts it: “DevOps is like dieting: it requires changes in values, attitudes, processes and habits. Such changes are hard and must be practiced, not bought. They require education and discipline, not a purchase order.”

The folks at Google/Alphabet, being the trailblazers they always are, are sharing their vision and experience with what they call “site reliability engineering” (SRE), providing some examples of how well-tuned teams of developers and ops people can work together to make things happen. Rest assured, it is baked deeply into the Google culture.

To clarify, SRE is somewhat different from DevOps, but joined at the hip. “Interestingly, the SRE movement emerged separately from the DevOps movement–although there is little doubt that they are part of the same IT spectrum with similar customer value-driven goals,” Jayne Groll observes in DevOps.com. “DevOps focuses on engineering continuous delivery to the point of deployment; SRE focuses on engineering continuous operations at the point of customer consumption. Both domains rely on sharing, culture, metrics and automation. Both require human and automated resources to ensure a seamless value stream and exceptional customer experience.”

A great illustration is provided by Patrick Hill, site reliability engineer with Atlassian:

“Dev teams want to release awesome new features to the masses, and see them take off in a big way. Ops teams want to make sure those features don’t break things. Historically, that’s caused a big power struggle, with Ops trying to put the brakes on as many releases as possible, and Dev looking for clever new ways to sneak around the processes that hold them back. SRE removes the conjecture and debate over what can be launched and when. It introduces a mathematical formula for green- or red-lighting launches, and dedicates a team of people with Ops skills (appropriately called Service Reliability Engineers, or SRE’s) to continuously oversee the reliability of the product.”

In their latest book and videos on the topic, Betsy Beyer, Chris Jones, Jennifer Petoff and Niall Murphy, all with Google, unveil what they have been doing and provide lessons from which every non-Google enterprise can learn. “For sizes between a startup and a multinational, there probably already is someone in your organization who is doing SRE work, without it necessarily being called that name, or recognized as such,” they point out.

SRE “represents a significant break from existing industry best practices for managing large, complicated services,” Beyer and her associates write, noting this is the best way for a software engineer to invest time to accomplish a set of repetitive tasks. At the same time, “it has become much more: a set of principles, a set of practices, a set of incentives, and a field of endeavor within the larger software engineering discipline.”

The Google team explains that they “apply the principles of computer science and engineering to the design and development of computing systems: generally, large distributed ones.” Their tasks range from “writing the software for those systems alongside our product development counterparts;” to building pieces such as “backups or load balancing,” or simply “figuring out how to apply existing solutions to new problems.”

SREs have three missions: reliability, features and operating services.

• Reliability: Reliability is the top priority for SREs. The Google team cites the words of Google’s Ben Treynor Sloss, originator of the term SRE: “Reliability is the most fundamental feature of any product: a system isn’t very useful if nobody can use it.”
• Features: Once suitable levels of reliability are attained, SREs are charged with features and products.
• Operating services: “Finally, SREs are focused on operating services built atop our distributed computing systems, whether those services are planet-scale storage, email for hundreds of millions of users, or where Google began, web search.”

Overview

In 2017, Capgemini published research indicating that enterprise adoption of cloud-native applications was poised for rapid growth. Conducted by Longitude Research on behalf of Capgemini, the study surveyed 902 senior professionals — evenly split between IT and non-IT roles — from 11 countries across Europe, the Americas, and Australia. Respondents came from banking, insurance, consumer products, retail, manufacturing, and high-tech sectors.

The headline finding: only 15% of new enterprise applications were cloud-native at the time of the study, but adoption was projected to more than double, reaching 32% by 2020.

What “Cloud-Native” Meant in This Context

The report defined cloud-native applications as software and services built specifically to perform optimally in the cloud, typically by leveraging Platform as a Service (PaaS) offerings. This contrasts with “lift-and-shift” approaches, where existing on-premises applications are migrated to cloud infrastructure without re-architecture.

Cloud-native applications are typically characterised by:

• Microservices architecture — functionality decomposed into independently deployable services
• Containerisation — packaging applications with their dependencies for consistent deployment
• Dynamic orchestration — using platforms such as Kubernetes to manage container lifecycles
• CI/CD pipelines — automating build, test, and deployment workflows
• Elastic scalability — scaling individual services horizontally based on demand

Why Organisations Were Moving to Cloud-Native

The study identified the primary business drivers behind the shift. Of the 900-plus respondents, the leading motivations were:

• 74% cited improved business agility
• 70% wanted to increase collaboration with external partners
• 67% aimed to deliver better customer experiences

Notably, cost reduction — traditionally the headline argument for cloud adoption — ranked lower than agility and customer experience improvements. This signals a maturation in how enterprises were framing the value of cloud investment by 2017.

Leaders vs. Laggards: The Performance Gap

The research segmented organisations into “leaders” — those with more than 20% of new enterprise applications developed cloud-natively — and slower adopters. The performance gap between the two groups was significant.

Cloud-native leaders were:

• Nearly twice as likely to report revenue increases attributable to cloud-native applications compared to laggards (84% vs. 44%)
• More likely to describe their software development approach as agile (69% vs. 37%)
• More likely to describe their deployments as automated (78% vs. 46%)
• More likely to report integrated DevOps teams (69% vs. 38%)

Leaders also held a different view of IT’s strategic purpose. Rather than primarily targeting cost reduction, they prioritised improving the customer experience (90%), business agility (87%), and scalability (85%), with cost reduction still valued but ranked lower (79%).

“We predict that cloud-native architectures will become the default option for customer-facing applications by 2020, driven by a need to continuously deploy innovations at an accelerated pace and enhance the customer experience. Businesses that delay adopting this approach will struggle to make up the gap with cloud-native competitors.”

Franck Greverie, Cloud and Cybersecurity Group Leader, Capgemini

Adoption Rates by Industry Sector

Cloud-native leadership was unevenly distributed across sectors. High-tech and manufacturing firms were ahead of regulated industries:

• High-tech firms: 26% were cloud-native leaders
• Manufacturing firms: 29% were cloud-native leaders
• Insurance providers: 18% were cloud-native leaders
• Consumer products, retail and distribution (CPRD): 22% were cloud-native leaders
• Banking providers: Only 11% qualified as cloud-native leaders

Despite lower current adoption, regulated sectors were accelerating. Banks were building 10% of new applications using cloud-native approaches. Nearly half of insurers (47%) and around a third of CPRD firms (27%) stated cloud-native formed a core part of their technology strategy. All three groups planned significantly increased PaaS spending over the following three years — banks and CPRD firms by 41%, insurers by 44%.

Barriers Holding Organisations Back

The report was candid about the obstacles CIOs faced, even in organisations that recognised the value of cloud-native approaches. Barriers fell into two categories:

Organisational Barriers

• 65% cited an ingrained culture resistant to cloud-native ways of working
• 70% reported a skills shortage when developing cloud-native applications
• Difficulty building internal business cases when leadership still measured IT success primarily through cost reduction

Technical Barriers

• 62% struggled to integrate cloud-native applications with legacy infrastructure
• 58% reported being locked into existing vendor contracts that constrained architectural choices

These barriers remain recognisable to DevOps practitioners today, suggesting the report captured structural challenges rather than temporary growing pains.

Six Recommendations for Becoming a Cloud-Native Leader

The Capgemini report offered a practical roadmap for CIOs seeking to close the gap with cloud-native leaders. The six recommendations were:

1. Assess the application portfolio — Identify which applications are candidates for cloud-native development and which should remain on legacy infrastructure for now.
2. Build credibility with a cloud roadmap — Demonstrate a clear, deliverable plan that connects cloud-native investment to business growth outcomes, not just technical metrics.
3. Start small, then scale — Begin with a contained project to develop team capability and organisational confidence before expanding the programme.
4. Adapt the IT operating model — Restructure teams and processes to support both business agility (speed of delivery) and stability (reliability and security).
5. Be pragmatic in technology selection — Avoid chasing the newest tools. Choose technologies that fit the organisation’s existing skills and integration requirements.
6. Incubate a culture of innovation — Actively build an environment that rewards experimentation, cross-team collaboration, and learning from failure — prerequisites for effective DevOps practice.

Why This Research Still Matters for DevOps Teams

Although the specific adoption percentages are now historical data points, several findings from the Capgemini study remain directly relevant to DevOps engineering work:

• The correlation between integrated DevOps teams and cloud-native success (69% of leaders vs. 38% of laggards) reinforces that tooling alone does not drive outcomes — team structure and culture are equally important.
• The skills gap identified in 2017 has deepened rather than narrowed in many organisations, making workforce development a persistent priority.
• Legacy integration complexity continues to be a primary technical constraint on cloud-native adoption, particularly in banking and regulated industries.
• The framing of IT’s role — shifting from cost centre to growth enabler — is a cultural change that DevOps advocates still actively navigate within enterprises.

Methodology

Longitude Research surveyed 902 professionals on behalf of Capgemini. Respondents were evenly divided between IT and non-IT roles and were based in 11 countries across Europe, the Americas, and Australia. Sectors represented included banking, insurance, consumer products, retail and distribution, manufacturing, and high-tech. The survey focused on views about cloud-native software development and organisational progress in adopting it.

Original source: Economic Times CIO, reporting on Capgemini research, 2017.

What Is Continuous Delivery?

Continuous Delivery is a software engineering discipline in which teams build software in small, frequent increments and ensure that the codebase is always in a releasable state. Unlike a big-bang release cycle, CD keeps the path from code commit to production short, automated, and repeatable.

The core idea is straightforward: automate everything that can be automated—builds, tests, environment provisioning, and deployment—so that releasing software becomes a low-stress, on-demand activity rather than a high-risk event. CD differs from Continuous Deployment in one important way: a human still approves the final push to production, which gives teams control without sacrificing speed.

High-performing engineering organisations at companies such as Amazon, Google, Facebook, and Etsy have long practised variants of Continuous Delivery, shipping code to production many times per day. For developers at smaller organisations, demonstrating fluency with CD principles and tooling is increasingly a differentiator in hiring and promotion decisions.

How Continuous Delivery Advances a Developer’s Career

1. Position Yourself for the Best Projects

Junior and mid-level developers frequently find themselves stuck maintaining brittle deployment scripts, chasing environment approvals, or acting as a manual handoff point between development and operations. This kind of work is necessary, but it rarely leads to recognition or growth.

Continuous Delivery replaces those manual, error-prone steps with automated pipelines. When deployments no longer require a developer’s manual intervention, that developer is free to contribute to new features, architectural improvements, and the projects that get noticed. Mastering CD is therefore not just about doing your current job better—it is about creating space to do higher-value work.

2. Increase Day-to-Day Job Satisfaction

One of the most common sources of developer burnout is the weight of tedious, repetitive work: late-night deployments, emergency patches caused by infrequent large releases, and long waits for environment availability. Continuous Delivery directly reduces this friction.

• Fewer emergency deployments. Small, frequent releases mean each change is easier to test and roll back, so production incidents caused by large, unexpected changesets become less common.
• No more waiting on environment provisioning. Infrastructure-as-code and automated environment setup, both prerequisites of a mature CD pipeline, eliminate the bottleneck of requesting and waiting for test environments.
• Less approval overhead. Automated quality gates—unit tests, integration tests, security scans, performance benchmarks—replace slow, manual sign-off processes.
• Faster feedback loops. Code merged today can be in front of real users within hours, giving developers actionable feedback rather than speculation.
• More time for meaningful engineering work. When the mundane is automated, developers can focus on problem-solving, system design, and technical depth—the work most engineers entered the profession to do.

3. Build Better Products Through Validated Learning

Continuous Delivery makes it practical and economical to release in small batches and gather real user feedback at every step. This tight feedback loop fundamentally changes how products are built.

Techniques such as A/B testing and feature flags, which are much easier to implement with a CD pipeline already in place, allow teams to validate assumptions before committing to full feature development. Rather than building a complete feature over several months and discovering it does not deliver value, a team can ship a minimal version, measure its effect, and decide whether to invest further. This reduces wasted engineering effort and leads to products that users actually want.

For developers, this matters for career growth: being associated with products that succeed—and understanding why they succeed—is a much stronger career signal than shipping code into a void and hoping for the best.

4. Develop a Reputation for Innovation

Creativity in software engineering requires two things: the opportunity to work on forward-looking projects and the time to do so. Continuous Delivery creates both. By reducing the operational burden on developers, it frees cognitive bandwidth for experimentation and invention.

Beyond that, understanding CD principles—pipeline design, deployment strategies such as blue-green or canary releases, observability, and feedback mechanisms—signals to employers that a developer thinks in systems, not just in isolated tasks. This is precisely the profile that engineering managers look for when staffing ambitious projects or building out platform and DevOps teams.

Core Skills to Develop Alongside Continuous Delivery

To benefit fully from Continuous Delivery as a career practise, developers should build competence in the following areas:

• Automated testing. CD depends on a reliable, fast test suite. Unit, integration, and end-to-end testing skills are foundational.
• CI tooling. Familiarity with tools such as Jenkins, GitHub Actions, GitLab CI, or CircleCI is expected in most modern engineering roles.
• Infrastructure as Code. Tools such as Terraform, Ansible, or Pulumi allow environments to be version-controlled and provisioned automatically.
• Containerisation and orchestration. Docker and Kubernetes are now standard building blocks of CD pipelines.
• Observability. Logging, metrics, and distributed tracing skills help developers understand system behaviour after deployment and respond quickly when something goes wrong.
• Deployment strategies. Understanding blue-green deployments, canary releases, and feature flags allows teams to manage risk during rollouts.

Getting Started

If your team does not yet practise Continuous Delivery, the most practical entry point is improving your automated test coverage and setting up a basic CI pipeline that runs on every pull request. From there, add automated deployment to a staging environment, then progressively tighten feedback loops and reduce manual gates.

Even if your organisation is not ready to adopt CD fully, demonstrating that you understand the principles and can articulate their value—to your team, your manager, or a future employer—is itself a meaningful career asset. Continuous Delivery has moved from a competitive advantage to an industry expectation. Developers who are fluent in it are better positioned to do impactful work, earn recognition, and take on increasing levels of responsibility.