devopsy.kinsta.cloud

Tag: devops definition

Defining DevOps: How Do You Know When You Have Achieved DevOps?

Key to understanding where you are in your organization’s journey is by defining DevOps

Much has been written about the compelling benefits of DevOps. However, the lack of a commonly agreed definition and clear prescription for implementing DevOps have left many people puzzled. Ask a group of experts, “How do you know when you have achieved DevOps?” and you are likely to get different answers.

It is tempting to dismiss definitions as academic. However, there are many incomplete, floundering and costly DevOps implementations that fall short of expected business benefits. This article explains some of the key challenges of defining DevOps, and the importance for having a definition at least within the scope of an enterprise. This article includes suggestions to help enterprises navigate their DevOps journey toward successful business outcomes.

Defining DevOps

An enterprise needs to know when it has accomplished DevOps to justify investments that support business goals. Pinning down a universal definition that satisfies the diverse community of stakeholders and survives the test of time has proven elusive. DevOps spans an evolving body of knowledge covering multiple humans, process engineering and technology disciplines. DevOps is never really “done” because the highest level of maturity, “The Third Way,” continuous improvement, defies setting boundary conditions.

To reconcile this dilemma, some have defined DevOps using vague or transient terms such as a “cultural movement.” Others have skirted the problem of definition with rambling statements describing what is involved to do DevOps, rather than state what it is in concise and concrete terms. Despite these challenges, acceptance of a definition by enterprise stakeholders is a key first step in any successful DevOps transformation. Any meaningful project progress measurements hinge on clear definitions.

I have found the following DevOps definition useful, relatively concise, and stable: “DevOps is the application of continuous flow, feedback and improvement to people, processes and technology for the benefit of agility, stability, efficiency, quality, security, availability and satisfaction.” Defining DevOps in this way is broad enough to stand the test of time, yet specific enough to answer key questions addressed by a good definition including “What is it?” “How it is done?” and “Why do it?” without too much rambling.

Whether you create of choose another definition, or decide to use mine, it is important that your cross-functional teams agree on one to align their goals and implementations and to have a basis to measure your DevOps progress and business outcomes.

DevOps and Continuous Delivery Partnership

DevOps is often said to refer to cultural aspects of high-performance software development and operations including leadership, teams and collaborative practices. Nevertheless, technical mechanisms involved in architecting applications and toolchains are essential for continuous delivery pipelines. Culture, without the technology associated with continuous delivery pipelines, will not achieve the expected benefits of DevOps and vice versa. Therefore, a practical measure of DevOps maturity really must include the technology and not only the culture.

Continuous Flow is a Practical Baseline

DevOps benefits are derived primarily from applying lean manufacturing methods to software development and operations. The “First Way of DevOps,” continuous flow, is first because it is a prerequisite to the Second and Third Ways. Therefore, the realization of continuous flow for at least one application in an enterprise can be considered a baseline for “having DevOps.” If you accept this point of view, then the answer to the question, “How do I know when I have DevOps” can be equivalent to the question, “What is the minimum requirement for continuous flow for an application?” In the context of continuous delivery toolchains, a continuous flow pipeline is achieved when it allows code submissions from development to successfully transit all pipeline stages to deliverable packages acceptable for production deployment.

A DevOps Model Application

Enterprises typically have many applications moving toward DevOps at different paces. Identifying one application as a model for DevOps is useful. The model provides a focal point for DevOps investments, and experiments. Other application product teams learn from the model application as it matures from discontinuous flow to continuous flow and higher levels of DevOps maturity.

Summing Up

A practical answer to, “How do you know when you have DevOps” depends on having a definition. While defining DevOps itself has been elusive, an enterprise definition is needed for alignment and progress measurement. Considering that DevOps needs continuous flow to accomplish business goals, it can be said you have DevOps when you have implemented continuous flow for at least one model application.

— Marc Hornbeek

October 30, 2018
A Definition of DevOps for the Masses

If you asked the average person in the street, “What does DevOps mean to you?” you’d probably get a blank stare. And there are those who aren’t directly involved but are vaguely aware of DevOps as a concept. While a vague understanding is better than nothing, it leaves room for misconceptions and misinformation, which can be problematic in the long term. An accurate definition of DevOps is necessary.

