Despite its well-documented benefits, many organisations treat DevOps adoption as a burden rather than an opportunity. Implementation is rarely straightforward, and the challenges are real. Understanding those challenges before you begin is the first step toward overcoming them.

“DevOps is not a goal, but a never-ending process of continual improvement.”

— Jez Humble, co-author of Continuous Delivery

What Is DevOps?

DevOps emerged from the recognition that traditional software delivery models — where developers write code and then “throw it over the wall” to operations to deploy and maintain — produce slow release cycles, poor quality, and organisational friction. By breaking down those silos, DevOps teams can:

• Release software more frequently and with greater confidence
• Detect and resolve defects faster through continuous testing and monitoring
• Share responsibility for both delivery speed and system reliability
• Build a feedback culture that drives continuous improvement

DevOps is closely associated with practices such as continuous integration (CI), continuous delivery (CD), infrastructure as code (IaC), automated testing, and blameless post-mortems. Tools like Git, Jenkins, Docker, Kubernetes, Terraform, and Prometheus are commonly used to operationalise these practices — but the tools are secondary to the cultural and organisational changes required.

Common DevOps Implementation Challenges

Organisations of every size encounter obstacles when adopting DevOps. The following are the most frequently cited challenges, along with practical guidance on how to address each one.

1. The Development vs. Operations Divide

The foundational tension in any DevOps adoption is the historical gap between developers and operations engineers. Developers are incentivised to ship new features quickly and are comfortable with change. Operations teams are incentivised to keep systems stable and are wary of untested deployments. These differing objectives — and the mutual distrust that often accompanies them — are the root cause of many delivery failures.

DevOps does not ask either team to abandon its expertise. Instead, it asks both to share accountability for outcomes. Practically, this means:

• Developers taking responsibility for the operability of their code (logging, alerting, runbooks)
• Operations engineers participating in sprint planning and design reviews
• Joint on-call rotations that give developers visibility into production behaviour
• Shared dashboards and metrics that make system health transparent to everyone

2. Cultural Change

DevOps is, before anything else, a cultural shift. It requires people to collaborate across boundaries they may have spent years maintaining, to accept blame-free retrospectives, and to trust colleagues from different disciplines. This is often harder than adopting any new tool or pipeline.

Cultural change cannot be mandated from above and completed in a quarter. Effective approaches include:

• Starting small: Identify a willing pilot team and build visible success before rolling out more broadly.
• Growing internal champions: Individuals who have experienced DevOps benefits firsthand are far more persuasive than external consultants or management mandates.
• Investing in training: Skills gaps in CI/CD pipelines, cloud infrastructure, or automated testing will undermine even the most enthusiastic teams.
• Celebrating learning from failure: Blameless post-mortems signal that the organisation values improvement over punishment.

3. Toolchain Complexity

The DevOps ecosystem offers a vast and growing selection of open-source and commercial tools. While this is ultimately an advantage, it creates a real challenge during adoption: teams can easily become overwhelmed by tool choices, or accumulate tools that overlap in function and create integration headaches.

More dangerous than choosing the wrong tool is deploying a tool nobody has been trained to use. An untrained team using a CI/CD platform incorrectly can introduce security vulnerabilities, break deployment pipelines, or create infrastructure drift. Key principles for toolchain decisions:

• Prioritise tools your team can actually use and support, not just the most popular options.
• Standardise on a core toolchain before expanding it.
• Treat tool training as a mandatory investment, not an optional extra.
• Evaluate security implications — particularly around secrets management, access controls, and supply chain integrity — before adoption.

4. Legacy Systems and Technical Debt

Many organisations carry significant legacy infrastructure: monolithic applications, on-premises systems built on older architectures, and tightly coupled dependencies that predate modern API design. These systems are often incompatible with the automation-first, containerised, cloud-native approaches that DevOps pipelines assume.

Attempting to bolt modern tooling onto an unchanged legacy estate rarely produces good results. Instead, organisations should:

• Assess which legacy systems can realistically be modernised, strangled (incrementally replaced), or encapsulated behind APIs.
• Prioritise the systems that most constrain delivery speed.
• Accept that some legacy systems will need significant investment before full DevOps practices apply to them.
• Avoid creating two-tier IT estates where new projects run on modern pipelines but critical legacy systems are excluded — this limits the overall impact of DevOps adoption.

5. Process and Workflow Changes

DevOps does not prescribe a single delivery process. There is no universal framework that applies to every organisation, and DevOps does not come with predefined KPIs. This flexibility is a strength, but it can also feel like a vacuum to teams accustomed to rigid waterfall or ITIL-based processes.

The transition from heavyweight change-approval processes to lightweight, automated deployment pipelines requires genuine procedural change. Audit trails, change records, and approval gates still exist in mature DevOps environments — they are simply automated, faster, and evidence-based rather than manual and bureaucratic. Teams navigating this transition should:

• Map existing processes before replacing them — understand why controls exist before removing them.
• Collaborate with security and compliance stakeholders early, not after pipelines are built.
• Allow teams some autonomy in choosing their workflow, within agreed quality and security guardrails.

6. Resistance to Change

Individual resistance is one of the most underestimated obstacles in DevOps adoption. People build skills, habits, and professional identities around specific ways of working. A mandate to change all of that — especially if the rationale is poorly communicated — naturally generates anxiety and pushback.

A common misconception is that DevOps automation will eliminate jobs. In practice, automation shifts the work rather than eliminating it: routine manual tasks are replaced by higher-value activities like pipeline engineering, reliability work, and capacity planning. Addressing resistance effectively requires:

