‘Secrets’ of DevOps

10 DevOps ‘Secrets’ for Job Seekers—and Everyone Else

You “do” DevOps, but how well do you understand this trendy mix of software development and operations concepts, techniques, and tools?

If you’re seeking a job in DevOps, are just getting started on a DevOps transition, or are still working in a traditional IT setting, the honest answer may be “Not a lot.” Even seasoned DevOps pros, let’s face it, have a few blind spots.

DevOps has a complicated and often surprising history and practice, from the name itself to the reasons for its rapid expansion inside enterprises of all shapes and sizes. We chose to go deeper into that still-developing tale to highlight ten DevOps “secrets” that everyone involved should be aware of—but frequently aren’t.

1. What’s in a name? With DevOps, plenty

It doesn’t take superhuman reasoning to determine that “DevOps” is a portmanteau that combines development and operations. Even though it has become conventional, the phrase serves to remind its essential purpose: to bring traditionally separated development and operations teams closer together.

But it isn’t the end of the narrative. Patrick Debois and Andrew Shafer are credited with coining the term during an “Agile Infrastructure & Operations” presentation at an Agile conference in Toronto in 2008.

More information, including a video history of the phrase from Damon Phillips, may be found in our piece “The Incredible True Story of How DevOps Got Its Name.”

2. DevOps isn’t really about technology

From “cloud” to “containers,” some of the most popular and widely used names in the modern software environment refer to technology or a group of technologies. It is not the case with DevOps. Though it’s often linked to software development, it’s ultimately a cultural issue. DevOps is sometimes described as a combination of people, procedures, and tools. It isn’t about any of those things in isolation, nor is it something you can buy, install, recruit, or otherwise check off a list as “complete.” No such thing as a “DevOps box” exists.”

“DevOps isn’t a service like a payroll processing,” explains Robert Reeves, CTO, co-founder of database release automation company Datical. “It’s not something you can outsource or delegate to a single team to handle.”

“Put legacy practices in place for a reason. Therefore there are probably vested interests in preserving things the way they are.” However, it would help if you recognized that change is continual and that DevOps is never complete. You have to be tuning and optimizing all the time.”

DevOps is, after all, a culture of continuous improvement; there is no finish line, and pretending there is means you’re missing the point.

3. There is consensus around the DevOps toolchain

Of course, the preceding does not negate the existence of a link between DevOps and technology. To begin with, putting a DevOps flag above the same old, worn tools and processes aren’t going to help anyone.

According to conventional opinion, devOps practitioners benefit most from standardizing on a toolchain. It is up to each firm to choose which tools to employ. However, the building pieces of a powerful, standardized toolset, as depicted in an “infinity loop” diagram like this one, are widely agreed upon.

​​

4. One of the most famous DevOps books is pure fiction

Seriously! The Phoenix Project should be on everyone’s DevOps 101 reading list. The book is regarded as the classic case study for the power of DevOps to tackle real-world IT challenges, co-authored by Gene Kim, Kevin Behr, and George Spafford. It’s also a work of fiction. It’s a fabrication, in other words! The subtitle reads, “A Novel about IT, DevOps, and Helping Your Business Win.”

The Phoenix Project is, of course, solidly rooted in fact. The story follows an IT manager tasked by the CEO to preserve a high-profile project that is well over budget and behind schedule. The way the narrative ends has turned it into a hallmark in DevOps culture, emphasizing the need to modernize monolithic approaches to IT operations, software development, and other areas.

5. The role of “DevOps engineer” is surprisingly controversial

One long-running DevOps argument is whether we should incorporate the phrase into job or team titles. Some people, for example, despise the word “DevOps Engineer.” Similarly, forming a “DevOps team” or department within a larger software company is good. Purists say that DevOps culture should permeate the entire firm; creating a unique team re-paints the same old siloed, monolithic IT pig.

On the other hand, others argue that if DevOps is ultimately about creating and operating better software, it should be widely promoted—so why not include it in job titles?

In the end, DevOps concepts are considerably more important than a team’s name or position. The role of Site Reliability Engineer embodies that effort for some. For other firms, tried-and-true titles like Systems Engineer, Software Engineer, and the like suffice.

6. “DevOps” jobs do exist—and they pay very well

Whether you like it or not, titles like “DevOps Engineer” and others are plentiful these days. On the job site Glassdoor, a recent national search for “DevOps Engineer” yielded more than 23,000 available openings. You’ll find comparable statistics if you do the exact search on other job or networking sites.

It’s unclear whether the title will stand the test of time. Many DevOps experts believe it will eventually go away with the term “DevOps” as it gets ingrained in day-to-day operations. In the meantime, these positions are highly lucrative. Although compensation data is erratic, Glassdoor estimates that the average income for DevOps Engineers is a comfortable $138,378.

