How DevOps culture could be the engine upgrade your Organization needs
You probably have heard of DevOps. Heck, you probably have implemented it until some point.
And if you didn’t, what are you waiting for?
DevOps is a culture – a cooperative culture between development and IT operations. The better the cooperation between these teams, the faster will be your response to market demands and the better and reliable your software will be.
But all of these intangibles should, and do, flow down to the bottom line. Which means that any well-designed program should include a healthy perspective on how it creates business value ROI.
These are perfectly valid statements that should be made not only for DevOps, but any implementation on scope. In this short handbook, we hope to give a brief overview of what is a real value of it and why you should have adopt it sooner.
What should I expect by Investing on DevOps?
“I’ve got this idea, it’s a philosophy and a movement and a cultural change and it’s going to make our company better.”
“I suggest we take advantage of AWS ECS Capabilities and the new Capacity Provider functionality, (…)”
I’ll lose your attention span if we start like this. Not because you don’t care, it’s just because it’s not your usual vocabulary. In any project, idea, improvement you make you should adapt your pitch according to the Audience, and DevOps is no different.
Besides having a strategy, and I mean a phased e clear plan, with timelines and clear objectives, it’s important to know what is the business’ impact, how it will create value what are the costs and how will recoup the investment.
So which are some of the symptoms that you need some kind of rework on how your processes?
You may think that you already have a solution to circumvent these problems or that you are already so used to it that you don’t see value on changing what is working, but if you’re able to visualize your savings in scale by updating any of these pain points, you might change your views.
Measuring DevOps Value
This is kind hard to tell, but DevOps value isn’t measured because it can’t be. You should be wondering “You just told be it’s important to know every ins and outs of any implementation”. And you’re right.
While it can’t be measured as itself, all your other projects can be. The difference between the value before and after of all the products and projects you develop and release is the value of DevOps.
It’s kind of utopian to measure DevOps value before & after, basically because it’s not some kind of plug & play tool. But we can split DevOps into smaller problems: For example, if you’re implementing a new centralized Log system to aid developers find & fix bugs, measure how much faster issues are found. And there you have a subset of the value created by DevOps.
And a DevOps mindset has a strong impact on a widely spoken concept that is IT performance. But How?
There are many “IT Performance” definitions, but since we’re talking DevOps, I would like to focus in two concepts that you should be aware:
These two concepts are the main drivers of your IT performance. And we can break it down into 4 main KPIs:
There are many more KPIs that we can keep in check (Deployment time, # customer tickets, error rates, etc) but we control these 4 main metrics and try to constantly improve them, we are on the correct track! But how can we do it? As I said before, DevOps is not a plug & play product, and as you may know, every business is very unique in it’s own way and it should be aligned with the organization objectives and limitations.
There is a plethora of tools & concepts that would make this endless, but I’ll leave an overview of the concepts that DevOps aims to fix:
There are many more concepts, such if limits on Work In Progress are set, how many homegrown scripts you have, If training developers on Ops and the other way around is set, etc. Again let me warn you: You can use all of these tools and not have a DevOps culture in place, or don’t use any of these and be DevOps proficient. The most important thing is communication, processes and people.
One other thing is if you’re going to invest, you also need how will you recoup the investment and profit on top of that.
The following equation explains itself:
You can expect direct savings on developer time and indirect savings on many other fronts, depending on the subject of your business. Let me frame it on five main points:
There’s many ways to setup your “DevOps Team”, but there’s not better explanation than these guys over at devopstopologies, where they talk about the do’s and don’ts of how to setup your team. There are some topologies that we can highlight as the more frequent:
Type 1 – Dev and Ops Collaboration
Smooth collaboration between Dev teams and Ops teams, each specialising where needed, but also sharing where needed. Needs quite substantial organisational change to establish it, and a good degree of competence higher up in the technical management team.
Type 3 – Ops as Infrastructure-as-a-Service
Organisations with a fairly traditional IT Operations department which cannot change rapidly and for organisations who run all their applications in the public cloud. A virtual team acts as a source of expertise and acts as a does most of the communication with the IaaS team
Type 4 – DevOps as an External Service
Some organisations, particularly smaller ones, might not have the finances, experience, or staff to take a lead on the operational aspects of the software they produce. Dev team might then reach out to a service provider to help build test environments, automate the infrastructure and advise on operational issues.
Type 5 – DevOps Team with an Expiry Date
This temporary team has a mission to bring Dev and Ops closer together, ideally towards a Type 1. The members of this team ‘translate’ between Dev-speak and Ops-speak. Long-term responsibility should not be given to the temporary team, otherwise it may become a silo itself.