What DevOps really is? A developers perspective.

Servers… your home
Whether you are just starting your career in Development or you have a solid portfolio of projects and you are thinking of switching to DevOps, I’ve written this article to express my point of view of how a DevOps wannabe could survive in this cruel world.

I’ve recently started reading The Phoenix Project and through the early chapters, I’ve recognized quite a few patterns that I’ve encountered in my career. Although I’m not looking forward to becoming a DevOps guy, I recognize the extreme significance of having a team of DevOps within an organization so that us developers should never have to deal with operations, deployments, configuration management or change management.

If I were to start as a DevOps though here is my perspective of how things should be done and should be dealt with.

You have a Goal

To Eliminate Waste through a Culture of Automation, Systems Monitoring and Sharing of Information across all Business, Development and Operations Corporate Divisions

Yes, this is a really important goal. Critical I might say. You need to ensure that IT Operations and Development are working together and not set apart from each other. It’s not as easy as it looks like in theory.

Those first words about eliminating waste came from Lean Six Sigma which is a methodology that relies on a collaborative team effort to improve performance by systematically removing waste and reducing variation.

This means that you have to Communicate with upper or lower management to pin point and remove all annoyances and waste that fall in your path.

Stability is your number one concern and you must be religious to keep your standards high. Otherwise, you will be spending your nights in the server room.

You are the glue that binds the Internal Divisions of Business, Development, and Operations. If that glue thins the business is screwed. That takes us to the next observation.

When Disaster strikes make sure you are covered

No, I don’t mean covered like that…

Sooner or later the disaster will happen. Will it be a patch deployed to production on new years eve when everyone is drunk, or a dismissed employee triggering a logic bomb, buggy software or external factors can contribute to the problem.

One important thing to realize is:

Complex Systems Fail.

What do we mean by complex systems? Anything that contains on average more than 7 nodes or components that interact with each other as part of the whole system.

Why 7? Its because of its the perfect number of items, tasks or interactions that we humans can manage at the same time.

What is a node or a component? It’s anything that has a logical boundary such as a UI Web app, a backend service, a database server, an Operating System, etc. As you imagine even a simple 3 tier system is complex thus it will fail.

So in order for you to cover your self its imperative that:

you need to optimise for sleep…

What it means that you need to ensure everything is automated. If you think you finished automating automate more.

And what I mean by automating:

  • Running tests: All test cases weather unit, e2e, system whatever should be part of a pipeline that makes sure nothing breaks in case of failing tests.
  • Collecting Metrics: All metrics, tracebacks, monitoring data should be running in the most non-obstructive way and not consuming resources. Logs should be rotated and collected to a secure place.
  • Running Reports and Alerts
  • Self-Healing: Software that runs on the server need to make the necessary adjustments to restore itself to normal operation in case of failure.
  • Back-ups

And that only the minimum requirements…

That takes us to another observation.

Document everything

You need to document everything. What I mean by that:

  • Automated: Everything falls back to automation. Documentation is really hard to maintain. You need to have automated scripts that keep a live wiki for every process that exposes APIs, configuration, requirements, validation, etc with no manual intervention.
  • Continuous: Documentation generation should be called every time something changes and needs to be on par with the current environment.
  • Traceable: Documentation should have traceable metadata. Who updated, when it was updated and why.
  • Detailed: Documentation should be as detailed as possible. It’s not enough to write something like “Updated 10 terminals with the latest OS patch”. You need to be more specific like the patch version information what were the steps to apply the patch, what effects were observed. etc.

That takes us finally into another observation.

Change needs to be Controlled

Developers are your best friends here as they are the ones that typically need to be sure that their new lines of code are seamlessly integrated into the organization. You need to work more closely together and automate the deployment process.

This will lead to frequent releases

This is not actually bad as it proves that everything works as a well-oiled machine. You need to be always on top of all the business needs and the current development status so that you plan your releases on time. That, of course, will come with experience, but hey if you love your Job you can do anything!


Ok, you’ve got a taste of what is expected when you run for a DevOps role. Bear in mind that those are just observations from a developers perspective. While you are working on your role, you will find tons of other best practices that you need to follow. This article was just to get you curious enough. I’ve added a few starting points for you to follow.


I’ve listed a few resources for any prospective DevOps can consume on their own time.

If this post was helpful please share it and stay tuned for my other articles. You can follow me on GitHub and LinkedIn. If you have any ideas and improvements feel free to share them with me.

Happy coding.