How can you provide an accurate definition of DevOps for a non-technical audience? Long-term DevOps practitioner Alex Honor echoed earlier agile software development principles when he coined the phrase, “People over process over tools.” This mantra provides a handy list of DevOps priorities, and as such offers a useful framework for an easily understandable definition of DevOps.

Start with the People

Everyone loves a good organizational chart, and discussing how DevOps teams organize themselves is a useful way to understand how DevOps should work in practice. DevOps is very much about bridging traditionally separate development and operations departments, but this involves more than simply increasing collaboration between teams.

Related Content:

5 Biggest Ways to Fail at DevOps

DevOps Gets More Exciting in 2018

In a traditional setup, developers build applications and fix them when necessary, while operations teams work to maintain, support and monitor those applications.

In DevOps, the wall dividing these two worlds disappears. But it’s not just about getting dev and ops teams to work more closely—it’s about creating an environment where developers and engineers work alongside each other at every stage of a product’s life cycle. In other words, there should be no separation between dev and ops, just a unified DevOps team.

By emphasizing the people factor and contrasting a DevOps team structure with more traditional arrangements, it’s easier to visualize DevOps playing out in the real world. This is a great place to start when it comes to demystifying DevOps for a less-technical audience.

Move on to the Process

When put into practice, DevOps is supposed to be faster, more efficient and more reliable than more traditional software engineering methodologies—once the organizational structure is in place, these benefits can be achieved via innovative DevOps processes.

In traditional development and ops, manual tasks have a habit of slowing down processes, and getting in the way of high-frequency deployments. But in DevOps processes based on infrastructure as code (more on the tech later), teams can automate the provision and management of resources.

Take the task of provisioning server resources, for example. In the past, the developer would email the infrastructure team and ask for a certain set of resources in a specific configuration. Then someone in the infrastructure team would look at a document and follow a checklist of tasks before finally deploying the server.

In a DevOps process, not only are developers and infrastructure engineers working alongside each other in the same team, they’re also implementing processes through infrastructure as code (IAC).

Within the context of IAC, the provisioning of IT resources is automated via code, so rather than provisioning servers manually, the developer simply clicks a button. The desired infrastructure then spins up automatically, accelerating the overall process and giving DevOps teams the means to deploy far more frequently and efficiently.

By describing the automated processes made possible by IAC, the differences between DevOps and more traditional practices become much clearer. For less-tech-savvy employees, this explanation provides some much-needed context in terms of the day-to-day working of DevOps teams.

Then Talk About the Tools

Technology, and the benefits it brings in terms of automation and management, is a key driver of DevOps. The maturation of cloud computing and virtualization, and the emergence of infrastructure as a service (IaaS) in particular, provides the flexibility and speed demanded by DevOps.

With IaaS, it’s possible to instantly provision computing resources for highly customized and constantly shifting IT requirements, without on-premises hardware or manual configuration. This in turn enables the infrastructure as code (IaC) processes detailed above, and the level of automation required for DevOps teams to function.

So cloud computing, in the form of IaaS and by extension IAC, lays the technological foundations of DevOps. That’s the big-picture stuff, but what about those brand-name tools that non-technical people might have actually heard of? Docker, Kubernetes, GitHub, Jenkins, Travis CI … the list goes on, but how vital are these to the core concept of DevOps?

Arguably, not very. While containerization, source control and continuous integration tools all can perform very important roles within a DevOps context, they’re hardly defining features of DevOps itself.

Continuous configuration automation solutions such as Puppet and Chef come more directly under the IAC umbrella, enabling the automatic configuration and scaling of data center resources. But like the others, these tools would be equally at home in a more traditional setup.

In this sense, there’s no such thing as a “DevOps tool,” just tools that can be used within a DevOps organization for DevOps processes. It’s how you use them that really counts.

So when offering a definition of DevOps for a novice audience, don’t fall into the trap of simply reeling off a list of tools. DevOps is far more about people, organization and process. And while it’s very reliant on IaaS and IAC technologies, many of the tools utilized by DevOps teams are more or less incidental.

And Finally, a Reminder that DevOps Works

The ultimate goal of DevOps isn’t simply to unify development and operations, but to result in shorter dev cycles, more frequent deployments, higher-quality products and happier customers. More bluntly, the ultimate goal of DevOps isn’t just to say, “We do DevOps,” but to increase productivity and make the business more profitable.

