In the beginning, there was “Dev” and there was “Ops.” Now, the term “DevOps” has taken its place in the tech lexicon, and the combination symbolizes how developers and IT operations have blended into one unit.

What propelled DevOps to the forefront of organizational focus was a desire to drive both productivity and software growth. Rather than serve as an obstacle to success, operations teams have sought ways to facilitate the developers’ agile mantra. Now the challenge will be to marry development with the business side to achieve full alignment.

“We’ve seen how DevOps practices have minimized or even eliminated finger pointing between ‘Dev’ and ‘Ops’ teams,” said Dave Vellante, chief analyst at SiliconANGLE Media’s sister market research firm Wikibon and host of SiliconANGLE’s livestreaming video studio theCUBE. “People are now taking the next step and aligning software development with product development. This is critical, as in the coming decade, virtually every company will have a software element to its product roadmap.”

During its coverage of the DevOps Virtual Forum on November 18, theCUBE will focus on emerging trends in the DevOps world. The event will include interviews with top executives from Broadcom Inc., Forrester Research Inc. and British Telecom Group PLC, with a focus on new capabilities in agile management, how organizations are pushing the envelope through the integration of product development and DevOps, and the use of cutting-edge automation tools to maximize value and efficiency. (* Disclosure below.)

Physical to ‘spiritual’ colocation
The end of February will mark a milestone that no one could have foreseen. It will be the approximate one-year anniversary of when a global pandemic transformed businesses around the globe, forcing entire organizations to work remotely.

This sudden forcing function has fueled virtual collaboration and a reorientation from a physical workspace to one where laptop cameras and video conference technology have become the tools of daily use. Enterprises have been forced to move on from physical spaces to “spiritual” colocation, a transition that was not always easy.

“You can’t do that without having an even higher attention to automation and DevOps practices that enable it, but there’s also an increased focus on enabling digital collaboration,” said Jeffrey Hammond, vice president and principal analyst at Forrester, during a recent interview with theCUBE. “In 2020, every company is a remote development company.”

For developers, the transition may have its challenges, but two recent studies have found that the development community is thriving. The Harness “2020 State of Developer Satisfaction” report issued in August found that over half of responding developers were happier in their roles since COVID-19 disrupted the world and 94% were overwhelmingly satisfied with their companies’ investment in employee growth.

A GitHub report issued in May documented that while development activity has not been without disruption, the activity of developer-generated pushes and pull requests has actually increased year-over-year. Developers appear to be keeping pace.

There remain key challenges for many organizations, particularly in the cultural alignment between DevOps and the product cycle. Does the development cycle match the product timetable? Not always.

In October, the BizOps Coalition released a Manifesto that outlined a framework to bridge the gap between tech investment in DevOps and business outcomes. By connecting software development with the goals of a business and leveraging critical tools such as AI, organizations hope to spark a cultural change that will eliminate wasted productivity and money.

“When we think about the major impediments for DevOps implementation, it’s all about culture,” said Serge Lucio, general manager of the Enterprise Software Division at Broadcom, during a recent interview with theCUBE. “It’s about who can do what and when and driving a bias toward action. There’s a great role that technology and AI can provide for a new level of collaboration.”

Guests who will be interviewed on theCUBE during the DevOps Virtual Forum include Jeffrey Hammond, vice president and principal analyst at Forrester; Serge Lucio, general manager of the Enterprise Software Division at Broadcom; and Glyn Martin, head of QA transformation at BT.

Implications of Application Interconnectivity

Modern businesses increasingly compete on the strength of their digital experience. That experience rarely comes from a single application. Instead, it is assembled from dozens of interconnected services — APIs, mobile apps, web front-ends, SaaS integrations, data pipelines, and back-end microservices — each owned by different teams, built on different technology stacks, and deployed to different environments.

For the end user, this complexity is invisible. They expect one seamless, always-on experience. For operations teams, however, this interconnectivity creates a significant reliability challenge: every service boundary is a potential point of failure, and a degraded dependency in one system can cascade silently across the entire user journey.

The Operations Responsibility

DevOps emerged to close the gap between development and operations teams, and many of its foundational practices originated on the development side: Agile methodology, code review standards, build automation, and continuous integration. These were developer-led responses to developer-identified problems.

Yet the real business value of software is only realised once code reaches production and is in the hands of end users. That means the greatest return on investment from DevOps practices lies in the operational half of the pipeline — in stability, observability, safe deployments, and reliable rollbacks.

