This article focuses on practical steps for bringing your marketing team into a DevOps state of mind—not by turning marketers into engineers, but by aligning their workflows and culture with DevOps principles.

Provide DevOps 101 Training to Marketing

Marketing professionals who have only supported products released under waterfall or other slow, stage-gated models may struggle to keep pace with the higher delivery velocity that DevOps enables. Features ship more frequently, roadmaps are more fluid, and the definition of “done” shifts constantly.

Providing foundational DevOps training to marketing staff is an important first step. The goal isn’t technical depth—it’s conceptual clarity. Marketers need to understand what continuous delivery means for their day-to-day responsibilities.

Consider a content marketing manager who is accustomed to writing a product overview only after the product is 100% feature-complete and ready to launch. In a DevOps environment, that model breaks down. Features may be released incrementally, documentation needs to evolve alongside the product, and launch timelines may be compressed significantly. Training helps marketers understand why their processes need to adapt—and gives them the vocabulary to participate in cross-functional conversations.

Useful topics for a DevOps 101 session aimed at marketing staff include:

• What continuous integration and continuous delivery (CI/CD) mean in practice
• How sprint cycles and agile planning affect release schedules
• What a minimum viable product (MVP) is and why products ship before they feel “finished”
• How to interpret a basic release roadmap or backlog
• Who to contact in engineering for feature information and release dates

Include Marketing in Your DevOps Cultural Transformation

DevOps cultural transformation is often discussed exclusively in terms of development, operations, and security teams. But for product and services companies, marketing is a critical part of the value delivery chain. Excluding them from the cultural shift creates silos that undermine the very collaboration DevOps is designed to foster.

Bringing marketing into the DevOps culture requires executive sponsorship from both technology and marketing leadership. Practically, it means rethinking how marketing and engineering interact across several dimensions:

• Shared accountability: Marketing should share in the collective responsibility for ensuring that what the organization ships meets customer expectations and is a genuine market fit. This is not just an engineering concern.
• Blameless culture: Marketing, development, and operations can naturally operate at cross-purposes. A DevOps culture discourages blame games. Mistakes and miscommunications should be treated as systemic issues to fix, not individual failures to punish.
• Mutual visibility: Marketing team members supporting a product need continuous insight into what developers are building and when. Equally, developers benefit from visibility into marketing messaging and campaign timelines. Surprises—whether a major feature that marketing missed or a campaign that engineers didn’t know was running—should become rare.
• Automation awareness: Automation is a core DevOps principle. Marketing counterparts should understand how automation affects the development cycle, even if they are not operating the pipelines themselves. This awareness helps marketers anticipate release timing and reduces ad hoc requests that disrupt engineering workflows.
• Collaborative artifacts: Activities such as user story development, product definitions, user documentation, and marketing collateral benefit from cross-functional input. In a DevOps culture, these are not handoffs from one team to another—they are collaborative outputs with shared ownership and tight scheduling alignment.

Put a DevOps Team Over Your Martech Stack

As marketing organizations move toward cloud-based platforms, marketing automation, and data-driven operations, the technology stack supporting those activities—commonly called the martech stack—grows in complexity. CRM systems, marketing automation platforms, content management systems, analytics tools, and advertising platforms all require configuration, integration, maintenance, and security oversight.

Applying DevOps practices to the martech stack is a logical extension of your broader DevOps journey. This means treating martech infrastructure with the same rigor applied to production software: version-controlled configurations, automated deployments, defined change management processes, and clear ownership.

In many organizations, the martech stack has grown organically outside of IT oversight—a common shadow IT pattern where marketing teams procure and manage tools independently. Bringing the martech stack under formal IT management, with a dedicated DevOps team or embedded engineers, can improve reliability, security posture, and integration quality. It also creates a natural bridge between engineering and marketing: shared tools, shared infrastructure conversations, and a clearer picture of how marketing systems interact with core product systems.

