Select Page

DevOps vs. DevOps at Scale


APRIL, 2019

by Carlos “Kami” Maldonado

“DevOps at scale” is what we call the process of implementing DevOps culture at big, structured companies. Although the DevOps term was coined almost 10 years ago, even in 2018 most organizations still haven’t completely implemented the practice.

DevOps used to be most popular at start-ups. After all, it’s easy to introduce processes that break the rules when you had no rules to begin with. But this has left large corporations and bureaucratic organizations to watch DevOps from the sidelines.

Now, things have finally changed. If we check the numbers from the 2018 edition of DORA’s Accelerate: State of DevOps Report, it’s evident that big players in the industry are actively implementing DevOps practices.

Could you do this at your organization? When applying DevOps at scale, you’ll face a collection of hurdles. Let’s look at how to overcome some of them.


Make the Bottom Line Your Top Priority

Large organizations may be leery about implementing DevOps culture out of fear for their bottom line. With start-ups, their value often depends on creating a new niche, maximizing their user base, then selling to a bigger entity. But older organizations are usually more focused on long-term goals. Therefore, they won’t take risks that could jeopardize revenue. The pace of change within their information technology (IT) department is usually slower than at a dynamic and nimble start-up, which can adapt quickly.

Even determining how an IT platform change has affected the bottom line can be tricky. Non-IT departments such as sales and marketing might have different metrics and reporting frequency, so agreements with other business units might be necessary. For example, if IT conducts reporting and planning every two weeks, and the sales department does this every month, it’ll be hard to pinpoint what changes might have influenced other business metrics.

You also need to know how each key performance indicator (KPI) affects indicators in other business units. This will let you make correlations between IT performance and your organization’s core activities. Follow the money and get relevant data, so your DevOps implementation helps your organization become more successful and profitable.

Stay Consistent Across Environments

A built-in advantage of start-ups is their reduced head count. There’s usually only a single team handling every major infrastructure, technology standard, and naming convention. To communicate new rules or policies, you can simply send one group e-mail then get back to working on code.

But when large numbers of people work in isolated groups, some anti-patterns tend to develop. For example, teams may use different words for common elements in a corporation, KPIs will start to change across teams because of differing goals, and server hardware may vary from one environment to another.

Inconsistencies introduce uncertainty in each phase of your code’s life cycle. For instance, “lead time” might mean different things for developers, operators, and marketers. Standardizing terms and technologies will reduce mistakes and the need to rework. It’ll also make things more transparent when capturing, analyzing, and learning from data. And when data and procedures are consistent, they’re useful for everyone.

Communicate Among Teams

Again, because start-ups are small, their teams can usually all fit into the same small office. Some employees might even work in coffee shops or from home and get together once a week for brainstorming sessions. Because of this intimate and casual work environment, staff can usually discuss, and agree on, an idea within minutes.

At large corporations, it’s harder to spread a message effectively. An idea needs to be aligned with shareholder interest and approved by a manager in the C-suite. In addition, clear, careful communication is essential to avoid confusion and opposition.

To enhance organizational culture, it’s essential to have transparency, trust, clear reporting, and blame-free post-mortems. Supporting these values from top to bottom helps everyone at the company feel confident and safe that their contributions will be respected and that peers won’t perceive them as threats.

Leaders need to help their teams communicate more substance and less noise. Managers must push a message clear enough to keep teams aligned with core business goals, instead of getting distracted by every new technology available.

Implementing DevOps at scale with geographically distributed teams introduces an additional layer of complexity. Time zones, varying degrees of language proficiency, and cultural differences all create barriers to collaboration. In addition, trust and influence are harder to build when people aren’t meeting face to face. That’s why it’s so important to invest the resources in getting members of distributed teams together a few days a year. These meetings will help them build personal bonds that will improve their trust in each other and increase their efficiency as teams.

Reduce the Development Cycle

Using shorter sprints in your software development cycle helps developers get feedback more quickly from users. Most start-ups are born with this practice in their DNA. However, developers at bigger companies will shudder at this prospect and assume they’ll have to go through the dreaded code integration phase more often.

Reducing your development cycle times also means code conflicts and regression errors might happen more often. That’s why modifying your sprint lengths isn’t enough when implementing DevOps at scale. Application code should be decoupled from its dependencies throughout its life cycle, so when there’s a breaking change in some related code, it doesn’t block other people from moving forward.

