Why DevOps Is Harder Than It Looks

The ability to introduce new business services and capabilities — and ship them to customers quickly and effectively — depends on IT and business sides of the enterprise being in genuine alignment. DevOps provides a framework for achieving that alignment by combining development and operations through practices that prioritize collaboration, automation, and continuous feedback.

“It’s a very powerful tool for removing bottlenecks,” says Aater Suleman, co-founder and CEO of Flux7, a consulting firm that specializes in DevOps adoption.

Yet despite the clear benefits, many organizations struggle to move beyond surface-level adoption. Business and IT leaders sometimes lack a clear picture of what DevOps actually is, what it delivers, and how it works in practice. Equally common is a failure to identify key stakeholders early, or to connect the organization’s business agility goals to the specific places where DevOps can make a measurable difference.

Reducing Complexity and Improving Agility

A well-executed DevOps initiative reduces complexity and improves agility across the software delivery lifecycle. Concretely, this means:

• Faster, higher-quality code delivery
• Software that more closely reflects the needs of business units and end customers
• IT infrastructure and capacity that scales to match shifting organizational requirements
• Automation that frees teams from repetitive, error-prone manual tasks

“An organization can gain a level of automation and efficiency that is transformative,” says David Newberry, principal for application services and platforms at Capgemini Consulting.

A clear vision of what DevOps will deliver is paramount. That vision should be anchored in business value: faster application deployment, more reliable services, and better alignment between what development teams build and what the business actually needs. Critically, that vision must be built with input from stakeholders across the organization — not just in IT.

Culture Is the Hard Part

“A point that’s often overlooked is that DevOps is heavily about the culture of the organization,” Newberry emphasizes. “It requires different thinking and different behavior.”

Cultural change is arguably the most difficult aspect of any DevOps transformation. Suleman stresses that a culture of accountability is essential. That means:

• Establishing a governance model with clear KPIs, metrics, and quality gates
• Building shared ownership — teams must understand that the full system is greater than the sum of its individual parts
• Holding development teams accountable beyond the single component they deliver, including code security and downstream interactions with other services, APIs, and systems

“Development teams need to recognize that they are responsible for more than the one piece that they create and toss over to the next group,” Suleman says. “They need to be accountable in a more holistic way.”

Building a Practical DevOps Strategy

Getting DevOps into the mainstream of an organization requires a deliberate, structured approach. Suleman recommends the following progression:

1. Establish a center of excellence. Create an internal team or working group that owns DevOps best practices and drives adoption.
2. Run focused pilot projects. Choose initiatives that will demonstrate clear ROI and attract the attention of leadership.
3. Document outcomes. Record both successes and failures. Learning what doesn’t work is just as valuable as what does.
4. Share knowledge broadly. Once internal experts emerge, use them to help other teams adopt DevOps practices. “You can help other teams get on board and push the concept deeper into the organization,” Suleman explains.

The Tactical Building Blocks

Beyond culture and strategy, a functioning DevOps model requires a set of concrete technical and process capabilities:

• Collaboration and communication tooling: Real-time communication platforms that keep all key stakeholders in sync, regardless of location.
• Automated testing: Tools that check continuously for code quality issues and application security vulnerabilities.
• Cloud and API libraries: Shared, reusable infrastructure and integration components that accelerate delivery.
• Integrated configuration management: A unified approach to managing environment configurations to reduce drift and deployment failures.
• Application monitoring and automated dashboards: Real-time visibility into system performance, team status, and project governance — including continuous and predictive monitoring where appropriate.

Dismantling Silos

One of the most fundamental structural changes DevOps demands is the elimination of IT silos. Traditional software delivery moves code through discrete stages — build, test, deploy — handled by discrete, separated teams. DevOps replaces that model with continuous, cross-functional workflows that are visible to all relevant stakeholders.

“There’s no need for everyone to sit in the same room,” Suleman notes. “With tools and processes that enable communication and define the delivery process, it’s possible to radically redefine the speed and manner in which development takes place. You no longer wind up with developers not knowing what the change was supposed to be and operations making the wrong change.”

DevOps Is a Continuous Improvement Program, Not a Project

When organizations succeed with DevOps, processes that previously took months may take weeks or days. Error rates drop. Agility, flexibility, and delivery performance improve measurably, and the organization’s capacity for innovation expands.

“The most important thing to understand is that DevOps is not a six-month initiative,” Newberry says. “It’s not a close-ended project. It’s a continuous improvement program that ties together your business and IT value chains. Even as technology evolves and customer solutions change, DevOps is able to help an organization deliver faster and better. It provides the framework to grow and change.”

That framing matters. Organizations that treat DevOps as a one-time transformation project tend to plateau. Those that treat it as an ongoing discipline — continuously measuring, learning, and improving — are the ones that realize the deepest and most durable benefits.

This article draws on commentary originally published at baselinemag.com, including insights from David Newberry of Capgemini Consulting and Aater Suleman of Flux7.

Why DNS Matters in a DevOps World

The DevOps model continues to gain traction because it reduces errors, shortens development cycles, and lowers the cost of post-deployment fixes. Central to DevOps is continuous integration and continuous delivery (CI/CD), which depends on the automatic creation and teardown of infrastructure — and on the network layer keeping pace with those changes.

DNS is often an afterthought in DevOps planning, yet it sits at the foundation of every network interaction. When infrastructure can be spun up or torn down in seconds, a DNS layer that takes 30 minutes to propagate changes becomes a serious bottleneck. Intelligent DNS — a managed, API-driven DNS service with fast propagation, service discovery integration, and native DevOps toolchain support — addresses this gap directly.

How Traditional DNS Became a Bottleneck