This shift is not always straightforward. Marketing teams that have operated independently may be protective of their tooling decisions, and IT teams may lack the bandwidth or domain knowledge to absorb new platforms. Executive alignment and a phased approach can help smooth the transition.

DevOps and Marketing: Stronger Together

DevOps and marketing may seem like an unlikely pairing, but the friction between them is largely a product of organizational silos, not fundamental incompatibility. Both disciplines are ultimately focused on delivering value to customers—one through software, the other through communication and positioning.

Bringing marketing into your DevOps culture pays dividends at the moments that matter most: product launches, go-to-market campaigns, and rapid response to market changes. When marketing understands how software is being built and delivered, and when engineers understand how their work is being positioned, both teams make better decisions faster.

Start with education, build shared visibility, establish collaborative practices, and consider where formal DevOps discipline can be applied to marketing’s own technical infrastructure. The result is a more cohesive organization—and a better experience for the customers you’re all working to serve.

Overview

Enterprise Strategy Group (ESG), working with Data Theorem — a provider of tools for securing APIs and mobile applications — surveyed 371 IT and cybersecurity professionals at North American organizations to assess the state of DevSecOps adoption. The results paint a picture of genuine momentum tempered by fragmented implementation, organizational silos, and tool sprawl.

Where DevSecOps Adoption Stands

Headline adoption figures look encouraging on the surface:

• 55% of respondents have already incorporated security into their DevOps processes.
• 22% plan to do so.
• 20% are still in the evaluation stage.

However, the survey reveals that adoption is uneven in practice. Only 33% of organizations involve cybersecurity teams at the start of the application development process — a foundational requirement for genuine shift-left security. And just 39% report that cybersecurity professionals are involved in more than half of their cloud-native application projects today, though that figure is projected to reach 78% within two years.

Coverage of actual applications is even more telling: only 8% of respondents are securing 75% or more of their cloud-native applications with DevSecOps practices right now. Within two years, 68% expect to reach that threshold — a dramatic projected shift that underscores both the ambition and the gap.

The Multi-Platform Security Challenge

One reason consistent DevSecOps is difficult to achieve is the diversity of platforms organizations already run. According to the survey, workloads are distributed across:

• Virtual machines: 34%
• Bare-metal servers: 28%
• Containers: 23%
• Serverless computing frameworks: 15%

Only 10% of organizations currently run more than half their workloads on public cloud, but that proportion is forecast to rise to 30% within two years.

This sprawl directly drives the top reported security challenges:

• Consistently managing cybersecurity across multiple platforms: 43%
• Cost and complexity of implementing controls across platforms: 35%
• Lack of understanding of threat vectors facing cloud-native applications: 35%

Container and Serverless Security Gaps

For teams working with containers, the survey identified two equally-cited top concerns:

• Aligning security controls with deployment models: 32%
• Verifying that images in registries meet compliance requirements: 32%

For serverless environments, API vulnerabilities were the most commonly cited concern at 32%. Budget allocations reflected these priorities closely: vulnerability scanning of registry-resident container images (26%) narrowly edged out API security tooling (25%) as the leading spend category.

Tool Sprawl and the Vendor Consolidation Dilemma

One of the more striking findings involves the tension between tool specialization and platform consolidation. The survey found:

• 73% believe their organization uses too many specialized products to secure cloud-native applications properly.
• 50% expect their organization to consolidate controls by procuring from a smaller set of vendors — or even a single vendor.
• Yet 59% still prefer disparate point controls to achieve more functionality, even if it means managing multiple tools across different compute types and locations.

This contradiction is common in security purchasing decisions: teams recognize the overhead of fragmented tooling but are reluctant to trade away functionality for simplicity. The most important product attributes cited by respondents were a rich set of pre-deployment capabilities, runtime security features, support across mixed server workload types, and flexible deployment options.

Organizational Structure: Still a Bottleneck