Just look at sprawling organizations such as Google and Amazon. The success of these companies hinges on their ability to deploy new software multiple times every day, or even every hour. Amazon and Google may not agree on a precise definition of the term, but what they do agree on is that DevOps, as a set of unified software engineering practices, is crucial to their profitability.

With a consensus on the broad strokes of DevOps emerging over the last few years, lack of definition of DevOps will hopefully become less of an issue as its culture crystallizes. In the meantime, the good news is that the big ideas behind DevOps are also the most straightforward to explain to a non-technical audience.

By breaking DevOps down into people first, process second and tools third, an accurate and relatively simple definition of DevOps is possible. DevOps is fundamentally about people, how developers and engineers organize themselves and work as a unified team to deliver better products faster. It’s on top of this structure that DevOps processes are built, with a heavy focus on automation and innovative tools—always within the context of the core DevOps principles and practices.

— Neal Thoms

January 23, 2018
The Elusive Definition of DevOps

How do you define DevOps? If you went out and asked IT professionals at other organizations, could you guarantee their answer would be the same?

In most cases, the answer to this question is no. DevOps, despite its growing popularity, still lacks a widely agreed-upon definition. There are a few fundamental principles that appear consistently in most explanations of DevOps, such as efficiency, collaboration and improved communication. However, when it comes to the details and how exactly DevOps can be implemented in the software delivery process, differences abound.

Recently, Clutch, a B2B research firm, conducted a survey of IT professionals to gauge knowledge of and opinions on DevOps. The data backs up the notion that a broad definition of DevOps remains elusive—but that fact shouldn’t hold organizations back when it comes to implementing DevOps.

Clutch gave respondents four distinct definitions from separate organizations and asked them to pick the one they think best defines DevOps.

Wikipedia’s definition, recorded in November 2016 and since altered, won the largest percentage at 35 percent. It read, “DevOps … is a culture, movement or practice that emphasizes the collaboration and communication of both software developers and other [IT] professionals while automating the process of software delivery and infrastructure changes.”

The definitions by Rackspace, Hewlett Packard Enterprise and Amazon Web Services each garnered significant support as well, at 24 percent, 21 percent and 20 percent, respectively. Their definitions emphasized different points or excluded elements of Wikipedia’s definition and you can read them in Clutch’s report here.

The organizations’ names were left out of the survey and the definitions’ presentation order was randomized to discourage bias.

No definition won a majority and Wikipedia’s definition leads by only 11 percent. We believe that if there was a “correct” DevOps definition out of these four, then it would’ve gathered more support.

Why Is a Definition So Tough?

The abstract nature of DevOps’ definition may be rooted in the movement’s history.

The idea of combining development and operations teams stems from principles in the Agile software movement, which emphasizes greater communication and collaboration within development teams. By breaking down silos on the operations side, DevOps further streamlined the delivery of product to user.

If the beginning of the DevOps movement could be pinpointed to a specific moment, it would most likely be a talk Flickr employees John Allspaw and Paul Hammond gave at the 2009 O’Reilly Velocity Conference in San Jose, California, titled, “10 Deploys a Day: Dev and Ops Cooperation at Flickr.”

Belgian IT consultant Patrick Debois, who had already been frustrated by the issues between development and operations teams, watched the talk online and, with encouragement by American software developer Andrew Shafer, created the first “devopsdays” conference in Ghent, Belgium. The movement (and the term “DevOps”) took off from there, gaining traction worldwide.

DevOps’ grassroots growth and expansion likely contributes to the lack of a singular definition. The concept was not created by a single organization, nor solidified by a written manifesto, like the Agile movement. In fact, a manifesto may have hurt the DevOps movement, writes Christopher Little on devopsy.kinsta.cloud: “If you have a manifesto for something, then all conversation in the domain will, rather quickly, go back to the manifesto for resolution instead of everybody working together. That’s not handy in an ever-fluid, often on-fire, scale-up fast, resilience-oriented, rapidly changing and evolving IT situation.”

So, DevOps’ history possibly explains its undefined quality, but that could be its strength.

Who’s Right?

In response to Clutch’s data, cloud experts gave differing opinions regarding Wikipedia’s definition.

David Hickman, vice president of Global Delivery at Menlo Technologies, said, “I think that the word culture is misused. It’s more of a methodology trend than a culture, which pertains more to social elements of organizations and how people relate to each other from a professional and business perspective.”

