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? It's 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 needs 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!
Verdict
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.
References
I’ve listed a few resources for any prospective DevOps can consume on their own time.
The Phoenix Project: Must book to read for DevOps.
DevOps Bookmarks: A list of really useful Bookmarks categorized.
Continuous Delivery: Solid Reference.
DevOps For Developers: A good choice if you are already a Developer.
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.
Top comments (4)
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.
This is the exact opposite of DevOps, which mandates the shared ownership of all these things by ops and developers. If an organization is practicing DevOps, developers should be heavily involved in all the items you listed.
"DevOps" is not a role, it's a methodology. What you've described is a traditional sysadmin role.
This comment is correct. If you have a devops role or org, you are doing dev/opsdev/ops. This isn't necessarily bad, though. This can be viewed as a first step in a journey to the end goal of forming true devops teams, and creation of SRE teams.
Chris doesn't a methodology relates to practice thus relates to a job responsibility aka concrete, actionable steps someone can take toward implementing or improving a DevOps culture in their work environment?
This is what I was getting at: You cannot hire a "DevOps" in the same way that you cannot hire an "Agile" or a "Waterfall".