Perhaps the most fundamental barrier identified in the study is organizational design itself. 82% of respondents said their organization has different teams assigned to secure cloud-native applications. Among that group:

• 50% plan to merge these responsibilities in the future.
• 32% intend to keep them separate.

As ESG Senior Analyst and Group Director Doug Cahill noted, cybersecurity is increasingly being baked into applications rather than bolted on after the fact. But achieving that consistently at scale requires dismantling the team boundaries that still keep security downstream of development in most organizations.

Key Takeaways for DevOps and Security Teams

The ESG findings offer several actionable signals for teams navigating their own DevSecOps journey:

• Shift left early and formally. Involving security at the start of development — not just during testing or deployment — is still uncommon. If only a third of organizations do this today, there is real competitive differentiation available to those who do.
• Address the platform coverage gap. Having a DevSecOps process that applies to some pipelines but not others is a significant risk. Audit which workload types and deployment environments lack consistent security controls.
• Prioritize API security. Whether workloads run in containers or serverless environments, API vulnerabilities consistently surfaced as a top concern. Ensure API scanning is part of your CI/CD pipeline, not a post-release afterthought.
• Challenge your tooling assumptions. If your team recognizes tool sprawl as a problem but keeps acquiring point solutions, define explicit criteria for when a platform investment is more appropriate than another specialized tool.
• Plan the organizational change, not just the technical one. Merging security and development responsibilities requires governance decisions, training, and process redesign — not just new tooling.

Conclusion

The ESG/Data Theorem study confirms what many practitioners already sense: broad awareness of DevSecOps has not yet translated into consistent, organization-wide practice. The two-year projections — 78% cybersecurity team involvement in cloud-native projects, 68% securing 75% or more of applications — reflect strong intent, but intent and execution are very different things. The organizations that close the gap fastest will be those that treat DevSecOps as a structural and cultural change, not merely a tooling upgrade.

Why Cloud and DevOps Are Inseparable

Organisations moving to public cloud often treat it as a purely infrastructure decision. In practice, the technology shift is only half the story. Without a matching change in how teams work — how they collaborate, release, and operate software — the promised speed and agility of the cloud rarely materialises. That is where DevOps enters the picture.

Cloud platforms provide the raw capability: elastic compute, managed services, global reach, and pay-as-you-go economics. DevOps provides the culture, practices, and tooling to exploit that capability at pace. Together they allow engineering teams to release more frequently, recover from failures faster, and iterate on products in ways that on-premises infrastructure simply cannot match.

Whether an organisation is already running workloads in the cloud or is only beginning to explore the idea, the goal is the same: create a foundation for business innovation and then build on it continuously.

The Case for Adopting DevOps Alongside Cloud

Embracing public cloud is a necessary first step, but it is not sufficient on its own. Lifting and shifting existing workloads to virtual machines without changing deployment processes, team structures, or operational practices typically produces a more expensive version of the same problems that existed on-premises.

DevOps addresses this directly by:

• Eliminating repetitive manual tasks through automation of build, test, deployment, and infrastructure provisioning.
• Breaking down silos between development and operations teams, reducing the classic “it works on my machine” friction.
• Enabling rapid, safe release cycles so that teams can deploy often, catch defects early, and respond to market changes quickly.
• Creating a feedback culture where teams learn from production data and iterate collaboratively rather than working in isolation.

The cultural shift is often the hardest part. Integrating previously separate teams — and convincing key stakeholders that the short-term discomfort of change is worth the long-term competitive advantage — is consistently the biggest challenge practitioners report during DevOps transformations.

Do You Actually Need an In-House DevOps Team?

A common misconception is that every organisation needs a dedicated, in-house team of DevOps engineers. In reality, most small and mid-sized companies lack the scale or complexity to justify the cost of building and retaining that capability internally. Hiring senior DevOps and cloud engineers is expensive, competitive, and time-consuming.