Brian Dearman, solutions architect at Mindsight, agreed with the culture aspect: “It being a cultural movement is true. Fifteen to 20 years ago, DevOps consisted of two separate things, with operations and development consistently complaining about each other. The culture is being changed, removing the animosity between each side.”

Meanwhile, Nick Martin, principal applications development consultant at Cardinal Solutions and organizer for the CloudDevelop Conference, criticized Wikipedia’s emphasis on automation: “The definition may be a little over-prescriptive in talking about automating processes. DevOps can be done without such a strong focus on automation. It’s ultimately about collaboration and getting groups working together in order to solve the same problems.”

Conclusion

So, DevOps lacks well-defined and universal guidelines. Should that stop you from implementing it in your organization?

Absolutely not. DevOps’ benefits are clear for most organizations that implement it. However, it’s imperative to clarify what DevOps should mean for your organization before you start implementation.

The concept of DevOps is broad, but most everyone can agree that increased efficiency, collaboration and communication are positive changes. However, making a point to hammer out the details with your team before implementation is important. Ideas such as increased communication are futile if every employee has a different approach to achieving them.

Choose DevOps, but choose it thoughtfully.

About the Author / Riley Panko

Riley Panko is a Content Developer and Marketer at Clutch, a Washington, D.C.-based research, ratings and reviews platform for B2B services. She conducts relevant research that aims to help consumers enhance their business and select the services and software best-suited to their needs. Connect with her on LinkedIn and Twitter.

February 14, 2017
Trick Question: What is DevOps?

DevOps suffers from the lack of a clearly defined definition. A Google search displays results that state that DevOps is empathy, culture or a movement. There are also derivations of DevOps, such as ChatOps and HugOps.

A lot of speakers mention DEVOPS but no-one seemed to have a widely agreed definition of what DEVOPS actually means.

— Stephen Booth (@stephenbooth_uk) November 19, 2015

Proposed Definition of DevOps: “Getting more done with fewer meetings.”

— DevOps Research (@devopsresearch) October 12, 2015

The real head-scratchers are the number of job postings for DevOps engineers and the number of certifications for DevOps popping up all over the web. The job title “software engineer” is contentious within the technology community, so the job title “DevOps engineer” is just begging to take pointless debates to a new level.

How, then, do you create a curriculum and certification course that has any significant value on an unclear subject?

For a methodology that has an emphasis on people, empathy and communications, it falls woefully short of heeding its own advice and values. On any given day, you can see the meaning debated on blog posts and tweets.

My Understanding of DevOps and Why it Exists

DevOps is an extension of the agile methodology that is hyperfocused on bringing customers extraordinary value without compromising creativity (development) or stability (operations). DevOps is from the two merged worlds of development and operations—operations in this context include all aspects of IT such as system administration, maintenance, etc.

Creation and stability are naturally at odds with each other. The ripple effect is a good way to explain how these two concepts have friction. Stability wants to keep the pond from becoming turbulent and causing harm. Creation leads to change, which can act as a random rock thrown into the water and sending ripples throughout the whole pond, leading to undesired side effects that cause harm to the whole ecosystem.

DevOps seeks to leverage the momentum of controlled ripples to bring about effective change without causing enough turbulence to impact the whole pond negatively.

The natural friction between these two needs often drives a wedge between development and operations. Operations worry that a product update may include broken functionality that customers have come to depend on, and developers worry that sorely needed new features may not make it to customers because of an operation’s resistance to change.

Instead of taking polarizing positions, DevOps is focused on blending those two positions into a force that effectively provides value to the customer without compromising the creativity and stability that a product or service needs to compete in an ever-evolving world.

Why is a Clear, Singular Meaning Needed?

The understanding of a meaning is an important part of sending a message.

If an unclear word is used to send a message, the word risks becoming noise and the message risks becoming uninterpreted or misinterpreted.

Without a clear, singular meaning, you risk losing the message that you want people to hear. In technology, I see messages get drowned in noise all the time.

In communications theory, noise is anything that interferes with understanding. Noise is more than just the sounds of static, loud music or machinery. Creating noise can be simple as using obscure words to explain a topic or providing an unclear definition that muddles the comprehension of a given subject.

DevOps suffers from too much noise that increases people’s uncertainty of the word. After reading a few posts on DevOps, each one with its declaration of the essence of DevOps, people can get confused by what the word means. DevOps is empathy! DevOps is culture! DevOps is a movement!