• Transparent communication about what is changing and why.
• Gradual rollout — piloting DevOps on a bounded project reduces risk and gives hesitant team members time to observe results.
• Investing in upskilling so that people feel equipped, not sidelined.
• Acknowledging that some roles will evolve, and providing a credible path for individuals to grow into those new roles.

7. Lack of a Unified Organisational Vision

DevOps adoption fails when different parts of the business pull in different directions. A common failure mode is treating DevOps as a purely technical initiative owned by engineering, while business units, product managers, and security teams continue to operate with conflicting priorities and separate metrics.

Successful DevOps transformations are driven by a shared vision that spans engineering, operations, security, and the business. This means:

• Leadership alignment on what DevOps success looks like — and agreement on metrics such as deployment frequency, lead time for changes, mean time to restore (MTTR), and change failure rate.
• Issues being resolved collectively, not in silos — a production incident is not just an operations problem.
• Cross-functional teams that include security (DevSecOps) and product stakeholders, not just developers and engineers.

Measuring DevOps Success

One practical way to align teams around a shared vision is to adopt well-established DevOps metrics. The DORA (DevOps Research and Assessment) research programme has identified four key metrics — deployment frequency, lead time for changes, change failure rate, and time to restore service — as reliable indicators of software delivery performance. Using shared metrics removes ambiguity about what improvement looks like and creates a basis for honest, data-driven conversations.

Conclusion

DevOps is not a product you can buy or a project you can complete. It is an ongoing discipline that requires sustained investment in culture, tooling, processes, and people. The challenges outlined above are real, but none of them are insurmountable. Organisations that have successfully adopted DevOps consistently report shorter release cycles, higher deployment reliability, faster incident recovery, and greater team satisfaction.

The path forward is pragmatic: start with a willing team, demonstrate measurable results, invest in training and tooling, and build from there. DevOps is, as Jez Humble observed, a never-ending process of continual improvement — and that is precisely what makes it worth the effort.

Nubeva Wins 2019 Stratus Award for Cloud Disruption

San Jose, California — Nubeva Technologies Ltd. (TSX-V: NBVA), a cloud visibility SaaS software developer, announced it received the 2019 Stratus Award from the Business Intelligence Group, specifically in the Cloud Disruptor category. The Stratus Awards recognize companies, products, and individuals delivering unique solutions that leverage cloud technologies.

The Business Intelligence Group uses a proprietary scoring system evaluated by business executives with relevant industry experience, rather than relying solely on editorial staff, to select award recipients.

The Problem: Encrypted Traffic Blinds Security and DevOps Teams

As enterprises move workloads to public, private, and hybrid clouds, the widespread adoption of TLS encryption creates a significant operational challenge: security and network monitoring tools lose visibility into encrypted traffic. This blind spot hampers threat detection, incident response, and application troubleshooting — all critical functions for security and DevOps teams.

Traditional inline decryption approaches struggle to scale in cloud-native environments and often cannot handle modern cipher suites such as those employing Perfect Forward Secrecy (PFS), which generates a unique session key for every connection and prevents retrospective decryption.

Nubeva TLS Decrypt: Out-of-Band Decryption for Cloud Traffic

Nubeva’s flagship product, TLS Decrypt, was launched in June 2019. It is designed to restore full packet-level visibility into encrypted cloud network traffic without requiring inline interception or changes to application architecture. Key technical claims made by the company include:

• Out-of-band decryption — operates outside the traffic path, avoiding latency and availability risks associated with inline decryption proxies.
• Symmetric Key Intercept — a patent-pending technique that captures session keys at the point of generation, enabling decryption of sessions regardless of the cipher suite used.
• Broad protocol and cipher support — covers TLS 1.0, 1.1, 1.2, and 1.3; Diffie-Hellman variants (DH, ECDH, ECDHE); Perfect Forward Secrecy (PFS) implementations; pinned certificates; AES, AES-GCM, ChaCha20-Poly1305; and legacy ciphers in use since approximately 2003.
• Cloud-native, SaaS-based architecture — deployable in minutes across any cloud platform without dedicated hardware appliances.
• Session key capture and storage — allows security and DevOps teams to retrieve and use stored session keys when and where required for forensic analysis or real-time monitoring.

Why This Matters for DevOps and Security Teams

For DevOps engineers managing cloud infrastructure, encrypted traffic inspection is increasingly a compliance and security requirement. Capabilities like Nubeva’s approach address several common operational needs:

• Security monitoring: Feeding decrypted traffic to IDS/IPS, SIEM, or NDR tools without reconfiguring the application stack.
• Incident response: Retroactively decrypting captured sessions using stored session keys during forensic investigations.
• Application troubleshooting: Inspecting encrypted payloads to diagnose performance and functional issues in microservices and API-driven architectures.
• Compliance: Maintaining auditability of data in motion across cloud boundaries in regulated industries such as finance, healthcare, and manufacturing.

Industry Recognition and Target Markets

Nubeva’s TLS Decrypt solution targets enterprises in software and high-tech, financial services, healthcare, and manufacturing sectors — industries with strict requirements around both encryption and regulatory visibility.

On receiving the award, Steve Perkins, Chief Marketing Officer at Nubeva, stated:

“Organizations must inspect and monitor their data in motion as it moves between networks, systems and clouds. We’ve developed a much-needed solution that once again provides full visibility into public, private and hybrid cloud traffic. The solution takes just minutes to deploy and allows security and DevOps teams to capture and store session keys for use when and where they’re needed.”

