Guest Post by Morpheus Senior Solution Architect Adam Hicks
Earlier this summer, I had the opportunity to speak at a small, Enterprise IT event in Chicago. To give you some context, this was a conference dedicated to Enterprise Architecture. I chose to speak about two hot-button concepts at once: DevOps and hybrid-cloud. I came away feeling as though my discussion subject warranted further reflection.
My day-to-day role is to evangelize and deploy orchestration and automation solutions in hybrid-cloud environments, and DevOps is the solution du jour for accomplishing this. However, as I prepared my talk, during my talk, and after my talk, I came to realize that there is a critical need to level set on the subject of DevOps.
So what is DevOps anyway?
At one point in my career, I could keep track of the number of customers who were actively engaged in DevOps challenges, but now I see the same thing everywhere. Here’s the typical scenario:
Me: “Mr. Customer, I have a great solution that will finally allow you to deliver self-service compute instances in your private and public clouds.”
Customer: “Can you do it in code? Because our DevOps team wants to deploy infrastructure as code.”
The attuned reader may have noticed it, but most will have missed the issue in that exchange: The customer pointed to a specific team as though this ‘DevOps team’, and ONLY this team, are the doers of the DevOps.
(The customer also implied — not so subtly — that there are some ways of doing tasks that are “DevOps” and some that are not.)
Don’t lose sight of DevOps’ fundamental goals
In my event presentation, I asked how many in the audience were attacking DevOps at their company. I’d put the hands raised at about 20%. Next, I asked how many had DevOps teams or, at the very least, talent with “DevOps” in their title. About 10% of hands went up.
This means that about half of the Enterprise representatives whose companies are engaged in DevOps also have designated specific doers of these deeds.
What, exactly, am I getting at? It’s clear to me that we have radically strayed from the original intent and meaning of DevOps. In a world of “DevOps Engineers” and “DevOps Toolchains,” I get the sense that as devout IT practitioners, we have missed the mark on what this movement is really supposed to be accomplishing.
My goal here is to spotlight the need to see DevOps in its original light, reorient our understanding of what DevOps really is, and ultimately set some goals we can all accomplish.
DevOps creates one team where there were many
Let’s start with a definition: DevOps (a clipped compound of “development” and “operations”) is a software engineering culture and practice that aims at unifying software development (Dev) and software operation (Ops). The main characteristic of the DevOps movement is to strongly advocate automation and monitoring at all steps of software construction — from integration, testing, releasing to deployment and infrastructure management. DevOps aims at shorter development cycles, increased deployment frequency, and more dependable releases, in close alignment with business objectives. —Wikipedia
At its core, DevOps is an organizational movement to increase the value of IT organizations. It began like any other culture shift: In response to different viewpoints seeking to understand a problem. IT is unique in that it is not always the core competency of a company, but in the digital age DevOps has become absolutely an indispensable way to drive business value.
The DevOps pipeline begins with agile methodology, expands to CI/CD, and finally to a DevOps culture. Source: The Modern Developer
10 years ago, Agile and Lean methodologies yielded incredible windfalls for application teams the world over. You’d be hard pressed to find developers today who are not working in an Agile or Lean manner to some degree.
Once the fruit of those trees was exhausted, however, the next pressing bottleneck was in Operations, whose job centers around availability – of services, of data, of infrastructure. These responsibilities stand in stark opposition to development, whose job centers around delivering features.
The answer is fundamentally, strikingly simple: Bring these disparate teams to each other’s respective tables to see how their domain of expertise can help the other to move more quickly while maintaining reliability. This philosophy of working together is the basic underpinning of what DevOps really is.
Why so simple a goal is so difficult to achieve
No matter how easy it is to grasp the concept that we should all get along, the pressing day-to-day needs of our organizations make achieving this goal anything but a breeze. That’s why it’s imperative that the decision to put specific practices in place consider both sides of the DevOps coin. In fact, these practices were once at the forefront of the DevOps movement under the guiding light of the renown Gene Kim, who heralded DevOps’s Three Ways:
Systems Thinking – understand the organization as an organism
Amplify Feedback Loops – consistent, 360 degree awareness of the what, where, when, and why of problems
Culture of Continual Experimentation and Learning – engineers are problem solvers and are best put to use engaging in solving problems
The three general practice focuses can be boiled down to more specific practice areas including CI/CD, Configuration Management, Automated Testing, and the holy grail, Automated Self Service. Each of these areas represents a microcosm of the three ways in practice, with the common goal of creating a finely tuned concert that automates the delivery of business-critical features in an incredibly reliable manner. (they are also at the heart of the Morpheus orchestration platform but this isn’t a product pitch)
At the end of the day, DevOps has to be organization wide. Frequently, it doesn’t work unless it starts at the top of the food-chain. I don’t mean to discourage any eager-beaver, individual contributors from proselytizing the heathens they work with, and by all means they should continue to do so but buy-in for a better way of working together needs to happen in those crucial corner offices of the IT organization, or it won’t get the complete lift.
Most importantly, an organization doesn’t need to go out and hire people or buy tools to start thinking in a DevOps way, even though many of the people and tools with “DevOps” in their tagline bring features that can enable all sides of an organization to play well together. One thing I encourage everyone to consider is that these days it is rare for an organization to simply buy off the shelf software. Our IT vendors look more and more like integral and valuable members of the business. I encourage you to lean on them to help you “do the DevOps.”
If you want to hop on a call to see how Morpheus can bridge the Dev-Ops gap we’d love to chat.