Because of noise, DevOps seems to stand for multiple ideas plus agile operations without setting any prioritization or definitive context. Okay, so which is it? Is it one of those or is it all of them? Which idea is the most important? Furthermore, these ideas can cause friction, as not everyone shares the same view on these topics. DevOps is supposed to reduce friction between naturally opposing groups within a business, not create more of it.

Remove the Barriers

Another aspect of noise is using words that are a barrier to understanding a given definition.

DevOps is the practice of operations and development engineers participating together in the entire service life cycle, from design through the development process to production support.

— the agile admin

People from a non-technical background or outside the world of agile and development may have a difficult time understanding a definition like that. When I read something like this, all is hear in my head is same sound the teacher in Peanuts makes: “Blah, blah blah, blah.”

If you want people to remember something, make it easy to understand and memorable.

Appeal to All Personality Styles

In marketing, you’re taught to write to appeal to four personality styles: driver, analytical, expressive and amiable. Getting people to work together in the workplace also requires appealing to these four personality types.

There is a need for a single definition of DevOps that appeals to the four personality styles—or, at the very least, refrains from being a barrier to entry. If a person needs to persuade someone who has a driver personality, but the definition includes language that invokes an automatic “no,” that puts people who want to use DevOps at a disadvantage.

Give people every advantage you can for them to adopt DevOps.

It’s Time for a Definition for DevOps

At a time when the DevOps role is becoming increasingly important for businesses, it is crucial that a globally recognized definition be created to reduce uncertainty. It’s hypocritical to introduce a word that touches upon the importance of communication and then expect people to take it seriously when the definition constantly changes.

It’s time that we have a singular definition for DevOps so people can use it for the hiring process or certifications without the risk of the message being lost or co-opted into something it is not.

About the Author/Michael Herndon

Michael is the head of DevOps at Solovis, creator of badmishka.co, and all around mischievous nerdy guy. He is writing on behalf of Packt Publishing.

March 15, 2016
DevOps for non-engineers

If you’ve scrolled through LinkedIn or companies’ career pages, you’ve probably seen the term “DevOps” used as a part of a job title. DevOps Engineers and DevOps architects are everywhere, and many people are surprised to find that those titles aren’t correct. It sounds innocuous: After all, isn’t DevOps something that you do? If you’re a marketer, hiring manager or non-engineer at your company, it might seem like it.

But nothing could be further from the truth. DevOps is actually a philosophy and a set of practices that guides how your engineering and IT teams work. And using the term improperly can cause problems, even if you’re speaking with somebody who has “DevOps Engineer” on their LinkedIn profile.

To clarify what DevOps is and what it means, it helps to know where the movement came from and why it matters.

Where Did DevOps Come From?

The rise of DevOps is rooted in the Agile Systems Admin and Enterprise Systems Management movements, as well as an effort by businesses to become more responsive to rapidly evolving markets and problems. Enterprise Systems Management attacked this problem by replacing large vendor solutions with faster, smaller and sometimes open-source tools, while at the same time, the Agile Systems Admin movement was gaining popularity in Europe as forward-thinking companies translated lean and agile manufacturing lessons to IT departments.

The combination of these agile movements, the rise of SaaS and 24/7 service delivery, and examples like Flickr of excellence in developer-operations collaboration all helped prime the technical community for a change. After a talk by Flickr at the O’Reilly Velocity conference in 2009, highlighting challenges the company faced in continuous deployment and how they solved those problems with focused collaboration across the development and operations silos, Patrick Debois started organizing the first Devopsdays conference, and the name stuck. DevOps has been growing ever since, with conferences around the world, and has become synonymous with collaborative, agile, teams that ship quickly while maintaining high quality. This a very simplified account, of course— I recommend Richard Rapaport’s “A Short History of DevOps”, or Damon Edward’s video on the topic for a detailed history.

And when you understand that history, it’s easier to understand why engineers bristle at the idea of DevOps as a job title or company role. By referring to and thinking about DevOps properly, you’ll not only make tech talent at your company happier, but will also help internalize DevOps principles within your organization.

So, What Is DevOps, Then?

Definitions vary according to who you ask, but The Agile Admin sums it up well:

DevOps is the practice of operations and development engineers participating together in the entire service lifecycle, from design through the development process to production support.

