DevOps crisis or time for NoOps

Dmytro Shamenko
4 min readFeb 15, 2020

Tell your story…

Oh, Medium, and the readers of this great blog platform, my story begins a long time ago…

If you read my stories often, you may find a pattern, I always show concerns about the current state of DevOps.

This article bit different and nonetheless will touch upon this topic. DevOps methodology is great and able to help in achieving benefits using it and the world is embracing DevOps and realizing its benefits. I will be honest with you, for me, this trend quite scary. For instance, at LinkedIn Jobs is ~141k open position with title DevOps, and this is not the only web service for job search.

But when you will read each of these vacancies, you will also see the pattern.

I’d like to talk about this pattern, especially about what you can see in the block of responsibilities.

Cloud Presence

Cloud is everywhere, and everywhere is not only virtual servers, which you can provision at AWS or Google Cloud to run your apps. I talk about SaaS, PaaS, IaaS.

As DevOps Engineer you required to know at least one of it, but we sure, that this responsibility is only for DevOps? From my point of view, this skill is good to have for every single software engineer or quality assurance engineer. There is no limit who should know it or not. Moreover, when you have someone with whom you can discuss your concerns about the cloud and which service is better to use, you will be able to define the best architecture solution.

Work with CI/CD

From my experience, only half of the employers who wrote this requirement knows what is actually CI/CD. Most of them align this with hands-on experience with Jenkins or TeamCity.

The compilation and delivery of the code is the responsibility of the DevOps engineer? It would not be so sad, but this is true, many people in various companies think so.

Jenkinsfile, .travis.yml, .gitlab-ci.yml — so many different files for different tools where you can describe how is your code should be built. Unfortunately, In my career, I met not so many developers who really want to know how to do it without bottleneck in the company as a DevOps Engineer. Not so many QA engineers know how to include their tests as an additional step in the pipeline.

We have adopted DevOps methodology to improve the speed of SDLC and continue to create bottlenecks.

Metrics, monitoring, alerting, logs aggregation.

Every business owner doesn’t care how is an application running until it is failed. This is not the responsibility of the DevOps Engineer or SRE to create stability for application. This is the responsibility of the whole team. Starting from scratch, as a team of software engineers you should aware of reliability for the application.

Dozens of years ago, when I was an engineer in Datacenter, our todo was to monitor every single hardware in the network and every single server. Now you can add a monitoring layer to your application out of the box. For instance, you can use Datadog, or just use a Prometheus which is already a standard for metrics. The last thing you need to do is just customize your dashboards to your taste and requirements. The centralized logging approach is not new already, and even newbie can understand the value for it. For example, you can have this all when you are using Google Cloud with included service Stackdriver. Do you need some special brains called DevOps Engineer to configure it? Not really.

Kubernetes, Docker

Years ago on conferences was pretty common to ask — “Raise the hand if you are using Docker in production!”. To be honest, every single year the amount of hands grows, really fast. In the first years, it was around 10 raised hands from 200–500 attendees. Now this question is even not mandatory to ask because you can see this requirement in every job posting with DevOps title.

But the same to Jenkinsfile, Dockerfile is easy to use and in my daily work I always happy to remove this gap for developers. As for the Software Engineer, knowledge of how to prepare a Dockerfile for your microservice is nice to have. From my point of view, this should be a requirement.

Kubernetes are tricky but do you really think that C++ knowledge is much easier than knowing how to the maintenance of Kubernetes?

Stateless applications, with right health-checks, will work easily. Scaling policies will cover your back when the traffic will grow and the monitoring will notify you using various integrations.

Afterword

Automating go-live activities, automating processes, help developers to debug problems, building, maintain operations and sysops related components.

This is not a DevOps, as DevOps methodology users we supposed to remove these gaps, Development should know Operations and without any freaking bottleneck deliver software to the production. Now, this is just another name for the Operations department, the guys who will prepare hardware/infrastructure for the application layer and will cover it with a monitoring solution. The guys whom we blame if the production returns 500.

P.S. I keen to find a working environment where software engineers are working with DevOps as a methodology and not as a team. If you have such work for me, please DM me on LinkedIn.

--

--

Dmytro Shamenko

Software Engineer with more than ten years of experience. Systems Architect expertise. DevOps methodology & Golang fan. www.linkedin.com/in/dmitriyshamenko