— Steve Perkins, CMO, Nubeva Technologies

Maria Jimenez, Chief Nominations Officer of the Business Intelligence Group, added:

“Nubeva is at the forefront of cloud visibility, helping to drive practical innovations in the cloud. The cloud is now part of the fabric of our personal and professional lives and we are thrilled that our volunteer judges were able to help promote all of these innovative services, organizations and executives.”

— Maria Jimenez, Chief Nominations Officer, Business Intelligence Group

About Nubeva Technologies Ltd.

Nubeva Technologies Ltd. (TSX-V: NBVA) develops SaaS solutions that enable enterprises to obtain visibility of encrypted cloud traffic. The company’s Symmetric Key Intercept architecture provides universal TLS decryption across any cloud platform, enabling network monitoring and security tools to operate effectively in encrypted environments. For more information, visit nubeva.com.

About the Business Intelligence Group

The Business Intelligence Group was founded to recognize superior performance in business. Its Stratus Awards program uses a proprietary scoring system evaluated by experienced business executives to identify organizations delivering outstanding cloud innovation. For more information, visit the Business Intelligence Group website.

This article is based on a press release dated October 3, 2019. Forward-looking statements in the original release are subject to risks and uncertainties. The TSX Venture Exchange and its Regulation Services Provider accept no responsibility for the adequacy or accuracy of the original release.

Security Moves from Afterthought to Boardroom Priority

AWS re:Inforce, Amazon Web Services’ inaugural security-focused conference, brought together practitioners, executives, and vendors to discuss the rapidly evolving challenge of securing public and multi-cloud environments. A recurring theme: security is no longer an afterthought bolted on at the end of a product launch cycle — it is now a first-class concern at the C-suite and board level.

Brian Riley, Senior Director of Global Cyber Risk Management at Liberty Mutual, illustrated how dramatically the conversation has shifted. “As soon as security would come up, out came the BlackBerrys,” he recalled of executive presentations from seven or eight years ago. “The last couple of years there’s been a drumbeat in the press of security issues that have affected various organizations, and there’s much greater focus [on security] at the executive management level and at a board level.”

That cultural shift was on full display at re:Inforce. Alongside deep-dive technical sessions on specific AWS security features and services, the conference dedicated significant time to broader organizational topics: breaking down the silos between security professionals and development teams, and embedding security thinking earlier in the software delivery lifecycle.

Security Teams Must Move at Development Speed

Bill Shinn, Senior Principal Engineer in the Office of the CISO at AWS, emphasized that the shift from large capital expenditure data center investments to pay-as-you-go cloud consumption has fundamentally changed the pace at which security teams must operate.

“I think security teams have to go faster. And they have to be the fastest thing in the organization,” Shinn said. He cautioned that organizations carrying over a data center mindset when architecting security in the cloud will be left behind.

Riley echoed this point from an enterprise perspective: “We can actually implement those security controls more effectively if we partner with the teams that are building those pipelines and build those controls through automation, so that we can execute them at a scale that we’re simply not going to be able to [with] staff in a security organization.”

How AWS Builds Security Into Its Own Development Process

Shinn described how AWS approaches security internally across its service teams. Every service undergoes a rigorous application security review before launch, encompassing:

• Threat modeling — service teams closest to the architecture develop their own threat models, with support from the security team where needed.
• Static and dynamic analysis — automated code and runtime analysis as part of the review pipeline.
• Canary deployments — new features are released to a limited subset of users or systems to validate security posture before broad rollout.

“Once you state the security intent of how something should or shouldn’t exist in production, we have a set of canaries around making sure that state doesn’t change,” Shinn explained.

A cultural emphasis on ownership is central to this model. Service teams are expected to understand and own the security of what they build, with the central security team serving as an accelerator rather than a gatekeeper. “The service teams just know culturally that it’s their job. And we’re there to help them do it faster.”

To reduce friction further, AWS runs an affinity program that pairs service teams with consistent security engineers across significant feature changes. This eliminates repeated context-setting while still allowing fresh engineers to be brought in for new perspectives when warranted. Customer satisfaction (CSAT) scores are used to measure whether security engagements were frictionless, cost-effective, and resulted in teams shipping secure code.

Multi-Cloud Environments Introduce Unique Security Complexity

One of the most substantive themes at re:Inforce was the security complexity introduced by multi-cloud architectures. Riley noted that AWS and Microsoft Azure, for example, have made fundamentally different architectural decisions — each logical and well-suited to their respective platforms — but this creates a meaningful challenge for enterprises trying to maintain consistent security postures across providers.

“Being in a multi-cloud environment makes some security processes more challenging because Amazon has made very different architectural decisions than Microsoft made, for extremely good reasons that make great sense with their platforms,” Riley said. “That means from an enterprise perspective that we really need to take each cloud provider on their own terms.”

He also raised a practical concern about vendor tools that promise security consistency across cloud providers: in practice, pursuing that consistency can mean foregoing the native capabilities that make each platform distinctive and powerful.

The key questions organizations must answer include:

• Where should the enterprise invest in platform-specific security expertise versus cross-cloud tooling?
• How do you ensure the right people are deployed in environments they deeply understand?
• How do you govern policy consistently while still leveraging platform-native capabilities?

The Cybersecurity Talent Gap Remains a Critical Challenge

Beyond technology, both Riley and Shinn pointed to the talent shortage as one of the most pressing issues facing security organizations today.