An increasingly popular alternative is to partner with a specialist consultancy or managed service provider that already has proven frameworks, tooling, and experienced engineers. This lets product engineering teams focus on building the software that differentiates the business, while the operational and infrastructure concerns are handled by experts.

Critically, no two cloud or DevOps adoption journeys are identical. Each project must be approached on its own terms — factoring in the organisation’s existing technical debt, compliance requirements, budget, timescales, and risk appetite.

Four Stages of a Structured Cloud Adoption Journey

A well-structured cloud and DevOps engagement typically progresses through four interconnected stages. Each builds on the last and is designed to reduce risk while accelerating time-to-value.

1. Cloud Foundation

Before migrating workloads, organisations need a secure, well-governed base to build on — often called a cloud landing zone. This involves:

• Defining a public cloud strategy aligned to business objectives.
• Establishing an account and identity structure (for example, AWS Organizations, Azure Management Groups, or GCP folders).
• Implementing network topology, security controls, logging, and compliance guardrails.
• Automating the provisioning of the core infrastructure so it is repeatable and auditable.

Cloud workshops and structured consulting sessions are a practical way to answer the key questions early: which cloud provider fits the organisation’s needs, what governance model is required, and what the step-by-step adoption roadmap looks like.

2. Cloud Migration

Migration is typically the highest-risk phase of a cloud journey. Business continuity must be maintained throughout, and the costs and risks of a poorly planned migration can be significant. A structured approach helps mitigate these risks.

A robust migration process generally covers:

• Discovery and dependency mapping — understanding what exists, what talks to what, and what the migration order should be.
• Assessment and prioritisation — categorising workloads by migration strategy (rehost, replatform, refactor, retire, or retain).
• Governance and security validation — ensuring the cloud foundation is ready to receive workloads.
• Pilot migration — migrating a low-risk workload first to validate tooling and processes.
• Wave-based migration execution — moving workloads in controlled batches.
• Testing and validation — confirming that migrated workloads behave correctly in the new environment.
• Cutover and decommission — switching traffic, monitoring closely, and retiring legacy infrastructure.

Proven tooling and documented runbooks are essential to keeping migrations predictable and reversible.

3. Managed CloudOps

Once production workloads are running in the cloud, ongoing operations, monitoring, cost optimisation, and incident response become critical. For many organisations, managing this continuously is neither their core competency nor the best use of engineering time.

Managed CloudOps services provide:

• 24/7 monitoring and alerting tailored to the organisation’s specific infrastructure.
• Incident response and on-call coverage.
• Regular security patching, compliance auditing, and cost reviews.
• Continuous optimisation of resource utilisation and cloud spend.

The goal is to free internal product teams from operational toil so they can focus on delivering features and value to end users.

4. Managed DevOps

A DevOps transformation is not a one-time project — it is an ongoing change programme aligned to business objectives. A managed DevOps engagement typically covers:

• Building or improving CI/CD pipelines for automated build, test, and deployment.
• Implementing infrastructure-as-code (IaC) using tools such as Terraform, Pulumi, or AWS CloudFormation.
• Automating environment provisioning and configuration management.
• Establishing observability practices: logging, metrics, tracing, and dashboards.
• Coaching and upskilling internal teams to sustain the transformation independently over time.

Automation of orchestration and provisioning is central to accelerating time-to-value and reducing the manual overhead that slows delivery teams down.

Security, Compliance, and Governance Cannot Be Afterthoughts

A recurring theme in cloud adoption failures is the treatment of security and compliance as a late-stage concern. Regulated industries in particular — financial services, healthcare, and the public sector — must satisfy strict requirements around data residency, access control, audit trails, and change management.

Embedding these controls into the cloud foundation from day one — rather than retrofitting them later — is significantly cheaper and less disruptive. Policy-as-code tools (such as AWS Service Control Policies, Azure Policy, or OPA/Conftest for Kubernetes environments) allow governance rules to be defined once and enforced automatically across the entire cloud estate.

You Don’t Own the Infrastructure — So Stop Acting Like You Do