Put another way by the site, it’s “agile systems administration.” That means DevOps is about software developers and ops engineers working together with shared values, principles, methods, practices and tools to build, maintain and improve systems. “Works on my box, ops’ problem now” has no place in this movement, and the entire technical organization takes responsibility — together — for delivering great quality and service to customers.

Engineering organizations often think about problem-solving in terms of technical constraints: do we have enough server capacity? Enough bandwidth? Enough test coverage? But DevOps is also about engaging with the human side of shipping: do responsible teams have the right communication processes? How do we minimize error, and how do we effectively learn from mistakes without compromising morale? Patrick Dubois characterizes effective DevOps champions as “ambassadors, peace makers, facilitators and communicators,” who build bridges across the organization and rally teams around a common cause.

Why Isn’t DevOps a Job Title?

For many organizations that are moving to a DevOps model, it represents a fundamental culture shift, and the messaging around it is important.

The definition above doesn’t fit on a business card. DevOps is not about software developers taking over the job of ops nor ops taking over the job of developers. And it’s not just about shared tools (though that is part of it). It’s about breaking down organizational silos, scaling and automating processes, and leveraging best practices from both the development and operations world to ship better stuff to customers.

Good DevOps work requires testing, iterating and, even, breaking things. That needs to happen quickly, without friction and, most importantly, without blame. Defining someone as a “DevOps manager”or creating a “DevOps team” could imply that only those individuals are responsible for DevOps, and, should it fail, those failures are due to that individual or team rather than systemic organizational problems.

As Chip Locke writes, software developers and operations engineers are often different types of people, and trying to combine them into a single role won’t always be effective. When devs and ops are forced into a contrived role instead of encouraged to collaborate across their individual teams, competing values and (sometimes) suboptimal results are the outcome. Additionally, implementing DevOps as a third team that sits between the development and operations teams is a recipe for disaster.

You’re not in Kansas anymore

As organizations have to ship faster, more complex software to an increasingly demanding and quickly changing market, the prevalence of devops will only grow— fluency in the movement will help you collaborate with, hire, and retain great engineers, while pigeonholing it can lose you credibility with your technical team that’s hard to get back.

As the outsider, the onus is on you to educate yourself. Watch the presentations that birthed the movement, read some history, talk with those in the movement. To start you off, here are some of my favorite resources.

A short history of DevOps

10 Deploys Per Day: Dev and Ops Cooperation at Flickr

What is this DevOps thing, anyway?

The Agile Admin: What is DevOps?

June 2, 2015
Evolution Not Revolution – DevOps in the Wild
Ever heard these questions:
- What is DevOps?
- How do I hire a DevOps Engineer?
- Should we have a Director of DevOps?
- Am I doing DevOps?
- Why is DevOps failing in my organization?
More and more frequently, I run into engineers, managers and business leaders describing failures in their organization due to “DevOps.”

Oddly, digging a little deeper, I find that most of these cases are simply failure by substitution. The Operations team was failing, so they rebranded it DevOps. Alas, buzzword compliance was unable to change the trajectory of the team and the buzzword was blamed.

DevOps today is–still–an ill-defined set of practices closely associated with automation and operations. If you accept this as fact, then DevOps can neither fail or succeed. If we want to measure the success of the DevOps movement in an organization, then we need a definition that leads to accountability.

A Definition for DevOps

The DevOps movement, unlike Agile, lacks a manifesto. To fill that gap, I assert that DevOps is a philosophy and that its base definition is:

DevOps is the way in which a technology organization embeds itself in a business to the benefit of that business.

The business in question need not be a technology company such at Docker or IBM. Indeed, all companies today are technology companies whether they like it or not. (1)

In this and future articles I will write about philosophy, models and implementation. In short, a philosophy is what I reason from to create models of behavior. Models inform the actions taken in an implementation. Implementation without philosophy leads to failure. Jingoistic adherence to philosophy without accounting for new technology leads to failure. Balance must be acheived.

As an example of this sort of failure, take a lesson from project management. Many shops adopt Jira because it can do anything. Since the tool can do anything, that means their workflow is capable of anything! Problem solved, QED. We all know tools are not process. When we look at our own track records of instituting change. too often the change stemmed from tool choice, not critical thinking about what was to be accomplished.