“There’s demand for talent in this space that far outstrips supply,” Riley said. Liberty Mutual’s approach has been to recruit globally, accepting that the competition for skilled security professionals requires casting a wide net. Organizations that can leverage global scale in hiring have a meaningful structural advantage in building out security teams.

The talent gap also reinforces the case for automation: when qualified security engineers are scarce, embedding security controls into automated pipelines becomes a force multiplier for whatever security staff an organization does have.

New Services Launched at re:Inforce: Control Tower and Security Hub

AWS re:Inforce 2019 served as the launch platform for two new AWS services aimed at helping customers manage governance and security at scale.

AWS Control Tower

AWS Control Tower provides customers with a pre-configured multi-account AWS environment and a pre-packaged set of guardrails to support ongoing governance and compliance. It is designed to answer demand for out-of-the-box governance without requiring organizations to build their own frameworks from scratch.

“Control Tower is an answer to what customers are really asking for in terms of governance and guardrails out of the box,” Shinn said. “Control Tower is launching with very prescriptive guardrails. And we also still have the Landing Zone solution available for customers that want a higher degree of configuration or customization.”

In practice, Control Tower is suited to organizations that want a fast, opinionated path to a governed multi-account environment, while Landing Zone caters to teams that need deeper customization.

AWS Security Hub

AWS Security Hub provides a centralized view of security and compliance findings across an AWS environment. It aggregates findings from native AWS services and integrated third-party partner solutions, normalizes them, and surfaces high-signal, actionable findings in a single console.

“Security Hub is really about meeting customers where they’re at in terms of integrations and event flows. Taking findings and high signal findings and making them actionable is something that Security Hub has done well within the public preview,” Shinn said.

Security Hub can integrate with Amazon CloudWatch and AWS Lambda, enabling automated remediation workflows triggered by specific findings — a key capability for security teams that need to operate at cloud scale without proportional headcount increases.

Key Takeaways for Security and DevOps Teams

• Shift security left: Embedding security reviews, threat modeling, and automated analysis into CI/CD pipelines is more effective and scalable than end-of-cycle security gates.
• Treat security as an enabler: Security teams that act as partners to development teams — rather than blockers — produce better outcomes and ship secure code faster.
• Respect cloud-native architectures: In multi-cloud environments, platform-native security controls often outperform generic cross-cloud solutions. Invest in cloud-specific expertise.
• Automate to compensate for talent scarcity: Given the persistent talent gap, automation and policy-as-code approaches are essential for scaling security programs.
• Use centralized visibility tools: Services like AWS Security Hub reduce the overhead of correlating findings from disparate tools and enable faster, automated response.

The reason for this imbalance lies in DevOps’ origin story. The narrative centers on developer frustration with risk-averse operations procedures that prevented rapid, frequent deployments. There is truth in that account, but it is more complicated than the myth suggests. Operations professionals are risk-averse for good reason: when things go wrong in production, Ops bears highly visible, public blame with little safety net.

That said, a reasonable aversion to risk can be taken too far. Combine it with a professional identity built around individual servers and manual procedures, and you get people becoming bottlenecks for huge processes—reaching for the keyboard for tasks that should long since have been automated away.

What Does DevOps Actually Mean for Ops?

The most significant benefit DevOps has delivered to operations teams is forcing a hard conversation about moving from artisanal, handcrafted IT infrastructure to industrial, scalable models that do not require a human in the loop for routine tasks. This cultural shift was crystallised in the well-known pets versus cattle analogy—treating servers as interchangeable units rather than irreplaceable individuals—but the transition is far from complete.

There is still a meaningful gap between the rhetoric of software-defined infrastructure and desired-state automation and practical, day-to-day operational uptake of those frameworks. Filling that gap requires a genuine transition away from traditional Ops models, with pervasive, intelligent automation augmenting—rather than replacing—the capabilities of experienced sysadmins.

This is not the automation of cron jobs and shell scripts, which experienced sysadmins have used for decades. Modern serverless and cloud-native frameworks remove the persistent coupling of infrastructure components to individual business services. Workloads now move, grow, and shrink in response to user demand, and infrastructure reconfigures itself top to bottom automatically. The promise of dynamic resource management that earlier virtualisation technologies hinted at is now becoming operational reality.

Why “Set It and Forget It” Automation No Longer Works

In a dynamic, cloud-native environment, operational automation can no longer operate on a static “set it and forget it” model. Every automated process needs real-time contextual awareness of its surroundings and how they are constantly changing. Without that visibility, you get situations like:

• Backup scripts faithfully backing up a server that has become a peripheral part of the application infrastructure, while the cloud services running the bulk of application logic are not meaningfully integrated into the disaster recovery plan.
• OS patching pipelines running against ephemeral instances whose average lifespan is shorter than the patch cycle—work that could be eliminated entirely by patching the base image templates instead.
• Automation that continues to run simply because no one is sure what might break if it stops—a signal that it is time for deliberate chaos engineering to find out.

To keep operational automation aligned with business reality, every automated process should be reviewed regularly across three dimensions: need, function, and ownership.

Three Questions Every Ops Team Should Ask About Their Automation

1. Who Needs This Automation?

Every piece of automation that runs should be traceable—however indirectly—to a business requirement. Useful questions to ask include:

• Does this serve a clear operational goal? “This ensures our infrastructure scales seamlessly in response to user demand” is a solid justification.
• Is the goal still valid given current architecture? “This keeps operating systems patched” is a legitimate aim, but if provisioned OS instances are replaced faster than the patch cycle, patching the base image template may be all that is needed.
• Is inertia the only reason this still runs? “We’ve always done it this way and aren’t sure what would happen if we stopped” is a prompt to run a controlled experiment—deliberately disable the process in a non-production environment and observe.

