DevOps is no longer a buzzword. It has evolved big time since many of us thought it was just a catchy word in recent times. In layman terms, DevOps is a mixture of the two words development and operation and its main purpose is to shorten the life cycle of software lifecycle management by promoting collaboration, communication, and integration between development (application/software engineering), technical operations, and quality assurance (QA) teams. DevOps is a never-ending process of continual improvement. Since today a lot of people perceive different meanings on DevOps. In this article, we will see what is DevOps in simple terms.
What DevOps Is Not!
Before emphasizing what is DevOps, let’s talk about what DevOps is not. Many people may have some misunderstanding about DevOps.
- DevOps is about automating Build and deployment – Nope it is CI/CD
- Isn’t that just a new term for Agile? – Nope it is a different driver, different goals
- DevOps is about more Tools! – No, Not at all. Using tools such as Docker or Jenkins does not mean that you are doing DevOps.
- It’s a mindset thing – No
- You need Kubernetes for DevOps – No, you don’t
- It’s about teams that mediate between Dev and Ops – Not always true
- DevOps is a role – Yikes No. Although most of the companies have a position as a DevOps engineer, it does not mean that DevOps is a position. It is a collective term for a class of engineers.
- DevOps is the Body of knowledge. – No
- DevOps is Innovative Framework – Nope
- DevOps is a Silo Entity. – No
What is DevOps in simpler terms?
From my experience interacting with DevOps guys, When I ask What is DevOps?, their answer usually starts with tools that they were using like Jenkins, Kubernetes, Docker, Prometheus, and so on.
DevOps is not only about tools, it has 3 components: People, Processes, and Tools. It is more about people on how they collaborate together. Before that, adopting DevOps requires people to be onboarded and involved in creating the process (differs based organization to organization) and then choose the right tool which suits the process.
Note: You should not propose tools and then ask your team to tailor the process respectively.
So what is DevOps? There is actually no authoritative definition of DevOps. Over time, the industry also has this saying: “If 100 people are talking about DevOps, DevOps may have a hundred meanings”. Anyway, no matter how many meanings there are, what I want to say is that the most fundamental definition of DevOps is basically similar to below
DevOps is a set of practical methods that shorten the time from submission to deployment of system changes to the production environment under the premise of ensuring high quality.
The Three way of DevOps
As per the DevOps bible (“Phoenix Project: A Novel about It, DevOps, and Helping Your Business Win”), The most followed principle is The Three Ways. (the core of the DevOps patterns that can be derived from). This model was proposed by Gene Kim and Mike Orzen. Gene Kim is the author of “Visible Ops” and “The Phoenix Project”, and Mike Orzen is the author of “Lean IT”.
The three ways proposed mainly include these contents:
- System Thinking
- Increasing the feedback loop
- Culture of continuous experimentation and learning.
The three ways are detailed with illustrations.
System Thinking
In the first method, systematic thinking. It mainly tells us that in the value chain, we should focus on the Holistic view of the entire Pipeline instead of optimizing a part of the value chain. Meaning, Say you are trying to optimize performance in a certain part of component or system resources, which can cause the performance bottleneck to shift to some other unexpected place. Therefore, you should optimize the problem from the perspective of the overall system and that is what the core of DevOps is (systematic or Holistic optimization).
Takeaways
- Minimize Cycle Times
- Holistic View
- Never pass defects downstream
Amplifying Feedback Loops
The second method is a closed loop of feedback. It is to create, shorten and amplify feedback loops between the various parts of the organization. Let us take a simple bug to describe, say if the bug is discovered by the developer before submitting the code to the source code, not by the tester. In this way, a lot of time is saved in the time needed to modify and fix the problem. Say if the bug is discovered by QA or by the customer after the software is released, the turnaround time will be high in fixing the problem and a lot of time will be consumed if it is discovered in later stages.
Most people think Ops work is to give feedback to Dev and it is wrong most of the time. Because sometimes defects can be rooted into something which went wrong further upstream. In these scenarios feedback doesn’t work, dev and ops need to sit together and work on what could be done better with upstream.
Takeaways
- Create right to left feedback loops
- Create Quality at source – Avoid downstream defects.
- Shorten and amplify all feedback loops
- Embed knowledge where needed.
Culture of continuous learning
The third method is to create a work culture that can maintain continuous experimentation and learning. You and your team should be willing to learn new things, do small experiments and learn from failure, rather than get stuck in an endless loop of constant analysis. But not just to learn new things, but you also need to combine the skills and tools you have mastered in your work with practice, integration, and continuous practice.
To master the skills you need to do the repeated practice. Say you have discovered a new technology, you need to learn and try to use the new technology. You may have heard, “Working code wins” and if it fails, you need to do more attempts by learning from failures. Concluding repetition and practice is the requirement for mastery.
Takeaways
- Foster continual experimentation (Experiment, take risks and learn from success and failure)
- Allocate time for improvement of daily work
- Introduce faults into the system to increase resilience.
These three methods provide a framework to help you obtain the core DevOps value and apply it in actual work. As you continue to progress in DevOps, always think about problems systematically and globally.
Why DevOps was needed?
In today’s world software delivery is the heart of today’s top technology trends that say it can be anything .. ex: Big data, IoT, Cloud, Social Business, Touch commerce. So in order to get a product from “Ideation” to “Realization”, we need applications to be delivered quickly and frequently to production.
So to give a better insight into the above terms, we have to look back to our traditional approach towards software delivery. Years back DevOps didn’t exist, Application development was following the Traditional model. Developers, Operation, and Maintenance resources are separated, and the software development process is divided into multiple independent links, which are executed by different Resources/Teams.
So the challenge here is to get the source code to production. It was taking several hours and even months to get the product released to the customer in traditional release management. This made the software development process need to pay high communication costs. To address this problem, Resources with different skills are grouped in the same team and worked for a common software development goal.
Then the philosophy has changed from “Dev and Ops” to “DevOps” which brought DevOps mindset, practice, and culture which helped to resolve the issues between different stakeholders and improved collaboration and communication between different teams and played an important role in automating and optimizing entire delivery process (Code -> Build -> Test -> Release- > Operate -> Code cycle) more frequently to serve the customer in better ways.
What is the relationship between Cloud and DevOps?
There is no necessary connection between these two. DevOps can then be practiced with virtual machines / traditional machines. However, some of the capabilities provided by the cloud, especially Fast and Flexible provide a lot of convenience in DevOps practice.
Mainly,
- The ability to simply create and switch (migrate) environments. This makes the process of development, testing, and deployment much simpler.
- The ability to easily create virtual machines, Managed services. Resource management and updates become simple.
- Database management is easy in terms of Cloud.
What is DevOps Engineer Salary?
According to Hired interview data, DevOps Engineers earn an average annual salary of$146,567. The salaries of candidates in this role range from a low of $90,000 to a high of $210,000, with a median salary of $147,000.
Below is the small infographic with the DevOps Engineer Salaries by region. DevOps Engineers are highest in demand in SF Bay Area, New York, and London.
How will an organization benefit from DevOps?
DevOps has become a universally chosen culture because it allows for better collaboration and more efficiency across the entire software development and deployment lifecycle. Of course, we require the cultural change should happen for a company to be successful with DevOps. Below are some of the Business benefits and Technical benefits of DevOps in bullet points.
Technical Benefits
- Speed (Frequent and Faster product delivery in a short span of time.)
- Rapid Delivery
- Reliability
- Greater collaboration between teams (Dev/Ops/Business)
- Scale
- Continuous Integration/Testing/Delivery/Deployment
- Automation.
- Security
Business benefits
- Enhanced customer experience. (ability to react and adapt in an agile way)
- Increased capacity to innovate (capacity to innovate the business with lean principles)
- Faster time to value (goal of DevOps is to deliver this (any) value faster and more efficiently)
- Efficiency
- Stability through feedback at the source.
Main key objectives of DevOps
The main purpose of DevOps is to make the delivery flow more efficient by developing and automating the continuous delivery pipeline. Below are some of the key objectives to delivering this (any) value faster and more efficiently
- Faster delivery of Environments.
- Faster feedback loops.
- Fewer failure rates of new releases.
- Stable environments.
- Control of quality.
- It helps to avoid ad-hoc work and failures.
- Handles release failure without losing live data.
- Maintain SLA inconsistent way.
- Continuous monitoring of applications and infrastructure.
- Version control of applications and infrastructure code.
- Rollback and Rollout.
- Automated config management.
- Deployment Automation
- Automated Testing workflows.
- Automated Application Workloads deployment.
- Automated Code Coverage workflows.
- Security.
- Cross-functional teams
My Two Cents
In my fifteen years of experience, I have practiced and worked in various technologies and tools. Among that, there have been some revolutionary changes. One of them is migration from a monolithic codebase to cloud-based Microservices. Another one of them is derived from the practice surrounding DevOps. From my experience what technology looks like today is not what technology looked like 10 -15 years ago, If you want to transition to a DevOps role my recommendation would be
- Focus on the process, toolset/technologies can be easily tailored.
- Start with any one programming language.
- Continuous learning is the key to progress upwards in your career.
- Explore Branches of DevOps: SysAdmins, IT Ops, Cloud Ops, SecOps, DevSecOps, NoOps, DataOps, SRE, BizOps, MarketingOps, FinanceOps, Other Ops.
Note:
Keep yourself updated with the current state of DevOps which will help you to understand how companies are using DevOps practices.
- Google’s DORA State of DevOps Report 2023
- Puppet State of DevOps Report 2023
List of Best DevOps Books
The below list contains a list of books covering DevOps concepts and how to implement the same in your organization considering the scale and other aspects. Following is the list of popular books in the DevOps family.
| Book Name | Description | Author |
| The Phoenix project | A Novel About IT, DevOps, and Helping Your Business Win | Gene Kim, Kevin Behr, George Spafford |
| Designing Delivery | Rethinking IT in the Digital Service Economy | Jeff Sussna |
| Lean Enterprise | How High-Performance Organizations Innovate at Scale (Lean (O’Reilly)) | Jez Humble, Joanne Molesky & Barry O’Reilly |
| The Lean Startup | How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses | Eric Ries |
| Implementing Beyond Budgeting | Unlocking performance potential | Bjarte Bogsnes |
| Release It! | Design and Deploy Production-Ready Software | Michael T. Nygard |
| Domain-driven design | Tackling Complexity in the Heart of Software | Eric Evans |
| Building Microservices | Designing fine-grained systems | Sam Newman |
| Continuous Delivery | Reliable Software Releases through Build, Test, and Deployment Automation | Jef Humble, David Farley |
Closing Notes
The word DevOps is a portmanteau of two words development and operations and it promotes collaboration, communication, and feedback between different teams such as Dev team, QA Team, DevOps Team, Automation Team.
Also, there is nothing like a “DevOps Engineer” or a “DevOps Team” because it is not a thing. However everyone in the industry now got used to the term “DevOps engineer” and as long as you understand the DevOps philosophy, these titles don’t matter much.
Wrapping up the bird’s eye view on DevOps for Layman. We have gone through what is DevOps and what not DevOps is. More specifically why we need DevOps in the first place. We then explored the core of the DevOps patterns along with DevOps resources.
Without further ado let’s move to part 2 – DevOps Lifecycle and Best practices.