7. DevOps can—and should—be measured

Don’t be fooled by the word “culture” into thinking DevOps is a happy-go-lucky affair. DevOps is a serious business, and its effects can and should be evaluated and tracked to gain insight into your development and operations teams’ general health and productivity.

If the ultimate goal of DevOps is to increase time-to-market and quality—two goals that aren’t always in sync in the software world—then there are a slew of metrics to track:

• Frequency of deployment: Smaller, more frequent releases are preferred over large, complex, and rare releases. According to some estimates, DevOps teams release deployments 30 times more frequently than non-DevOps teams. 
• Change volume: How much net change is sent to production in a typical release. Increasing the frequency of deployments should not result in a reduction in overall change volume. 
• Code deployment lead time is a metric that estimates how long it takes code to go from development to production. According to Gene Kim, it forecasts the quality of deployments, the capacity to quickly restore service, customer experience, and, perhaps most importantly, how quickly teams can receive feedback on their work. Significantly, the broader metric of change deployment lead time, according to Kim, isn’t simply tactical; it’s also a strategic indicator of “internal quality, external customer pleasure, and even employee happiness.” 
• The failure rate of deployments: What percentage of deployments resulted in outages, performance difficulties, or other failures to satisfy customer needs? The figure should be as low as feasible and continue to fall. 
• How long does it take your team to recover from failures and other issues? Mean Time to Recovery (MTTR): How long does it take your team to recover from failures and other issues? DevOps aims to establish well-coordinated, collaborative teams that quickly identify and resolve problems. 

“We need to instrument everything, whether our code, database, environment, features,” Kim added, “to obtain strong outcomes on these kinds of metrics.” Because we can receive more telemetries, it’s an exciting time to be a part of the game.” Surprisingly, even a small number of measurements can have a significant impact.

8. DevOps is for big, traditional companies, too

DevOps skeptics have long said that it works better in small, agile businesses than a giant, traditional corporations with 10,000 or more engineers. However, evidence reveals that this isn’t the case.

“We now have so many evidence points to indicate that DevOps is genuinely not just for the unicorns like Google, Amazon, Facebook, and Netflix, but for every technology business, especially in huge, complicated enterprises,” Gene Kim says. What excites me the most is that they’re receiving the same results that we’ve usually only seen in unicorns.” According to Kim, most DevOps value is now being created in huge, complex enterprises, which are seeing similar benefits as the internet unicorns.

9. DevOps correlates with business success

DevOps is linked to not only positive results for IT departments but also to business success. According to Gene Kim, high-performers who use DevOps are significantly more elegant and dependable: “They are more likely to thrive in the marketplace,” both in terms of bottom-line results and corporate valuations.

The data backs him up. “DevOps approaches contribute to higher IT performance,” according to the 2017 State of DevOps Report from Puppet and DORA. Productivity, profitability, and market share are all enhanced due to this better performance.” “The capacity to develop and deliver software swiftly and accurately is a critical differentiator and value driver for all businesses—for-profit, not-for-profit, educational, and government institutions alike,” says the report. DevOps is the way to go if you want to produce value, regardless of how you measure it.”

Even if you aren’t using DevOps, your competitors most likely are, and you may find yourself at a disadvantage.

10. DevOps: it’s not just for IT any more

Why should DevOps be limited to technology teams if it is a culture of doing things better and faster? Shouldn’t the DevOps concepts of speed, agility, efficiency, reliability, and quality pervade all organizations? While DevOps is most often associated with software development teams, it may also be an effective business strategy and a tactical, technical approach. Eliminating inefficient silos and bottlenecks and cultivating a culture of shared accountability for service quality across functional roles and teams is beneficial across the board.

DevOps principles are beginning to find homes outside of IT departments, similar to programming approaches such as agile and scrum. “DevOps has transformed how software is created and deployed,” Christopher Tozzi recently wrote in Channel Futures. But why should we stop there? DevOps may help the entire company better.”

Tozzi proposes five primary ways to implement DevOps-inspired strategies across your company:

• Communications that are centralized and simplified 
• Roles with a lot of latitudes 
• There is automation everywhere. 
• Improvement is ongoing. 
• Before the product or service reaches end-users, problems are identified early. 

Of course, doing so may need the creation of “a shared currency of value,” as CollabNet CEO Flint Brenton describes it. While a statistic like Mean Time To Recovery may be intuitively understandable—and valuable—to an engineer, CMOs and CEOs may require some interpretation. However, everyone understands the necessity of swiftly identifying and resolving problems. That’s precisely what DevOps is all about.

Enteros

About Enteros

Enteros offers a patented database performance management SaaS platform. It proactively identifies root causes of complex business-impacting database scalability and performance issues across a growing number of RDBMS, NoSQL, and machine learning database platforms.