2. What Is the Function of This Automation?

The technology landscape continues to shift rapidly. Virtualisation was barely settled when cloud computing arrived; cloud computing was still maturing when containerisation accelerated; containerisation is still evolving alongside serverless architectures. Automation written for one era can carry hidden assumptions that make it fragile or redundant in the next.

Ops teams should borrow a practice from software development: refactoring. Review automation regularly to remove outdated assumptions, eliminate technical debt, and take advantage of newer capabilities. The function of a script or workflow that made sense in a bare-metal or early-virtualisation context may need to be redesigned completely for a container-native or serverless environment.

3. Who Owns This Automation?

Every piece of automation needs a named owner—someone responsible for maintaining it over time and accountable when it breaks. Developers have long discussed the concept of technical debt: the compounding cost of unmaintained code. Operational automation accumulates the same kind of debt when no one maintains it.

Historically, sysadmins took pride in the uptime of individual servers. That sense of ownership needs to migrate: from the individual server to the overall infrastructure, and to the automation and management tooling that ensures its availability and performance over time. The cattle-not-pets principle applies to the infrastructure; the ownership and craftsmanship principle applies to the automation that manages it.

Ops Is the Other DevOps

As Ops becomes increasingly about building and managing automation rather than administering individual systems, the boundary between Dev and Ops begins to dissolve. Development teams are taking on production responsibility—”picking up the pager”—while operations teams are writing progressively more sophisticated code to fulfil the infrastructure promises that applications depend on.

Traditional Ops tasks are evolving or disappearing, and new roles are emerging in their place. The role of automation architect—someone who designs, maintains, and governs the systems that keep infrastructure running—is becoming more strategically important than any role that primarily involves logging into individual servers or network devices. Operations professionals navigating this transition have a great deal to learn from the software engineering practices that developers have refined over the past decade: version control for infrastructure code, code review, testing, refactoring, and clear ownership models.

In the long run, the term “DevOps” may come to describe not developers versus non-developers, but two distinct types of software engineer: one focused on business logic and user-facing features, and one focused on the architectural foundations and automation that make reliable delivery possible at scale. Getting there requires Ops to be taken as seriously as Dev in the tools, practices, and culture that organisations build around continuous delivery.

This article is adapted from a piece originally published on DevOps.com. The original author was affiliated with Moogsoft, which at the time of writing had a strategic partnership with Microsoft.

DevOps, open source, and programmable infrastructure were dominant trends heading into 2018. To understand where IT professionals were focusing their energy, TechTarget gathered New Year’s resolutions from DevOps engineers, ops veterans, project managers, and cloud architects. The result is a practical snapshot of the skills and mindset shifts the industry was prioritizing—most of which remain highly relevant today.

Pick Up New Operating System Skills

“I grew up in Microsoft, and I’d like to ratify and expand Linux [server administration]. My goal for the next 12 months is to get a Red Hat certification.”

— Gary Bright, Infrastructure Developer at Niu Solutions (UK)

For engineers rooted in Windows environments, Linux fluency has become increasingly important as cloud-native infrastructure defaults to Linux-based systems. Red Hat certifications cover a broad range of IT functions performed with Red Hat products—from Gluster storage administration to OpenShift container deployment. Beyond its core Linux administrator and developer tracks, Red Hat also offers a dedicated DevOps certification path for practitioners looking to formalize their skills.

Do DevOps Right—Not Just by Name

“[The goal is] getting our heads around what DevOps is, and self-learning, and bringing that back into the organization. You can’t just say, ‘I’m going to do DevOps or just Agile.’ How do I pick and choose from those and push it into our processes and make sure each bit is beneficial to our org?”

Adopting the DevOps label without understanding its underlying principles is a common pitfall. True DevOps transformation requires deliberately selecting practices—continuous integration, automated testing, blameless post-mortems, shared ownership—that solve real problems within a specific organization. Blanket adoption of frameworks without adaptation rarely delivers value.

Rely on Monitoring and Management Dashboards

“We are at the point where we started utilizing management dashboards now and want to do more and more: create all the dashboards, all the alerts and all the data-driven metrics.”

Observability is only as useful as the dashboards and alert configurations that surface actionable signals. Moving beyond reactive incident response—where teams scramble after something breaks—toward proactive monitoring using historical metrics allows teams to spot degradation before it affects users. The goal: use data to prevent incidents, not just respond to them.

Advice for professionals looking to grow in DevOps: combine a relevant certification with at least one programming language. An example path cited was obtaining the AWS Certified Solutions Architect credential alongside scripting or automation skills to bridge the gap between application engineering and operations.

Bring Enterprises into Modern Ops

“I want to get better at providing [configuration and compliance automation] … to help that customer move one step closer to continuous integration, continuous deployment [and] continuous compliance.”

— Larry Herz, Senior Data Center Engineer at Ahead LLC

Not every enterprise can or should move everything to the cloud immediately. A pragmatic approach—evaluating workloads case by case—was already standard practice by 2017. Applications that benefit from auto-scaling or geographic distribution are natural candidates for cloud migration. Large monolithic stacks, by contrast, often require significant refactoring before a cloud move delivers real cost or performance improvements. A lift-and-shift migration without architectural changes can produce cloud bills higher than equivalent on-premises costs.

Configuration management and compliance automation (using tools such as Ansible, Chef, or Puppet) are key enablers of CI/CD pipelines in enterprise environments, ensuring that environments remain consistent and auditable without manual intervention.