One of the most clarifying realisations for organisations moving to public cloud is that the underlying infrastructure — the physical data centres, the hardware, the global network — belongs to Amazon Web Services, Microsoft Azure, or Google Cloud Platform. The organisation owns its data and its product, not the servers.

This changes the calculus around in-house operations teams significantly. Building a team whose primary job is to manage infrastructure you do not own, using skills that are expensive to hire and hard to retain, is often a poor allocation of resources. Partnering with specialists who live and breathe cloud operations — and letting internal engineers focus on the product — is increasingly the smarter choice for companies that are not cloud platforms themselves.

Key Takeaways

• Cloud adoption without a corresponding DevOps culture change rarely delivers the expected speed and agility.
• Every organisation’s cloud journey is different — a framework must be tailored to individual requirements, timescales, and budgets.
• A structured four-stage approach (Foundation → Migration → CloudOps → DevOps) reduces risk and accelerates value delivery.
• Security and compliance controls should be built into the cloud foundation from the start, not added later.
• Most organisations do not need a full in-house DevOps and cloud operations team — a trusted managed service partner is often more cost-effective.
• Focus engineering effort on what the business owns: the product. Let specialists manage the infrastructure.

What Is DevOps in the Cloud?

Both DevOps and cloud computing are widely cited as essential to maintaining competitiveness and pursuing digital transformation. While DevOps focuses on improving collaboration, processes, and software delivery pipelines, cloud computing provides the underlying on-demand infrastructure and services those pipelines run on. Combining the two creates an environment where development and operations teams can move faster, experiment more freely, and deliver higher-quality software.

How Cloud DevOps Differs from On-Premises DevOps

On-premises DevOps is constrained by physical boundaries: fixed compute capacity, shared infrastructure, and a narrower choice of technologies. Cloud-based DevOps removes many of those constraints.

Mark Debney, head of DevOps at tech consultancy 6point6, explains it this way: “It also allows us to expand our view wider than just the servers or load balancers. In a cloud-based environment we can view our complete stack from top-level network elements down to a single package installed on a server as a discrete entity, all of which we can create, destroy, copy and modify with a simple click.”

Cloud-native DevOps also accelerates two foundational DevOps ideals:

• Everything as Code (EaC): Infrastructure, configuration, policies, and pipelines are all defined in version-controlled code files, making them reproducible and auditable.
• Immutable Infrastructure: Rather than patching running servers, new deployments replace old ones entirely, reducing configuration drift and increasing consistency.

Cloud platforms also connect teams to a broader ecosystem. As Debney notes: “We can leverage tools and ideas within the wider cloud community. We are no longer tied to our own internal set of infrastructure technology with its own unique quirks.”

Key Benefits of Combining DevOps and Cloud

Programmable, API-Driven Infrastructure

Public cloud platforms expose their capabilities through well-documented APIs. Tim Hynes, DevOps engineer at Rubrik, points out that this makes cloud a naturally programmable environment: “This enables us to take a modern, scalable approach to building applications and provides levels of flexibility and opportunity that are not available in traditional environments.” Because APIs are universally available across cloud services, automation becomes straightforward where it would otherwise require custom integration work.

Lower Capital Expenditure on Tooling

Richard Slater, principal consultant at Amido, argues that the financial model of cloud directly reduces one of the biggest barriers to DevOps adoption: upfront tooling costs.

“You need to invest in DevOps upfront to see a medium-to-long-term result… By adopting DevOps in the cloud, you can reduce the capital expenditure on DevOps tools by simply renting SaaS tools from the market – for example Datadog, Splunk, AppDynamics, New Relic, JIRA, Bamboo and CircleCI.”

Subscribing to SaaS-based tooling also shifts maintenance and upgrades to vendors, freeing engineering teams to focus on delivery rather than tool management.

Greater Flexibility and Scale

