“What is DevOps” – A CTOs Guide
Despite surging demand for DevOps across organizations of all sizes, few seem to understand what the fuss is all about. Fewer still fully grasp its impact and how best to utilize it successfully… but we’ll come back to that in a moment.
I really like Google, not only as a search engine, but as a litmus test for what people are thinking and doing. So while doing research for this article, I turned to my old friend. A quick Google Trend search for DevOps shows just how hot this topic has gotten.
The ranking of searches related to DevOps also paints an interesting picture. As you can see, “what is devops” is by far the most queried search.
One Ri… Engineer to Rule Them All
Modern tech companies know they want to hire DevOps Engineers, most just don’t know how best to utilize them. They hope these unicorns can solve myriad challenges. To illustrate, here’s an example of a recent conversation I had with the CTO of a software company, whose name I have changed.
John: We are going to hire a DevOps engineer.
Me: How will you be integrating them into your team?
(after some more prodding)
John: Well, we want want to automate software delivery and scale our infrastructure.
Okay, fair enough. Automation and infrastructure are general skillsets that successful DevOps engineers bring to the table. If you were thinking along these same lines, read on.
The problem with this statement is that its a somewhat diminished understanding of the value DevOps brings to an organization, and ultimately its customers. DevOps is not there in itself to save money, replace operations, or increase automation. Nor is hiring a bunch of DevOps engineers a cure-all for an organization’s problems, be whatever they may.
As the CTO of a tech company, you may be looking at DevOps to accomplish a variety of things:
- Speed up software development and delivery
- Tight customer feedback loops
- Faster problem resolution
- Continuous Deployment
- Eliminate noise
- Align Dev/Ops
These are important challenges, to be sure. But before you jump the gun and make your first DevOps hire ask yourself, “Are we hiring for a position or transforming the way we build, deploy, and manage our product?” Manage your expectations. If you’re hiring for a position that’s fine, but only under the right circumstances. At Caylent, DevOps is both. It is most definitely a position. That’s because as a DevOps-as-a-Service platform, it is a crucial component to our business.
DevOps should not and cannot exist in a vacuum. In order to be successful, it must be fully integrated across the organization and throughout the entire product lifecycle. The true magic of DevOps happens when you align development, operations, and IT teams in a cross-functional way. It’s often remarked that DevOps is not a role or a tool. This is true. It is a culture. DevOps, done correctly, is a collaborative effort between your whole team. Notice I said team and not teams.
DevOps can trace its roots to the Agile software development methodology. According to Wikipedia, the Agile Methodology
promotes adaptive planning, evolutionary development, early delivery, continuous improvement, and encourages rapid and flexible response to change.
DevOps embraces these principles, and if they sound prescriptive, so should your organization. DevOps is for every aspect of your business. But that’s a separate topic.
So how do you make DevOps work for your business and customers? First, start by understanding the problem you’re solving. Identifying the pain points your development and operation teams face is the first step. If you’re in management, you likely think you know, but it never hurts to ask. Second, are Dev and Ops aligned? Chances are no, at least not completely.
Here’s a simple litmus test to determine whether or not they are:
- Ask the Dev team how long it takes them to push code. If it’s not same-day, you’re not achieving Continuous Delivery.
- Ask the Ops team how frequently code breaks. If the answer is always, often, or sometimes, you’re not performing Continuous Integration correctly.
- Most importantly, ask your customers. Are they happy? Are features shipping often and correctly? Are those features meeting or exceeding their needs? Would they refer your product to a friend? If the answer to any of these questions is “no”, then you are not doing Continuous Deployment.
The Fact Train Rolls On + Promise of the Premise
We’ve talked about what DevOps is, what it isn’t, and why your organization should be using it. Despite all the prevailing hype and myth surrounding the topic, DevOps is here to stay. It has to. As consumers, it is what we expect from our software, apps, services, and beyond. We live in an era of a 24/7, always-on, self-service economy. We expect software to be reliable, ship often, and at least meet, if not exceed, our expectations.
This is the promise of DevOps. It’s not just some position you can throw money at — although you’ll probably need to, anyway — it’s a transformative shift in your organizational culture. I would encourage every CTO to consider it, it’s a great philosophy and a fun way to do things. More importantly, your developers, engineers, and customers will love you for it.
If you’re looking for ways to integrate DevOps-as-a-Service in your organization, give us a try.
Disclaimer: No DevOps engineers were harmed in the making of this article.