Pick Up a New Programming Language

“My last personal goal was to improve my technical communication. What’s next? Learning Go. The ops and developer tooling world is moving to Go, and I don’t have a statically typed language under my belt. I write Ruby every day, and default to Python when given the choice.”

— Paige Bernier, Software Engineer on New Relic’s Demotron project

Go (Golang) was developed at Google and has become a dominant language for DevOps and infrastructure tooling. Its strengths include fast compilation, a straightforward concurrency model via goroutines, and a standard library well-suited to network services and distributed systems. Many widely used DevOps tools—including Docker, Kubernetes, Terraform, and Prometheus—are written in Go, making it a practical skill for anyone working in cloud-native environments.

For engineers primarily working in dynamically typed languages like Python or Ruby, Go introduces static typing, which can catch entire categories of bugs at compile time rather than runtime.

Editor’s note: Demotron is an internal New Relic project that builds intentionally poorly performing dummy applications and back-end services, enabling the company to demonstrate its IT performance monitoring and management tooling in realistic failure scenarios.

Put Multi-Cloud to Use

“My resolution is to have several multi-cloud production engagements where organizations can take advantage on-the-fly of cloud pricing and region availability.”

— Will Kinard, CTO of BoxBoat Technologies

By 2018, the hybrid data center model was already well established. The next logical step was workload portability across multiple cloud providers—enabling organizations to exploit pricing differences, geographic availability, and provider-specific capabilities without being locked into a single vendor.

Containers are the key enabler of this portability. However, realizing multi-cloud deployments in production requires mature container orchestration, a clear approach to networking and service discovery across providers, and federation technologies that allow a unified control plane to manage workloads across clouds. The maturity of tooling in this area has grown substantially since 2018, but the architectural decisions Kinard described remain central to any multi-cloud strategy.

Focus on What Matters—Including Your Own Health

“Personally, I really want to take good care of myself. You do ops work for 15 years and it’s 15 years of sleep deprivation. It can ruin your health. That’s why I’m so passionate now about helping people, particularly in ops, to remove some of that burden of being way overwhelmed. We don’t let our computers get to 100% capacity utilization, and we shouldn’t let ourselves either.”

— Dominica DeGrandis, author of Making Work Visible: Exposing Time Theft to Optimize Work & Flow

Burnout in operations roles is a well-documented problem. Persistent on-call rotations, alert fatigue, and organizational pressure to maintain uptime at all costs erode both individual health and team performance over time. DeGrandis’s analogy is apt: systems engineering practice explicitly avoids running servers at 100% utilization because performance degrades and failures become more likely—the same principle applies to human capacity.

Sustainable DevOps practices—including thoughtful alert thresholds, fair on-call rotations, blameless post-mortems, and explicit prioritization of work in progress—are as much about organizational health as they are about technical efficiency. DeGrandis’s book Making Work Visible offers a practical framework for identifying where time and energy are being consumed invisibly, which is a useful starting point for any team struggling with overload.

Key Takeaways

• OS breadth matters: Linux fluency and formal certifications (such as Red Hat’s) open doors in cloud and DevOps roles, even for engineers with a primarily Windows background.
• DevOps is a practice, not a label: Adopt specific techniques that solve real organizational problems rather than implementing frameworks wholesale.
• Observability drives proactive operations: Invest in dashboards and historical metrics to prevent incidents, not just respond to them.
• Cloud migration requires judgment: Lift-and-shift is not always the right move; workload characteristics should drive migration decisions.
• Go is a practical DevOps language: The ecosystem of infrastructure tooling built in Go makes it worth learning for anyone in the cloud-native space.
• Multi-cloud portability requires container discipline: Realizing multi-cloud value depends on mature orchestration and federation strategies.
• Operator health is a system concern: Sustainable on-call practices and workload management are prerequisites for long-term team performance.

The Core Problem: Speed Versus Security in Government IT

Automation has become a foundational technology for modern IT organizations. It allows teams to deploy, tear down, and reload production systems without manual intervention. But for federal agencies, automation alone is not enough. Once a system reaches production, managers need confidence that it cannot be misconfigured and that infrastructure components remain exactly as they were approved.

At the same time, methodologies like agile and DevOps push teams to develop software iteratively and ship changes quickly. This creates a fundamental tension: How do you ensure that systems on government networks remain in a completely known, secure state once they reach production?

Compliance Pressures Make This Harder

Federal agencies operate under a range of security accreditation frameworks and requirements, including:

• FISMA (Federal Information Security Management Act)
• FedRAMP (Federal Risk and Authorization Management Program)
• CDM (Department of Homeland Security Continuous Diagnostics and Monitoring program)

As systems are continuously evaluated over time, IT and security managers often discover that what was authorized to go into production does not necessarily have the same configuration six months later. Configuration drift — the gradual, often untracked divergence of a live system from its approved baseline — is a persistent and real problem in government environments.

What Is Immutable Infrastructure?

Immutable infrastructure is a deployment and operations model in which servers, containers, or other infrastructure components are never modified after they are deployed. Instead of updating a running system in place, you replace it entirely with a new, pre-approved image or container that incorporates the required changes.

At first glance, the idea of an unchanging infrastructure may seem like the opposite of an agile infrastructure — one that needs to flex and adapt constantly. In practice, the opposite is true. Immutability can actually accelerate agile adoption in government agencies because it builds verifiable trust in the infrastructure itself.

How Immutable Infrastructure Works in Practice

