The essence of DevOps: what, who and how

There is a lot of fussing around DevOps today. Experts call it a buzz word; specialists explain the term and describe the implementation tactics, while decision makers have long conversations about DevOps business benefit. So, what is it all about? Does anyone have a definitive answer? Well, no. Still, I`ll try to clarify some things.

Let`s start from the very beginning.

What is DevOps?
Actually, it is all that you have already heard. It is a job title, an approach, a way of organizing and a way of thinking. Yes, it`s all of it. But if we need the definition of the term itself, I would say it is a methodology.

Who are those people behind the word?
Let`s split the word into two parts. “Dev” is used as shorthand for developers in particular, but in practice it embraces “all the people involved in development process”, which is Product, QA and other kind of disciplines. “Ops” is a blanket term for systems engineers, system administrators, operations staff, release engineers, DBAs, network engineers, security professionals, and various other subdisciplines and job titles.

So, technically is quite difficult to call DevOps a job title.

Why does it work?
Here we are coming to the filling.

I guess you happen to hear things like “it works on my side” or “sysadmin built an unreliable platform”, or anything like that. These all are the signs of “us and them” way of thinking. When developers, QA, sysadmins the whole project staff is located in different places, it is quite difficult to pull them together. Usually they don`t work for one idea, the work just to “finish my piece and let it go”. Staff is not interchangeable. Yes, it does not sound very much polite, but this is what actually happens.  This is waterfall methodology.

DevOps paved its way from Agile. DevOps puts emphasis on communication, collaboration and integration between software developers and IT operations. It does not see these two groups as silos who pass things along but don’t really work together. DevOps adheres to their interdependence.

I would add that the DevOps “movement” is characterized by people with a multidisciplinary skill set - people who are comfortable with infrastructure and configuration, but also happy to roll up their sleeves, write tests, debug, and ship features. These are people who make connections, because they can. They have feet in multiple camps and can be ambassadors, peace makers, facilitators and communicators.

This has a tremendous impact on the business. Suddenly the technical team starts trying to pull together as one. An “all hands on deck” mentality emerges, with all technical people feeling empowered, and capable of helping in all areas.

Where DevOps can be applied?
Technically DevOps can be applied to any project type. However, I would recommend it for long-term or mid-term projects. My idea is simple. The more complex system architecture is, the more difficult it is to deploy and maintain it. Hence the more useful DevOps is. Still, this is how I see.

How about the obstacles?
Adopting new approach was never too easy and, of course, there have to be some reasons preventing DevOps from implementation.

First challenge or I would say the unwritten one – doubts. You have no idea how it ends, you don`t know whether your staff can handle it. And in the end, will it pay off? So, it will always be a challenge, an obstacle to say - “yes, we are doing it. The decision is mine”.

As soon as the decision is made, there come other obstacles.
Too many people/departments involved, which entails lack of role alignment. However, DevOps does not live its own life within a company. It needs strong leadership. You should clearly understand that even staff is interchangeable everyone has its own primary role and in case of emergency some employees can pick up tasks outside the role limits.

Another obstacle is that one day there would be a mess with responsibilities. As the same people can be engaged on different project phases, they lose the understanding of who is responsible for which step. And I`ll repeat – strong leadership. Keep track what tasks you assign and to whom, control the “staff migration” among the project phases.

And maybe the challenge that may seem quite painful for decision makers – DevOps requires investment. To jumpstart it, you`ll have to invest in new tools, training of development and operations personnel, and hiring new resources with necessary skills.

Along with those challenges DevOps leads to emerging of entirely new role across IT department. New skills, expanded knowledge improve the whole development process and collaborations across departments. Despite the challenges named above this is a strong positive indicator.

Is DevOps beneficial?
I understand that new is always confusing and challenging, but after all fights things become transparent and far better organized.

Among the benefits I would mention these ones:

• Continuous software delivery
• Faster implementation of changes
• Process automation
• Quicker defects` detection and fixing
• Stable operating environment
• More time available for high priority tasks
• Less time wasted for routine manual things

In fact the whole idea is aimed at business benefit. The core of DevOps lies on speed, quality, control and cost. Speed is crucial “element” to every business strategy – customers just won`t wait. Quality is essential to success and company`s long-term viability. Control provides safety of all operations. I guess, these are the basic principles of any business and DevOps stands for them.

If you are still sitting on the fence to move forward with initiating DevOps strategy, I would add implementation of DevOps triggers faster time-to-market and meeting customer needs.

In a nutshell, it is all about satisfying growing customer demands and creating positive customer experience. This is where companies strive to - the first one to cover customer needs gets the “prize”.

by Artsiom Marzavin
Senior Software Developer