This observation motivates a reframing of the DevOps conversation: instead of starting from development and working toward operations, what if teams started from operational requirements and worked backward into the design and development process?

That reframing has a name: OpsDev.

What OpsDev Actually Means

OpsDev is not a rejection of DevOps. It is a shift in emphasis — specifically, the practice of front-loading operational considerations into the earliest stages of application design and development.

In an OpsDev approach, questions that are traditionally deferred to the end of the delivery cycle are asked at the beginning:

• How will this application be monitored in production?
• How will it scale under peak load?
• What are the security and compliance requirements, and how are they enforced automatically?
• How will it be migrated if the underlying infrastructure changes?
• What are the dependencies between application components, and in what order must they be deployed?

Addressing these questions upfront — rather than retrofitting answers after code has been written — leads to better-designed software and a far smoother path to production.

Equally important is treating the delivery pipeline itself as a first-class product artifact. The toolchain, automated tests, deployment scripts, and environment configurations that move code from commit to production are designed and built in parallel with the application — not bolted on afterward.

First Pants, Then Shoes: Getting the Order Right

A common failure mode in traditional software delivery is that infrastructure and operational concerns are treated as someone else’s problem until it is too late. The result is code that passes QA in a staging environment but fails in production due to configuration drift, unmodeled dependencies, or untested failure scenarios.

OpsDev prescribes a specific order of operations:

1. Model dependencies first. Before writing application code, map and document the relationships between all application components. Understand what depends on what, and in what order systems must start, stop, or scale.
2. Model the target environments. Define the production infrastructure — including networking, security boundaries, compliance controls, and environment-specific configurations — before development begins. Application components can start as stubs; the environment scaffolding should not.
3. Automate the deployment processes. Build the scripts, pipelines, and runbooks that will deploy each component to each environment. Automate as much as possible so that the same process used in development can be promoted through staging and into production without manual intervention.

When these steps are in place before significant development work begins, development and test teams can run their work inside environment models that accurately reflect production. They become aware of production constraints early and write code accordingly. The result is far fewer surprises at release time.

The Release Pipeline as an OpsDev Cornerstone

A well-designed release pipeline is the operational backbone of the OpsDev approach. Unlike a simple CI/CD pipeline that builds and tests a single service, a release pipeline orchestrates the coordinated deployment of multiple application components — produced by different teams — across dev, test, staging, and production environments.

Key characteristics of a mature release pipeline in an OpsDev model include:

• Aggregation of commit pipelines. Individual CI pipelines (one per service or component) feed into a release pipeline that understands how those components relate to each other.
• Dependency-aware deployment sequencing. The pipeline deploys components in the correct order based on their interdependencies, rather than leaving that coordination to humans.
• Approval gates. Both manual and automated gates can be inserted at key promotion points — for example, requiring a change advisory board sign-off before a production deployment, or requiring a security scan to pass before promoting to staging.
• Parallelization. Where components can be deployed independently, the pipeline runs those deployments in parallel, reducing total release time.
• Artifact and configuration fidelity. The same artifact that was tested in staging is deployed to production — no rebuilds, no manual configuration changes — reducing the risk of configuration drift.

ITSM and APM Integration

An OpsDev release pipeline does not operate in isolation. It integrates with the broader operational toolchain that enterprises already rely on.

ITSM (IT Service Management) integration allows the pipeline to:

• Automatically open and close change records as deployments progress through environments.
• Request approval from a change management system before executing a production deployment.
• Record deployment events in an auditable log for compliance purposes.

APM (Application Performance Monitoring) integration allows the pipeline to:

• Automatically trigger performance and load tests immediately after a deployment completes.
• Receive signals from monitoring tools and act on them — for example, triggering an automatic rollback if error rates spike after a deployment, or initiating auto-scaling in response to load metrics.
• Use post-deployment health checks as automated approval gates before promoting a release to the next environment.

This bidirectional integration between the release pipeline and operational tooling is what distinguishes a mature OpsDev implementation from a basic CI/CD setup.

Final Thoughts: The Case for an Ops-First Mindset

The argument for OpsDev is straightforward: in a world where digital services are deeply interconnected and business outcomes depend directly on application uptime and performance, operations cannot be an afterthought. Reliability, security, scalability, and observability must be designed in — not bolted on.