Cloud elasticity means teams can rapidly scale existing components for load testing, spin up parallel environments for feature branches, and tear down resources when they are no longer needed. This opens the door to testing and release strategies — such as blue/green deployments, canary releases, and chaos engineering — that are difficult or expensive to replicate on fixed on-premises hardware.

Making Cloud DevOps Adoption Succeed

Build Trust with Development Teams

Slater identifies a lack of organisational trust as one of the primary reasons agile and DevOps transformations fail: “Organisations wanting to adopt Agile, Cloud and DevOps must start to give trust to the individuals making decisions and writing code on the ground. To a certain extent this trust must be earned, but in many of today’s enterprises there is so much governance around technical delivery that it has the effect of slamming the brakes on any transformation.”

This does not mean abandoning governance entirely, but rather distinguishing between controls that genuinely reduce risk and bureaucratic processes that slow delivery without adding value.

Scale Adoption Gradually — No More Than 3x at a Time

Slater recommends a deliberate, incremental approach to expanding cloud DevOps across the organisation: “If you started with one project, next try another three projects, then nine and so on. Aim for the projects that deliver the most business value in the shortest time. Once you have ten projects under your belt, start looking at tackling some of the harder problems — these will be a lot easier now you have a critical mass of products, vendor agreements, suppliers, processes and people behind you.”

Scaling by a maximum factor of three at each step gives teams time to consolidate learnings before the next wave of expansion, reducing the risk of organisational overload.

Cloud DevOps Best Practices

1. End-to-End Traceability

Iskandar Najmuddin, specialist architect at Rackspace, identifies end-to-end traceability as a foundational DevOps practice for cloud environments. Traceability means being able to follow any change — from the initial commit that triggered it to the running workload it produced — so that bugs, incidents, and vulnerabilities can be investigated quickly.

“No one tool can solve this – as you build a pipeline of changes, the key is to ensure that the business injects metadata into it to help trace the steps.”

In practice, this means propagating a correlation ID or build reference through every stage of your CI/CD pipeline — from source control, through build artefacts, container images, deployment manifests, and into runtime logs and monitoring dashboards.

2. Shift Left on Testing and Security

Najmuddin describes Shift Left as the practice of finding and fixing defects, vulnerabilities, and misconfigurations as early in the development lifecycle as possible, rather than discovering them in production where remediation is most costly.

“Development is done on the left hand, and production is on the right. Businesses must identify and fix the problems on the left before they transition toward the right. This affects how businesses plan, design, write and apply code, as well as how they introduce any changes into the environment.”

Practically, Shift Left involves integrating automated unit tests, static code analysis, dependency vulnerability scanning, and infrastructure-as-code linting directly into pull request checks and build pipelines — so problems surface within minutes rather than weeks.

3. Keep Applications Small and Independently Deployable

Sasan Padidar, director of engineering and container security at Tenable, advocates for decomposing applications into small, independently deployable components: “Independent components of the application can be scaled separately. It also means that pieces of an application can be deployed faster because of the reduced complexity of the overall application.”

Padidar also recommends packaging all dependencies with each application at build time: “This means that applications are immutable units that can be deployed anywhere.” Container images are the dominant mechanism for achieving this today, but the principle applies equally to other packaging formats such as virtual machine images or self-contained binaries.

The Road Ahead: Containers, Orchestration, and Evolving Roles

Najmuddin anticipated growing adoption of containers alongside a consolidation of the container orchestration landscape — a prediction that has largely played out, with Kubernetes becoming the dominant platform across public cloud providers.

He also predicted that the “DevOps engineer” as a distinct job title would evolve: “The idea that DevOps is a distinct job or role in an organisation will also start to tail off. DevOps will become the default way to manage cloud environments, and the job titles will evolve to reflect this.”

Roles such as Site Reliability Engineer (SRE), Platform Engineer, and Cloud Engineer have emerged as common titles that embed DevOps principles without labelling them as such — consistent with this direction of travel.

Summary