Tools should reflect the philosophy they are implemented to support. Without that philosophy tools will fail. The more complex the problem or tool, the more spectacular the failure. In this example, Jira did not fail, leadership failed. Specifically the thought leaders entrusted with workflow management.

Are you Doing IT DevOps Style

DevOps is about evolution. If you are doing IT DevOps style, then you are asking questions like:
- What should we change next?
- How do we create a sandbox to measure the impact of the change?
- How do we create demand for the change once vetted?
- Who do we need to be patient zero?
- What cultural paradigms are we shifting and how do we ease this for teams?
While automate-all-the-things is often associated with the term DevOps, automation without cultural shift will result in broader failure, rather than success. Like any technology problem, at its core DevOps models account for their impact on people because businesses are composed primarily of people.

Future Articles

Over the course of the next few months. I will relate my experiences at several companies. Articles will describe:
- What we changed.
- Why we changed what we did.
- What cultural issues we faced.
- What technologies we used and why.
I hope you will join me to learn how the practice of DevOps as a philosophy can lead to millions of dollars on the bottom line, happy bosses, fluffy bunnies and rainbows. If your lucky, you might even become a unicorn, though my own horn has yet to sprout.

The first case study will describe a failing company with three months capital. An amazing team. Some amazing mistakes and, ultimately, some amazing success. Technology decisions driven by the needs of a sales team. Automation driven by a business model. A successful acquisition.

References

(1) The Phoenix Project – Gene Kim, Kevin Behr, George Spafford
(2) Good to Great – Jim Collins

About the Author/Boyd E Hemphill

Boyd E Hemphill is Director of Evangelism at StackEngine (link). , an enterprise grade, Docker operations management software company. DevOps raconteur and organizer of community events in Austin, find him on Twitter or LinkedIn.
February 4, 2015
Buzzword abuse: The anatomy of a DevOps Engineer
Once, people used the word genius only when describing someone who really was a genius. Someone with extraordinary intellectual and perceptual capabilities. Today every parent uses this word to describe their, likely cognitively regular child – and this term has lost any good taste. I find the same trend holds true for DevOps. And yet, that doesn’t stop everyone from saying the word DevOps, a lot (and more often than not, in a completely wrong context).

The Problem

Many recruiters are now looking for “DevOps Engineers”. The demand for “DevOps engineers” has grown exponentially over the course of the last few years by thousands of %, just a small trend graph from indeed.com, and snippet from Google.

We constantly hear about companies building, “DevOps Teams”, and developing “DevOps Tools”. Everyone wants “DevOps” but have no idea what it means.

The short definition of DevOps is the ultimate business-requirements to customer to business-requirements cycle (often referred to as the best “development to production cycle”). How this would look in code:

(Of course, this snippet presents the problem very broadly and doesn’t take serious bugs into consideration)

All of this, aside from the development process is expected to happen automatically, not affect users at all, and have monitoring that is so exceptionally smart that it always points to the exact problem. Hmmm. What’s described above, is of course…. utopia.

Reality Check. Most companies are more likely in the camp that:
- runs tests manually or not at all
- monitors the wrong things
- reacts to the wrong problems in the wrong manner
- doesn’t improve work processes
- keep doing the above in iterations and trying to set out fires while more fires appear.
- more bad stuff…
DevOps aims to solve these problems.

It is a culture, in which people work together to improve the product delivery cycle.

At its base, it requires good collaboration/communication (with the other teams), familiarity (with the system), control (over features and failures), short dev-to-prod cycles (this isn’t mandatory, but can help to prevent major bugs), and quality testing (‘nuff said). This is practically a great analogy to a good relationship except that it also requires automation (to make all of the above possible), which is something you should probably refrain from in your relationship if you want your belongings to remain inside the house.

The Perceived Anatomy of a “DevOps Engineer”

Let’s look at the following job descriptions.

DevOps Expert

See anything… strange about them? Yes, they want a God.

The Dream Errr…”DevOps Team” is basically a group of:
- Linux Experts (preferably all distributions in the world)
- Coders (preferably Python, Ruby, Perl, Bash, Batch, Powershell, Powerpoint…)
- Adept at CM, CI, CD, NBA and NBC (So they must know Chef, Puppet, Jenkins, Hudson, Travis, Git…)
- Have vast knowledge in Cloud (like.. in the sky?)
- are familiar with Databases (Including high availability, disaster recovery, fault tolerance, fail-over… something like the average marriage)
- Know Storage (WTF?)
- Know Monitoring (Nagios? REALLY?!)
- Know Networks…
- Know Big Data (the bigger, the better)
Bottom line, they are supposed to be a group of people who know everything, can do anything, yet do not develop the application (That’s the Devs Job), nor do they install servers manually (That’s the Ops job).