Encouraging developers to think Ops-first does not mean slowing down development. On the contrary, teams that invest in environment modeling, deployment automation, and integrated pipelines early in a project consistently experience fewer production incidents, shorter release cycles, and less time spent firefighting. The upfront investment pays back quickly and compounds over the lifetime of the application.

Whether you call it OpsDev, platform engineering, or simply mature DevOps practice, the core principle is the same: begin with production in mind.

We call it DevOps but much of the time there’s a lot more discussion about the needs and concerns of developers than there is about other groups.

There’s a focus on improved and less isolated developer workflows. There are many discussions around collaboration, continuous integration and delivery, issue tracking, source code control, code review, IDEs, and xPaaS – and all the tools that enable those things. Changes in developer practices may come up – such as developers taking ownership of code and pulling pager duty.

We also talk about culture a great deal in the context of developers and DevOps. About touchy-feely topics like empathy, trust, learning, cooperation, and responsibility. It can all be a bit kumbaya.

What about the Ops in DevOps? Or, really, about the other constituencies who should be part of the DevOps process, workflow, and even culture? Indeed, DevSecOps is gaining some traction as a term. DevOps purists may chafe at “DevSecOps” given that security and other important practices are supposed to already be an integral part of routine DevOps workflows. But the reality is that security often gets more lip service than thoughtful and systematic integration.

But what’s really going on here is that we need to get away from thinking about Ops-as-usual (or Security-as-usual) in the DevOps context at all. This is really what Adrian Cockcroft was getting at with the NoOps term; he didn’t coin it but his post about NoOps while he was at Netflix kicked off something of an online kerfuffle. Netflix is something of a special case because they are so all-in on Amazon Web Services, but Adrian was getting at something that’s more broadly applicable. Namely that, in evolved or mature DevOps, a lot of what Ops does is put core services in place and get out of the way.

Ironically, this runs somewhat counter to the initial image of breaking down the wall between Dev and Ops. Yes, DevOps does involve greater transparency, collaboration, and so forth to break down siloed behaviors but there’s perhaps an even stronger element of putting infrastructure, processes, and tools in place so that Devs doesn’t need to interact with Ops as much while being (even more) effective. One of the analogies I like to use is that I don’t want to streamline my interactions with a bank teller. For routine and even not so routine transactions, I just want to use an ATM or even my smartphone.

It’s up to Ops to build and operate the infrastructure supporting those streamlined transactions. Provide core services through a modern container platform. Enable effective automated developer workflows. Mitigate risk and automate security. But largely stay behind the scenes. Of course, you still want to have good communication flows between developers and operations teams; you just want to make those communications unnecessary much of the time.

(At the same time, it’s important for Dev and Ops teams to understand how they can mutually benefit by using appropriate container management and other toolchains. There’s still too much of a tendency by both groups to think of something as an “ops tool” or a “dev tool.” But that’s a topic for another day.)

Modern container platform

A DevOps approach can be applied just about anywhere. But optimizing the process and optimizing cloud-native applications is best done on a modern platform. Take it as read that most IT is going to be brownfield and DevOps may even be a good bridge between existing systems, applications, and development processes and new ones. But here I’m focusing on what’s optimized for new apps and new approaches.

You need scale-out architectures to meet highly elastic service requirements. Application designs with significant scale-up components simply aren’t able to accommodate shifting capacity needs.

Everything is software-defined because software functions, such as network function virtualization and software-defined storage, are much more flexible than when the same functions are embedded in hardware.

The focus is on applications composed of loosely-coupled services because large monolithic applications can be fragile and can’t be updated quickly.

A modern container platform enables lightweight iterative software development and deployment in part because modern applications are often short-lived and require frequent refreshes and replacements.

As I wrote about in The State of Platform-as-a-Service 2016, a PaaS like Red Hat’s OpenShift has evolved to be this modern container platform, embracing and integrating docker-format containers, kubernetes for orchestration and using Red Hat CloudForms (based on the ManageIQ upstream project) for open source hybrid cloud management.

Automated developer workflows

When thinking about the toolchain associated with DevOps, a good place to start is the automation of the continuous integration/continuous delivery (CICD) pipeline. The end goal is to make automation pervasive and consistent using a common language across both classic and cloud-native IT. For example, Ansible allows configurations to be expressed as “playbooks” in a data format that can be read by both humans and machines. This makes them easy to audit with other programs, and easy for nondevelopers to read and understand.

A typical automated workflow begins with operations provisioning a containerized development environment, whether a PaaS or more customized environment. This provides an example of how a mature DevOps process separates operations and developer concerns; by providing developers with a dynamic self-service environment, operations can focus on deploying and running stable, scalable infrastructure while developers focus on writing code.