To understand the value, consider how a general-purpose operating system like Linux works in a traditional enterprise environment. Enterprise Linux is built to run thousands of instances in production and provides extensive flexibility to configure each instance differently. That flexibility comes at a cost: management complexity grows significantly, and each instance can end up uniquely configured over time, making it difficult to audit what is actually running.

Immutable infrastructure flips this model:

• Hosts are configured at deployment time, not modified afterward.
• All instances are managed identically. One web server looks exactly like every other web server.
• Changes are transactional. Updates go through a defined process — pre-tested, pre-approved configurations are bundled into a new image, and the old instance is replaced.
• Automation is central. Because hosts are configured through automation, the approach works consistently across public clouds, private clouds, and even virtual machines on a developer’s laptop.
• Large distributed environments become more manageable, even when direct control over individual hosts is limited.

This approach enforces a high degree of standardization and makes change management auditable by design.

Red Hat Atomic Host as an Example

Red Hat Linux Atomic Host (now succeeded by Red Hat CoreOS in more recent Red Hat product lines) was a purpose-built variant of Linux optimized for running immutable infrastructure. It was designed specifically to run DevOps workloads and Linux container workloads.

In this model, if a developer wants to change the host operating system, those changes must pass through a formal configuration management process. The result of that process is a new image or container — not a patched live system. This means every change is traceable, reviewable, and reproducible.

A Real-World Government Example: USCIS

The U.S. Citizenship and Immigration Services (USCIS) adopted this approach to build a high level of confidence in the technology deployed on its networks. The results illustrate the organizational as well as technical benefits.

Previously, any system change had to go through a lengthy peer review and configuration management change program — a process that could take two to three months. Under the immutable infrastructure model, if a developer makes a change and it passes quality control checks, those changes can move directly to the production system. The developer no longer waits months for approval. Innovation cycles accelerate because the immutability of production provides the assurance that previously required manual review.

“They can realize innovation much faster because of this immutability of production. USCIS is one of the first agencies to truly do DevOps.”

Shawn Wells, Chief Security Strategist, Red Hat North America Public Sector

Why Immutability Builds Trust Across Teams

The real perceived risk of agile and DevOps in government is chaos — things changing so fast that no one can be certain what is actually running. Immutable infrastructure directly addresses this fear by providing a provable, auditable record that what was approved is what runs in production.

The trust benefits span all three groups that typically create friction in government IT delivery:

• Security teams gain confidence that whatever goes into production is exactly what they verified — nothing more, nothing less.
• Operations teams know that the approved blueprint is what will actually end up in production, eliminating configuration drift as a variable.
• Development teams can be certain that the software or blueprint they built and validated through automation is identical to what the DevTest team approved.

Collectively, this reduces the organizational burden of troubleshooting. When something goes wrong in production, teams are not chasing down undocumented manual changes applied months ago — they are working with a known, auditable baseline.

The Security Resilience Angle

There is also a direct security benefit. If an agency is compromised and an attacker attempts to install malware or alter system binaries, immutable infrastructure is inherently more resistant to persistence. Because hosts are expected never to be modified in place, any unexpected change is immediately anomalous and detectable. The infrastructure can be designed to automatically replace a compromised host with a clean, approved image rather than trying to remediate an infected live system.

This resilience model aligns well with modern cybersecurity thinking around assume-breach architectures and zero-trust principles, where the goal is to limit the blast radius of a compromise and restore known-good states quickly.

Key Takeaways for DevOps and Government IT Teams

• Immutable infrastructure is not the enemy of agility — it is an enabler of sustainable agility in regulated environments.
• By making every change transactional and image-based, you create a natural audit trail that satisfies compliance requirements like FISMA and FedRAMP.
• The model reduces configuration drift, a significant source of security and operational risk in long-lived systems.
• Adopting immutable infrastructure can compress approval and deployment cycles by replacing manual review with automated, pre-validated change management.
• The approach builds inter-team trust — a prerequisite for genuine DevOps culture — by giving security, operations, and development a shared, verifiable source of truth.

The Comment That Started the Debate

Not long ago, a reader left this comment on a “making code faster” series:

…this “making code faster” series is pretty useless for the average developer working on the usual application.

It’s a sentiment you’ll hear often in developer communities—that topics like performance internals, database engine design, or systems programming are too niche to matter to someone building a typical enterprise application. The argument is understandable on the surface, but it doesn’t hold up under scrutiny.

Who Is the “Average Developer,” Really?

The so-called average developer is often described as someone perpetually heads-down, coding another login page under a deadline, with no time to look up. This framing appears regularly in discussions about professional development expectations—including arguments that expecting developers to learn on their own time is somehow offensive or unrealistic.

That view is worth taking seriously. Life is busy. Many developers are balancing demanding jobs, families, and other responsibilities. No one is suggesting that you neglect your family to chase the latest technology trend.

But there is a real difference between balance and stagnation.

Why Breadth of Knowledge Pays Off

If you limit your learning strictly to what you need for next week’s sprint—the hottest JavaScript library, the design pattern your team just adopted—you are optimizing for short-term delivery at the cost of long-term capability. Here’s why that matters:

• Recognition of known patterns: When you encounter a tough problem, a broad knowledge base lets you say “I’ve seen this class of problem before” and reach for a better solution faster.
• Avoiding reinvented wheels: Understanding foundational concepts—memory allocation, concurrency, query planning, caching strategies—helps you avoid mistakes that have already been made and documented in the field.
• Genuine versatility: Technology stacks change. Developers who understand underlying principles adapt more easily than those who only know a specific framework’s API surface.
• Better judgment in design decisions: Performance characteristics, trade-offs in data modeling, or failure modes in distributed systems are relevant even in “average” applications once they reach any meaningful scale.

