Principles In Striking The Balance For DevOps
The concept of DevOps has been largely misunderstood and we will address a bit of it today. Somewhere in Nigeria, the discussion about DevOps was brought up in a conversation a Backend engineer said
“DevOps is what you do when you want to retire from being a software engineer, it’s a glorified support role”
I got to do some findings and realized they understood DevOps to be basically about CI/CD and container orchestrations. Well, conventionally, DevOps is defined as some sort of relationship between the developers and operations needed to maintain the code that has been built. Furthermore, some people even say DevOps is about Jenkins, Kubernetes, Docker, AWS and the rest of the awesome tools in the space. While this may seem correct, I beg to disagree.
Now what is DevOps🤔?
From experience, I can say, DevOps is a name given to a culture designed to increase an organization’s ability to deliver applications and services faster than traditional software development processes. It involves taking into consideration concepts like Information Technology Infrastructure Library (ITIL), Software Development Lifecycle (SDLC), Communication, Collaboration, Operational methodologies and of course software engineering. DevOps should be embraced by every member of a team regardless of your role; backend, product manager, designers, engineering managers, technical support, QA and the list goes on.
“In summary, DevOps == engineering culture”
However, it is expedient that I tell you the major principles that bind the DevOps culture, at least from my experience over the years. The principles include the following:
Customer-First
In building a product, the first consideration is taken with the customers in mind so, therefore, no customer, no product. While we build features and make things interesting, the customers initiative must be considered but then there are cases where a team may have competing priorities, how do I mean?
Imagine a case, where a customer reports a bug or a malfunction meanwhile the engineering manager is pressuring for the push of a feature, the DevOps principle entails that the external customer is addressed immediately before any internal plan is considered because they keep the lights on. While making these decisions, either as a contributor or manager, you must consider the impact on the value stream pipeline.
When we get a lot of unplanned work, it can overwhelm our ability to complete planned work. This is something that is frequently underscored in The Phoenix Project by Gene Kim.
Final words here; Never sacrifice stability for new features, always take a customer-first and this is where DevOps processes come into play.
Shared Responsibility
An attitude of shared responsibility is an aspect of DevOps culture that encourages closer collaboration. It’s easy for a development team to become disinterested in the operation and maintenance of a system if it is handed over to another team to look after. If a development team shares the responsibility of looking after a system throughout its lifetime, they can share the operations staff’s pain and so identify ways to simplify deployment and maintenance (e.g. by automating deployments and improving logging). When operations staff share the responsibility of a system’s business goals, they can work more closely with developers to better understand the operational needs of a system and help meet these. In practice, collaboration often begins with increased awareness from developers of operational concerns (such as deployment and monitoring) and the adoption of new automation tools and practices by engineers.
In summary, ops do not blame the developer, the developer does not blame the designer, the manager does not blame ops, QA does not blame the developer, ops do not blame the manager but they collectively work with different inputs and achieve the goal.
Don’t Repeat Yourself (DRY)
The concept of DRY Code is very important and should be considered as a DevOps principle in software engineering. Bolu did some justice in approaching this concept in this article here. Writing sustainable and clean code requires taking the DRY concept very seriously. It reduces complexities and unnecessary stress while factoring in how to make the code implementable. Apart from using the DRY concept in pure code, it could be implemented in IAC may be for moduling, locale creations and many others. The DRY concept is also part of the DevOps culture.
Preserve the sanity of your codebase with the DRY concept
Infrastructure As Code
IAC is the practice of describing all software runtime environment and networking settings and parameters in simple textual format, that can be stored in your Version Control System (VCS) and versioned on request. These text files are called manifests and are used by DevOps tools like Terraform and Kubernetes to automatically provision and configure build servers, testing, staging and production environments.
It is for many reasons but ultimately to make deployment quite easy. It can be used in conjunction with Version control, documentation process from git commits, self-service and finally validation (using code review methods and testing protocols). Some categories of IAC include custom scripts, configuration management software (Ansible, Chef, etc), server templating (packer and the rest), container orchestrations then finally provisioning tools like Terraform and Pulumi.
IAC makes building an architecture very easy from just one code space which is a pure implication of DevOps culture that requires automation and ease
Version Control System (config management)
The version control system just explains how to code will be controlled via git or any other VCS process. Here, we will consider configuration management and some of the goals include
- Configuration identification and control
- Build and process management
- Environment management
- Version control
Configuration management is important to DevOps operations because we always want to be able to build and deploy a working copy of our software at any time. Without configuration management, some item of our configuration may change, rendering our software undeliverable. When we take care to implement configuration management practices, we avoid unexpected failures and can carefully test our code. We manage this with VCS, documentation, an advisory board for changes approval and IAC.
DevOps Culture anywhere should have VCS involved or the target of quick control and delivery may be somewhat stressful.
Applications High Availability/Software Delivery Using CI/CD
CI/CD is a method to frequently deliver apps to customers by introducing automation into the stages of app development. The main concepts attributed to CI/CD are continuous integration, continuous delivery, and continuous deployment. The high availability and software delivery of applications is tied to our talk on a true DevOps culture. Now, we must understand that there are several CI/CD platforms and each has its peculiarities but the main goal of quick code delivery is part of a DevOps culture. Furthermore, you can read up on my choice of CI/CD platform here.
CI/CD is not DevOps but CI/CD can achieve a proper DevOps culture across engineering teams.
Finally, I believe at this point you understand that DevOps is beyond engineering and more of a cultural term. I could have gone on and on about other tools and languages but they are not needed in understanding the culture but required more in further engineering implementation. Another thing I should add is we should not forget the “CALMS” model for DevOps thinking — it explains DevOps beyond the tools and throws insights on true realities. My friend, Tola, wrote an interesting piece on the “CALMS” model and it can be accessed here.
I look forward to hearing from you about any contribution or thoughts on the DevOps culture and remember, I speak all these things based on experiences over the years across several professional teams globally. Just to add, next time you hear DevOps defined wrongly, please forward the piece for ignorance deletion😂.
Now, remember, this article is not only for experts in the software space, even newbies could hop in and learn a lot and that is why I try to make everything clear both in layman and professional terms, so if you have any questions, shoot or you can also reach out to me on Twitter or find me on GitHub.
Thanks for reading ❤️
Please leave a comment if you have any thoughts about the topic — I am open to learning and knowledge explorations.