Automation then ensures that the application can be repeatedly deployed. Many different types of tools are integrated into the DevOps workflow at this point. For example:

• Code repositories, like Git
• Container development tools to convert code in a repository into a portable containerized image that includes any required dependencies
• Vagrant for creating and configuring lightweight, reproducible, and portable development environments¥IDEs like Eclipse
• CICD software like Jenkins

Mature DevOps systems may even push the code directly to production once it has passed automated testing. But this isn’t about removing Ops from its role of ensuring stable and robust production systems. Rather, it’s about automating the processes to ensure that deployed code meets set criteria without ops needing to be directly involved with each deployment.

Mitigate risk and automate security

Ops is also ultimately chartered with protecting the business. This doesn’t mean eliminating all risk – which can’t be done. But it does mean mitigating risk which is accomplished in part by managing the software supply chain and by automating away sources of manual error.

That’s not to say that security is purely an ops concern – hence the aforementioned DevSecOps term. Creating a mindset in which everyone is responsible for security is key as is the practice of building security into development processes. Security must change from a defensive to an offensive posture that is both automated and constant.

Among the practices to be followed in such a proactive environment are:

• Components built from source code using a secure, stable, reproducible build environment
• Careful selection, configuration, and security tracking of packages
• Automated analysis and enforcement of security practices
• Active participation in upstream and community involvement
• Thoroughly validated vulnerability management process

I think this quote from Gartner captures the required dynamic well: “Our goal as information security architects must be to automatically incorporate security controls without manual configuration throughout this cycle in a way that is as transparent as possible to DevOps teams and doesn’t impede DevOps agility, but fulfills our legal and regulatory compliance requirements as well as manages risk.”

Why Front-End Performance Matters in SaaS

Engineering teams at SaaS companies have traditionally invested heavily in back-end optimization — scaling databases, tuning APIs, and improving infrastructure reliability. Many have robust monitoring and alerting in place for server-side issues. However, the front-end is often a blind spot.

Here is the core problem: if the front-end of your web application is slow, it does not matter how performant your database is. Users never interact directly with your database — they interact with the browser. A slow rendering pipeline, bloated JavaScript bundles, or unoptimized assets create a user experience (UX) bottleneck that no amount of back-end tuning can fix.

A common misconception in SaaS is that front-end performance only matters for acquisition. The reasoning goes: “Our users are already paying customers on annual contracts — they’re not going anywhere.” This assumption is dangerous for several reasons:

• Slow web apps interrupt user workflows and create frustration that accumulates over time.
• Frustrated users submit more support tickets, increasing operational costs.
• Users complain publicly — on social media, in user communities, and on software review platforms.
• Poor UX directly influences renewal decisions and word-of-mouth referrals at contract review time.

UX is not just a marketing concern. It is a retention and revenue concern, and front-end performance is a foundational part of UX.

Performance Optimization for DevOps Teams

Key Questions to Ask About Front-End Performance

When evaluating front-end performance for a SaaS web application, DevOps teams should be asking questions such as:

• How long does it take for users to log in and see their initial dashboard?
• Are third-party behavioral analytics scripts adding measurable latency to page loads?
• Are externally managed APIs introducing unpredictable latency into the application?
• How quickly can users navigate between different sections of the application?
• Can users generate and render reports without noticeable delays?
• Do billing and upgrade flows complete quickly and without errors?

Synthetic monitoring — also called proactive or outside-in monitoring — is an effective approach for answering these questions. By scripting key user flows and running them continuously, teams can establish baseline response times, receive alerts when thresholds are breached, and detect regressions before real users are impacted.

Integrating Performance Checks into the CI/CD Pipeline

Monitoring catches performance problems after they reach an environment. A more proactive approach is to prevent performance regressions from being released in the first place by integrating performance analysis directly into the build pipeline.

Performance optimization tools that integrate with continuous integration (CI) platforms such as Jenkins can be configured to fail a build when a performance rule is violated. Teams can define their own thresholds and best-practice rules, so only the checks that matter to their specific application are enforced. This gives teams a configurable, automated performance gate — a fail-safe that catches issues at the point of code merge rather than in production.

Example Scenario: Icon Assets and a Production Incident

Consider the following scenario, which illustrates the value of pre-release performance checking:

Without optimization tooling in the pipeline: Your team ships a UI update that includes a new set of custom icons. QA validates cross-browser rendering. UX research confirms users respond positively. You deploy to production. Within hours, you notice that dashboard load time has increased. You pull waterfall charts, compare before-and-after, and start diagnosing. Meanwhile, Operations flags that SLA thresholds may be breached if the issue isn’t resolved within the hour. You roll back the release. After further investigation, you discover the new icons are four times larger in file size than the previous set. You optimize, create a hotfix, and re-release. The entire incident consumed hours of engineering time and created unnecessary operational risk.

With optimization tooling integrated into staging: You merge the icon update into your staging branch. The build fails automatically. The optimization tool flags that the new icon assets are four times larger than the previous set and surfaces specific recommendations for reducing their size. You optimize the assets before the code ever reaches production. The release goes out on schedule. Dashboard load times remain stable — or improve slightly. No incident. No rollback. No fire drill.

The goal of integrating performance tooling into the DevOps workflow is straightforward: find performance issues earlier, when they are cheaper and less disruptive to fix.

Performance Optimization for Business Teams

The Performance Stakes on Marketing Sites

Nearly every SaaS company relies on a marketing website to support the sales and buying process. These sites tend to be content-heavy — rich with images, video, and a significant payload of third-party tracking and analytics scripts. Those scripts serve a legitimate purpose: they capture behavioral data that helps teams personalize content and optimize conversion funnels. But they carry a real performance cost.

Business teams managing marketing sites should keep in mind that the marketing site is a prospect’s first direct experience with the product. Performance and UX on that site shape expectations about the web application itself. A slow, unreliable marketing website signals to prospective customers that the product may also be slow and unreliable — even if that assumption is unfair.

Key Questions for Business Teams

• Are unoptimized images or videos contributing to slow initial page loads, and is that correlated with a high bounce rate?
• Are there unused or redundant third-party tracking scripts still loading on pages where they serve no purpose?
• What are the critical conversion paths on the site — free trial signups, demo requests, contact forms — and do those flows complete quickly and without errors?

Example Scenario: Homepage Video and Conversion Testing

Consider a common question that marketing teams face: should the homepage include a product video? Video can increase engagement and communicate product value quickly, but it can also add significant page weight.

A reactive approach: You add the video to the homepage and run an A/B test against the version without it. The test runs for several weeks. You eventually determine that the video adds two seconds to page load time and that this latency is associated with a measurable drop in conversions. You remove the video and start over. The test cost you time, traffic, and potential revenue during the experiment period.

A proactive approach using staging analysis: Before changing the live site, you and your development team deploy the video version to a staging environment and run performance analysis against it. You confirm the two-second load time increase before any real visitors are affected. Based on that data, you explore alternatives — for example, SVG animations or CSS-based motion — that achieve a similar visual impact without the payload cost. You validate the new approach in staging, confirm it performs well, then release it to production. Conversion rates improve. No traffic was wasted on a suboptimal experiment.

This approach requires collaboration between business and development teams, but it produces better outcomes than reactive A/B testing alone.

Building a Performance Culture Across the Organization

Performance optimization tools provide value even when used in isolation by a single team. But the most effective SaaS organizations go further by building a shared performance culture across both technical and business functions. This means:

• Aligning on shared KPIs: Agree on the performance metrics that matter most — load time, time to interactive, error rates, conversion rate — and make them visible to all stakeholders.
• Collaborating on strategy: DevOps and business teams should work together to prioritize performance work that has measurable business impact, not just technical elegance.
• Sharing tooling and data: Common dashboards and reporting give every team visibility into performance health, reducing the risk of siloed decisions that inadvertently hurt performance.

When performance is treated as a cross-functional concern rather than a DevOps-only problem, organizations are better positioned to deliver consistently fast, reliable experiences — both to prospects on the marketing site and to paying customers inside the application.

Key Takeaways

• Front-end performance affects UX for paying SaaS customers, not just for prospects. Slow web apps drive support costs, churn risk, and negative word-of-mouth.
• Integrating performance analysis into CI/CD pipelines allows teams to catch regressions before they reach production, reducing the cost and impact of performance incidents.
• Marketing websites are part of the product experience. Poor performance on the marketing site shapes prospect perception of the application itself.
• Proactive performance testing in staging environments gives business teams data to make smarter decisions without exposing real users to degraded experiences.
• Cross-functional alignment on performance KPIs, strategy, and tooling produces better outcomes than siloed optimization efforts.