Don’t even get me started on “DevOps Tools” – Puppet, Chef, Ansible, Cloudify, Saltstack, OpsWorks, Jenkins.. these are all “DevOps Tools”, right? WRONG! They are automation tools! They don’t “DevOps”. They automate, i.e. enable “DevOps”. JIRA, HipChat, PagerDuty, CloudWatch, New Relic… these are communication, collaboration and monitoring tools. You get the idea.

There are no “DevOps Tools”. Developers have development tools because a developer is a profession. Just like a blacksmith has a mallet. Can you define a set of culture tools? Are the pen, the paintbrush, and the violin considered culture tools? No, they are instruments for the writer, painter, and musician to create works of cultural significance.

In the same way, there are automation, collaboration and communication tools that enable the DevOps culture to be implemented into the organizational DNA.

What we tend to mean when we say DevOps:
- ‘We use Puppet to manage our servers’ configuration’.
- ‘We use Ansible to deploy our application versions’.
- ‘We use AWS as our infrastructure’, ‘we use Cloudify for our orchestration.
What we should mean when we say DevOps:
- ‘Our Devs and Ops work closely together’.
- ‘They’re familiar with each other’s work so that Devs know the system they’re writing code for, (and adjust to it) and Ops know the code they’re deploying (and understand how it affects the system)’.
- ‘They develop in short iterations and can deploy fast (both infrastructure and application) to overcome bugs ASAP and create smaller problems if any new bugs arise’ (again, not mandatory, but can help).
- There are many more items in this list… but you get the gist.
This is enabled by:
- Keeping code tidy and well documented so it’s easily understood by all.
- Keeping our code under version control and backed up so that we can always go back to a previous version in our environments, when needed.
- Testing and monitoring the most important aspects of the system rather than the ones that we don’t care about.
- Automating our Infrastructure, because deploying servers and configuring them manually makes them more susceptible to human errors.
- Automating our code deployment so that we can deploy a lot (that doesn’t mean that we HAVE to deploy a lot), without making mistakes.
Where did we stray off course?

Culture is a very abstract and complicated concept. It isn’t as simple and obvious as a tool.

Along the way, we took the tools and skills that are required to implement DevOps and named them DevOps instead. We appended the skills necessary to deal with these tools to a list, created a job description, and from there… the rest is history.

What people refer to as “DevOps people” is usually (not always) a term that describes operations people who know how to code and who automate stuff – “InfraCoders”.

So pretty much, you can’t (well,you can – it just doesn’t make much sense) have a “DevOps Team” or a “DevOps Engineer” because “DevOps” is not a thing.

It is a how. It doesn’t respond to the question: ‘What’s your job?’ or ‘What does your team do?’ it responds to: ‘How does your company do it?’. And most importantly: DevOps, is “DevsWITHOps”, not “DevANDOp.”

Having said that, DevOps is not ONLY for Devs and Ops. It’s for everyone. It’s not about the titles or teams, it’s about the way a company handles the process of delivering a product to production in the best way possible.

The problem with the “everything is DevOps” attitude is that it renders definitions meaningless. If everything is DevOps, then it’s everything and nothing, and de facto has no meaning. DevOps is already a complex concept. Making it mean everything, will make it practically impossible to implement.

Ultimately, it really makes no difference whatsoever what you call your special forces team. You can call them “DevOps” or you can call them Bean Soup. Just be sure not to delude yourself that by constantly using the word DevOps in the wrong context, that your company is doing DevOps, while all you’re actually doing, is using Puppet.

About the Author

Nir Cohen – is an Ops Architect at GigaSpaces working on Cloudify and a co-organizer of DevOps Days Tel Aviv. He’s the brainchild behind the awesome open source tool Packman for package management. Nir loves system architecture, likes to think of himself as an innovative, think-tank type of guy who adores challenges and has an extremely strong affinity to automation and system architecture. He’s primarily driven by researching and deploying new systems and services. To Nir, the most important thing in life is ethics. Find Nir on GitHub or follow him on Twitter.
September 23, 2014