DNS was originally designed for a relatively static internet. Hostnames changed infrequently, and manual zone file edits were acceptable. Cloud computing changed that model entirely. Infrastructure as Code (IaC) tools can now provision or destroy hundreds of virtual servers with a single command, using robust cloud provider APIs. Traditional DNS, with its manual zone management and slow propagation, cannot keep up with this pace.

Organizations running modern DevOps pipelines need a DNS solution that offers:

• High performance and low propagation latency — DNS changes should be visible at edge nodes in seconds, not minutes or hours.
• A robust, programmable API — so DNS records can be created, updated, and deleted as part of automated infrastructure workflows.
• Service discovery integration — so applications can locate other services dynamically as infrastructure scales up and down.

DevOps as an Evolution of Agile

Agile methodology broke down the wall between developers and QA testers by merging them into cross-functional teams, producing higher-quality software at greater velocity. DevOps extends this philosophy further by also merging development, testing, and operations responsibilities. The goal is to eliminate silos between development, QA, and network operations teams so that code flows smoothly from commit to production.

This cultural and tooling shift enables organizations to release software faster, respond to customer feedback more quickly, and compete more effectively. Every component of the delivery pipeline — including DNS — must support this velocity rather than impede it.

Propagation Speed: Why Your DNS Round-Trip Time Matters

In a DevOps environment, a single IaC operation might create or remove dozens or hundreds of virtual servers. Each of those servers may need DNS records created, updated, or deleted immediately. If DNS propagation lags — taking 30 minutes for changes to appear at authoritative and edge name servers — your automation pipeline stalls. Developers and operators are left waiting, which defeats the purpose of automation.

When evaluating managed DNS vendors for a DevOps environment, propagation speed should be a primary evaluation criterion. Test how quickly changes made via the vendor’s API appear at their global edge nodes before committing to a provider.

Infrastructure as Code and Its DNS Requirements

Infrastructure as Code treats server and network configuration with the same rigor as application source code — versioned, tested, and repeatable. IaC has three primary components:

• Infrastructure Blueprints — Declarative definitions of your infrastructure that enable consistent, repeatable deployments. Tools like Terraform, Ansible, and Chef are widely used for this purpose.
• Version Control — Infrastructure definitions are stored in a version control system (e.g., Git), allowing teams to track changes and roll back to a known-good state when needed.
• Unit and Integration Testing — Infrastructure code is validated at multiple stages of the pipeline before reaching production, reducing the risk of configuration errors causing outages.

For DNS to participate fully in IaC workflows, the DNS provider must offer a programmable API that can be called by tools like Terraform or Ansible. Native provider plugins or modules — for example, a Terraform provider for your DNS vendor — remove the need for custom scripting and make DNS changes a first-class citizen of your infrastructure pipeline. A DNS change becomes just another resource declaration, applied, versioned, and rolled back like any other infrastructure component.

Service Discovery and DNS Integration

Service discovery is the mechanism by which applications and servers identify what other services are available on the network, along with their current IP addresses and ports. Static configuration files and periodically updated databases are insufficient in modern DevOps environments where services scale horizontally and endpoints change constantly.

Common service discovery tools include:

• Consul — Provides service discovery, health checking, and a distributed key-value store, with built-in DNS interface support.
• Apache ZooKeeper — A distributed coordination service often used for service registry and leader election.
• etcd with Registrator and confd — etcd serves as a distributed key-value store; Registrator automatically registers containers with service registries; confd watches etcd for changes and updates configuration files accordingly.

When your managed DNS provider is tightly integrated with your service discovery layer, DNS records and service registries stay in sync automatically. As services come online or go offline, DNS is updated in real time — ensuring that clients always resolve to a live endpoint without manual intervention.

Best Practices for Choosing an Intelligent DNS Provider

The DNS requirements for a DevOps pipeline are not fundamentally different from those for high-traffic production internet traffic — they are simply applied at greater automation velocity. When selecting a managed DNS provider to support a DevOps environment, evaluate the following criteria:

• Anycast DNS network — Requests are routed to the nearest point of presence, reducing latency and improving resilience.
• Zone transfer support — Standard AXFR/IXFR zone transfers should be supported and easy to configure for secondary DNS providers.
• Service Level Agreement (SLA) — The provider’s uptime and performance guarantees should meet your availability requirements.
• Robust, well-documented API — Full CRUD operations on DNS records via a REST API (or equivalent) are essential for automation, IaC, and service discovery workflows.
• Native integration with DevOps toolchains — Look for official Terraform providers, Ansible modules, or Chef cookbooks that allow DNS management without custom scripting.

Build in DNS Redundancy

No single DNS provider is immune to outages. A best-practice DevOps architecture includes redundancy at every layer of the stack, and DNS is no exception. Configure a minimum of two authoritative DNS providers for your zones. This means that if one provider experiences an outage or degraded performance, the other continues to serve queries for your domains without interruption.

Multi-provider DNS redundancy requires that both providers support zone transfers or API-based synchronization so that records stay consistent across providers. Factor this synchronization mechanism into your IaC and automation design from the start, rather than retrofitting it later.

Summary

Intelligent DNS is not a luxury for DevOps teams — it is a foundational requirement. As infrastructure becomes more ephemeral and automation more pervasive, DNS must evolve from a manually managed utility into a fully programmable, high-performance component of the delivery pipeline. The key capabilities to prioritize are fast change propagation, a robust API, native IaC tool integration, service discovery compatibility, and multi-provider redundancy. Teams that align their DNS strategy with these requirements will remove a significant bottleneck from their DevOps lifecycle and ship more reliably at higher velocity.

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

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

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

The early stages of DevOps

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

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

Creating a cultural shift

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

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

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

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

Role-setting

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

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

Data-driven DevOps

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

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

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

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

Achievable success

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