What is DevOps?
An introduction to Agile Software Development and Delivary
Introduction
In this article, we'll see what is DevOps and how to implement it in our development culture. We'll also see various tools and methodologies that will make DevOps, a DevOps culture.
DevOps is not a tool. DevOps is not a job title.
When we start thinking about DevOps, we think about GIT, we think about CI-CD, we think about the cloud, and many more tools. What if I say, that DevOps is not just some set of tools, it's a mindset or a culture?
Yes, it's a culture of working in small batches to reduce waste and creating minimum viable products to gain valuable insight. To change your culture, you need to learn new ways of how to think, how to work, how to organize, and how to measure.
And also you need to remember that Tools are not the solution to a cultural problem.
Business Case for DevOps
Since the year 2000, fifty-two percent of the Fortune 500 companies have been gone. Fifty-two percent! That is almost half of the Fortune 500 companies that existed in the year 2000, are now gone!
What were they up against? In a word, disruption. It is not if you get disrupted, it is when you get disrupted. Established institutions like banks might think, “Who is going to disrupt me?” You can talk to banks about the need to deploy fast and use continuous delivery, but they are not always responsive.
Then the bank down the street comes out with an app that can take a picture of a cheque and deposit it. Meanwhile, if it takes your bank six months to get your app updated to take a picture of a cheque and deposit it, your bank will lose many customers in those six months. It is not a matter of if you get disrupted, It is a matter of when you get disrupted.
Now, they will say “Oh, the technology disrupted me. I have been disrupted by technology.” But if you think about it... The technology that was available to the disruptors is the same technology that is available to the incumbents because most of it is open source.
The disruptors just had a different business model. And that's the reason they went ahead.
Real-life examples
In 2009, at the Velocity conference, it opened a lot of people's eyes. John Allspaw and Paul Hammond gave their now famous presentation at the Velocity 2009 conference, entitled "At Flickr, they do 10+ Deploys per day". This opened a lot of people's eyes to the possibility of what could be if Dev and Ops worked together to move things out instead of Ops being the gate for Dev.
In January 2011, Etsy talked about deploying to production 517 times that month. What they said was that in January 2011, a month, they had over a billion views, their code was committed by 76 unique individuals and deployed to production a total of 517 times. I did a little back-of-the-napkin calculation and estimated that they are deploying every 25 minutes.
How are they doing it?
Chad Dickerson, the Chief Technical Officer of Etsy, said that Etsy’s deployment environment requires a lot of trust, transparency, communication, and discipline across the teams. He and his teams, work together for a common goal, not working against each other in silos.
So, to achieve faster deployment and faster delivery, the entire team needs to be in sync and working together, and DevOps opens the door gate for that.
History of DevOps
Let's talk about application evolution for a moment.
In the past, there was Waterfall, with its monolithic applications deployed on physical servers.
Then at some point in time, we migrated to Agile and used Service Oriented Architecture and virtual machines.
Then DevOps followed. Now we are using microservices deployed in immutable containers. This has been an incremental evolution.
We broke the monoliths into services. The services were still large, using Service Oriented Architecture, but we had embraced services as a design concept. Then we had virtualization and the Cloud. This made things much smaller.
With DevOps, we have evolved again into microservices and containers to deploy them in.
The issue with the Waterfall Method
Before Agile or DevOps, software developers used the Waterfall method to deliver applications. So then what happened?
Every stage in the waterfall method has its own entry and exit conditions. So every stage takes its respective amount of time before going to the next stage.
For example, in the case of the Design stage, it's not possible to go to the coding stage without completing the proper high-level, low-level, and system-level designs. But while the system design is going on, no one from the coding team has any ideas. So, when the design is handed to the actual coding team, many design flaws come in and encounter more delays.
Another huge problem is that all the teams are working separately. So, they are unaware of the impact on each other. The coding teams don't know the impact of their code in integration. So when the integration team fails, the entire process swims back to the coding stage, hence more delay.
Extreme Programming
In 1996, Kent Beck came along with extreme programming. Extreme programming is based on an iterative approach and used feedback loops.
The idea was to improve software quality and get feedback quickly: get something out to the customer, get feedback quickly, and then iterate on it. Extreme programming was intended to improve software quality and responsiveness to changing customer requirements. Kent Beck’s Extreme Programming was one of the first Agile methods.
Agile Manifesto
In 2001, seventeen software developers met in a resort in Snowbird, Utah to discuss these lightweight development methods. What they came up with is called the Agile Manifesto.
The Agile Manifesto emphasized valuing,
Individuals and Interactions over process and tools;
Working Software over comprehensive documentation;
Customer Collaboration over contract negotiation;
Responding to change over following a plan.
In Agile development, requirements and solutions evolve through a collaborative effort of self-organizing cross-functional teams and their customers. It advocates adaptive planning, evolutionary development, early delivery, and continual improvement. It also encourages rapid and flexible responses to change.
In Agile development, Work is done in increments called sprints. Say, we plan for the next two weeks, and then the two weeks after that, and then two weeks after that. This way, Agile solved most of the problems with Developers.
But being Agile doesn’t solve all the problems. There is still Ops to consider and Agile was in direct opposition to the way operations were being measured. The development was rapid, but the deployment was slow, not just because the physical resources were limited but also because the human resources which were managing the operations were limited. That's where DevOps comes into the picture.
DevOps - Definition
In 2009, Patrick Debois (the father of DevOps) coined the term “development operations.” He said, “Operations is an extension of Agile development environments that aims to enhance the process of software delivery as a whole.” This makes the Ops as Agile as the Devs by working together for a common goal.
DevOps is the practice of development and operation engineers working together during the entire development lifecycle, following lean and Agile principles that allow them to deliver software in a rapid and continuous manner.
DevOps Requires
A change in Culture.
To achieve this, Dev and Ops both must work together through the entire software lifecycle. To do that, we need to change to a culture of collaboration that values openness, trust, and transparency.
A new Application design.
You must adopt a new application design that does not require entire systems to be redeployed just to add a single function. You are not going to be able to deploy these large, monolith applications 10 times a day.
Leveraging automation.
We need automation that accelerates and improves the consistency of application delivery so that we can deploy and deliver our software with speed and stability.
Programmable Platform
Finally, we need a dynamic software-defined programmable platform to continuously deploy onto.
What DevOps is not
DevOps is not just Development and Ops working together. It is a cultural change.
DevOps is not simply combining the Dev team and the Ops team.
DevOps is not a separate team. If we know anything about Agile, we do not make an Agile team. We don’t say, “Oh, we have that team over there. They are the agile team. They make us Agile." No. Instead, the company becomes Agile. DevOps is not a team. It’s just like Agile.
DevOps is not a tool. Many tools support DevOps. These tools can reinforce your DevOps culture but they will not change your culture. We cannot become DevOps by simply buying a set of tools.
There is no one-size-fits-all strategy. It would help if you found out what works for your team.
Finally, DevOps is not just about automation. People think that if they hire somebody who knows all the DevOps tools, then that person can automate everything and make them "DevOps."
Essential Characteristics of DevOps
What is the Goal?
We want to be doing smart experimentation.
We want to be moving in the market with maximum velocity and minimum risk.
This way, we can gain quick, valuable insights to consistently change the value proposition and quality we can deliver to our customers.
Agility: the Three Pillars
DevOps
This includes cultural change, automated pipelines, infrastructure as code, and immutable infrastructure.
Microservices
It includes a loosely coupled application design using microservices that communicate via REST APIs. Microservices are designed to resist failure and are tested by breaking them and failing fast.
Containers
Containers are developer-centric environments that give us portability and fast startup. They also enable an ecosystem that allows quick deploys with immutable infrastructure.
Dimensions of DevOps
Culture
The most important thing of all to focus on is culture! Changing the culture to be agile and distributed is the most important of all.
Culture is the number-one success factor in DevOps. Building a culture of shared responsibility, transparency, and faster feedback is the foundation of every high-performing DevOps team. --Atlassian
Methods
Using a well-suited method for the team is also one of the most important things. A proper method can accelerate the delivery time and can also increase efficiency in the team.
Tools
Tools are the last dimension of DevOps. When we talk about small microservices, it's very hard for a human to maintain the lifecycle of individual services. There come the tools. Tools automate things, like CI-CD, monitoring, and testing.
Epilogue
In this story, we understand what DevOps is, and what is the history of DevOps. We also got an idea that what is the significance of DevOps in business.
In the next story, we will discuss DevOps itself, from its tools to its culture and methods as well.
If you think that I missed anything, and if you have any ideas or comments, let me know.
Thanks for giving me your valuable time and thanks for reading. I'll see you in the next story.