Cycling Through Versions Is Not the Same as Learning

There is a trap that many developers fall into: mistaking framework churn for genuine growth. Moving from one version of a web framework to the next—adopting each new release as it ships—can feel like continuous learning. It isn’t. If the underlying concepts are the same and you’re only tracking the API changes, you’re running on a treadmill.

Genuine learning means expanding into adjacent or foundational areas: how the runtime manages memory, how the database executes your queries, how the network stack behaves under load, how operating systems schedule threads. These topics may not pay off immediately. They will pay off eventually—often at the exact moment you need them most.

How Much Time Does It Actually Take?

The good news is that continuous improvement does not require heroic sacrifice. For most people, two to four hours per week is achievable without disrupting family life or work commitments. That translates to roughly 100–200 hours per year—enough time to work through a substantial book, complete a focused online course, or build a meaningful side project.

Practical ways to find that time:

• Treat one or two evenings per week as deliberate learning time, not passive screen time.
• Use commute time for technical podcasts, talks, or audiobooks where possible.
• Replace low-value browsing (social media, news cycling) with focused reading or practice.
• Pick topics that genuinely interest you—motivation sustains the habit better than obligation.

The Bottom Line

Valuing your career means investing in it consistently, not just when a new job forces you to. Advanced topics—performance engineering, systems design, compiler internals, distributed systems theory—are not the exclusive concern of people building database engines. They are the foundation that separates developers who can only execute someone else’s design from developers who can reason about problems from first principles.

That investment is not always easy. It is, however, worth making.

Originally sourced from a discussion on DZone.com. The views reflect a perspective on developer professional growth and continuous learning.

A DevOps survey of 1,000 software professionals — including developers, database administrators, and managers — shed light on the real-world state of database DevOps. More than half of the companies involved employed over 500 people, giving the results reasonable weight across mid-to-large enterprise environments.

Top-Line Findings

• Within two years of the survey, 80% of companies were expected to have adopted DevOps.
• The primary driver for including the database in DevOps pipelines is increasing the speed of database change delivery.
• The biggest obstacles to DevOps adoption are a shortage of skills and a lack of alignment between development and operations teams.

Those headlines are significant on their own, but the deeper findings — particularly around the database — are where the survey becomes genuinely instructive for engineers trying to extend DevOps practices beyond application code.

Do Developers Work Across Both Databases and Applications?

The answer, consistently across all companies surveyed, is yes. Roughly 75% of developers are responsible for both database and application development. This challenges the idea that database work belongs exclusively to a dedicated DBA team — in practice, full-stack responsibility is already the norm.

The numbers go further:

• 60% of developers build database deployment scripts.
• 39% are responsible for deploying database changes to production.
• In companies that have already adopted DevOps, those figures rise to 74% building scripts and 45% handling production deployments.

The implication is clear: if you are a developer without strong database or SQL skills, closing that gap is increasingly important to your day-to-day effectiveness.

How Frequently Are Database Changes Deployed?

Deployment frequency is one of the clearest indicators of DevOps maturity, and the database is no exception.

• 44% of companies practicing database DevOps deploy database changes daily or more than once per week.
• Among companies with no plans to adopt DevOps, that figure drops to 28%.

One interpretation is that teams without DevOps simply face less pressure to release frequently. However, the answer to the next question complicates that reasoning.

What Is the Greatest Drawback of Traditional Siloed Database Development?

Survey respondents ranked the following as the top drawbacks of keeping database development separate from application development:

1. Increased risk of failed deployments or downtime when introducing database changes.
2. Slow development and release cycles.
3. Inability to respond quickly to changing business requirements.
4. Poor communication between development and operations teams.

Teams are broadly aware these problems exist. The more interesting question is what is preventing them from acting on that awareness.

What Is the Biggest Challenge in Integrating Database Changes into DevOps?

The leading challenge is synchronizing application and database changes and bridging the different working approaches of development and operations teams. This is somewhat ironic — the very problem that motivates DevOps adoption in general is also what makes extending DevOps to the database hard.

There is, however, a positive feedback loop at work. Once DevOps practices are embedded in application development, many of the coordination and communication issues begin to resolve themselves — making the extension of those practices to the database progressively easier.

How Long Will Full Database Deployment Automation Take?

This question produced arguably the most revealing result in the entire survey:

• 43% of respondents who had not yet adopted DevOps estimated it would take longer than two years to fully automate database change deployments.
• By contrast, 68% of those already practicing DevOps expected to achieve the same goal in less than one year.

Given the broad mix of industries and company sizes in the survey, this gap is not easily explained by selection bias. The more likely explanation is a compounding effect: once an organisation invests in DevOps tooling, culture, and automation for application delivery, those foundations make it substantially faster to extend the same practices to database change management.

What This Means for Your Team

The survey paints a consistent picture: the database is not an afterthought in DevOps maturity — it is a meaningful and often lagging part of the pipeline. Teams that ignore database DevOps risk accumulating exactly the bottlenecks and deployment risks they were trying to eliminate. The good news is that investment in DevOps practices generally accelerates the ability to bring the database along with it. Starting with version-controlled migration scripts, integrating database changes into CI pipelines, and establishing shared responsibility between developers and DBAs are all practical first steps.

Note: Survey data cited in this article originates from a 2017 study attributed to 126kr.com. Figures should be interpreted in their historical context; adoption rates and tooling have evolved considerably since publication.