Implementing smaller changes in code and using feature branches and topic branches are popular solutions you might want to consider. Otherwise, you might end up with many small waterfall phases instead of a continuous deployment pipeline.

Automatically Enforce Requirements

There’s usually a “Doctor No” in every big organization—often one or more engineers who serve as production gatekeepers and frequently veto suggestions. ITIL literature calls them the change advisory board (CAB). They make sure deployments are compliant with requirements. CAB processes usually involve meetings and lots of time from developers.

As the software release process evolves, Doctor No’s role will experience deep changes. You can facilitate this by helping CAB members convert their requirements into reproducible automatic tests. Then, you can use these tests as a resource in your continuous deployment platform. Put all this on trial with small projects that don’t affect revenue.

Automating releases will make deployments safer and remove bottlenecks. As a bonus, you’ll see less friction between people when a system enforces code compliance. If you still require a manual step, it could be reduced to people checking a box.

Have Developers On Call

It’s common for start-ups to involve developers with live issues in production. However, putting developers on call in big organizations is no easy feat. People who weren’t hired with the expectation of off-hours availability might not be pleased. And finding developers committed to an on-call role also means paying them higher salaries.

If you currently have only operators on call, you’ll need to modify your escalation and hand-off procedures. Offer your staff some form of compensation for unexpected overtime. Some people prefer money, while others prefer paid time off. In addition, some organizations provide laptops, phones, and other resources to improve on-call incident response time.

Make your on-call staff’s efforts visible by measuring their outcomes with KPIs like “Time to First Response” and “Time to Restore Service.” Keep iterating with new data from each incident to improve the process, and your developers will produce code that fails less often. And when it does, it will produce clearer error messages.

Implement DevOps With Confidence

Every organization will face different challenges when implementing DevOps at scale. When you do, I recommend keeping these important items in mind:

  • Stay focused on providing value to your business.
  • Capture relevant metrics to validate your hypothesis.
  • Reward consistency, transparency, and software quality.
  • Focus on outcomes, perform small changes, and measure again.
  • Build in small wins by automating deployments with low risk, and learn from them.
  • Remember that driving people through change takes time. Listen to them, and keep iterating.

Carlos “Kami” Maldonado

Enov8 blogger, Carlos, is an engineer helping his company transition to DevOps. He specializes in Linux automation, and he’s experienced in all layers of infrastructure, from the application layer down to the cable. He’s part of a team migrating a monolithic app from static VMs to on-premises Kubernetes deployments.

Relevant Articles

What Is Privacy by Design?

What Is Privacy by Design?

21APRIL, 2021 by Zulaikha GreerWhat Is Privacy by Design? Millions of dollars go into securing the data and privacy of an organization. Still, malicious attacks, unnecessary third-party access, and other data security issues still prevail. While there is no definite...

Data Compliance: A Detailed Guide for IT Leaders

Data Compliance: A Detailed Guide for IT Leaders

31MARCH, 2021 by Ukpai UgochiSo, As the leader of a DevOps or agile team at a rising software company, how do you ensure that users' sensitive information is properly secured? Users are on the internet on a daily basis for communication, business, and so on. While...

What Is IT Operational Intelligence

What Is IT Operational Intelligence

24MARCH, 2021 by Taurai MutimutemaKnowledge is more important than ever in businesses of all types. Each time an engineer makes a decision, the quality of outcomes (always) hangs on how current and thorough the data that brought about their knowledge is. This...

What Is Data Fabrication in TDM

What Is Data Fabrication in TDM

15MARCH, 2021 by Carlos SchultsIn today’s post, we’ll answer what looks like a simple question: what is data fabrication in TDM? That’s such an unimposing question, but it contains a lot for us to unpack. What is TDM to begin with? Isn’t data fabrication a bad thing?...

Top TDM Metrics

Top TDM Metrics

19 FFEBRUARY, 2021 by Carlos Schults "You can't improve what you don't measure." I'm sure you're familiar with at least some variation of this phrase. The saying, often attributed to Peter Drucker, speaks to the importance of metrics as fundamental tools to enrich and...

Structured Versus Unstructured Data

Structured Versus Unstructured Data

08 FEBRUARY, 2021 by Zulaikha Greer Data is the word of the 21st century. The demand for data analysis skills has skyrocketed in the past decade. There exists an abundance of data, mostly unstructured, paired with a lack of skilled professionals and effective tools to...