What is DevOps?
First, let us understand, what is not DevOps. Yes! you read that right. DevOps is not a Team, nor a role, nor a set of tools, neither a set of questions and answers for your next interview. It is not about zero failed deployments. So, what is DevOps? It’s a mindset, It’s a culture. " DevOps is a culture which combines many practices/methodologies whose primary focus is to break walls between the teams, with ways to fail fast, learn from failures, and focus on shared responsibility”
Let's break it down. The above definition in the simple term refers to the “development of a quality software/product in a short period". Let's go back in time, before the DevOps era! The developer writes the code, they build it and hand it over to QA Team, then they verify a few test cases and approve it for final release for the customer usage. This whole cycle is half-yearly or yearly. Once, after releasing the software, If the customer has any issue with the application, it is raised as a complaint to the operations team, and as this is not related to the environment itself, a defect Id is opened for this and passed to the Developer.
Difficulties in Traditional Approach
What's new with DevOps?
The biggest problem - Developer focuses on new features. Operations focus on the stability of the application. And that's the big wall between them which needs to be broken! So, DevOps helps in bringing together the Developer and Operations team, so that a shared responsibility model helps in delivering features faster, by also maintaining stability. So, some may even define DevOps as a combination of Developer and Operations and there is nothing wrong about it, as it is true. So, as we discussed earlier, there are many definitions for DevOps outside, and all the definitions which include "high-quality production a shorter period" will stand true. Okay, So Far ... So Good.
So, this exactly applies to our current scenario. It is easy to say that we want a high-quality product in a shorter time, but how do we achieve this goal? As we discussed earlier in the definition that DevOps is a culture, that combines many practices/methodologies, namely, Continuous Integration, Continuous Delivery, Continuous Deployment, etc. These are some of the practices which are going to help us to achieve our goal. And each of these practices is in turn supported by several tools. Each practice mentioned above is very important and we are going to discuss each of them one-by-one.
Since DevOps has many definitions, we would like to break it into 3 main categories … DevOps as People, DevOps as Process, and DevOps as Tools.DevOps as People
In a traditional approach, the two teams who are at the opposite end of the line are Developers and Operations. Usually, The operations team is not familiar with developer terms and vice-versa. So, it finally ends up as a blame game between them, which has high chances of the issue heading in a different direction, losing focus on the important stuff. DevOps as People help us in overcoming this issue.
So, DevOps members are the ones who have some knowledge about the coding, entire build process, and at the same time aware of the activities done by the traditional Operations team. So, if an issue arises, they will help identify the root cause of it, and forward all the details required about it, to the respective team, so that it can be fixed properly. To put in simple words, DevOps brings the developer's team and Operations team together.DevOps as Process
What is Continuous Integration? In the traditional approach, there will be a team of developers who would be working on their assigned tasks. Each Developer work on a part of the code, and in the end all the code is combined into one and we start building the code. If the build fails, then it becomes a tedious task to identify which part of the code, written by which developer, is causing the issue and it delays the work of other developers too, because they cannot move forward unless the issue is fixed. This may have a potential delay in the product release and clients will not be happy, as the expected deadline couldn't be met. So, we will take the same scenario but from a DevOps perspective.
The same set of developers working on the specific task assigned to them. Instead of merging it all in the end at once, what we do differently here is, we will have a centralized code repository to store the application code. Once the developer has completed his task, he will commit his code to the centralized repository. We will make a configuration in such a way that, for every commit pushed to the repository, an automatic build is triggered to validate the code. This build will be happening in Jenkins (open source automation server).
We will get the results of those builds within a minute such that the errors in the code can be identified immediately. In this way, we can also be sure that which developer's code exactly caused the error. So, Continuous Integration is a practice/process which helps us to identify the errors in the code as quickly as possible, by triggering as many builds as required. What is Continuous Delivery? In the traditional approach, once the application is built, the application will be deployed in lower environments manually. After this, it will be validated with functional and non-functional test cases. And then it will be approved for deployment to production environments.
In continuous delivery, this manual process must be automated for making application versions ready for deployments. What is Continuous Deployment? Well, this is almost similar to what Continuous delivery is, except for one major change in the last step. In large organizations, as far as lower environments are concerned, we can risk the deployment of the code immediately after the Continues Integration step is completed. Because, even if something goes wrong, it has no direct impact on the customer. But whereas in Production servers, that is not the case. We cannot risk anything causing customer impact. So, the last part of the flow, deployment of the application is done only on a specific release window, so that customers are informed.
But for startups who are building the release pipeline from scratch, they should aim for continuous deployments. Natural maturity in DevOps is to move from continuous delivery to continuous deployment practice.DevOps as Tools
To support the DevOps mindset and to have DevOps processes in place, we need tools, let's look at a typical set of tools used, this is not exhaustive, but should give us an idea!
Source Code Management: As the name itself indicates, these tools help us in managing the codebase of our application in a centralized repository, that can be accessed and modified by developers at the same time. GitHub, Bitbucket are some of the popular tools that are being used currently.Continuous Integration: Earlier we have mentioned that we can trigger a build of each commit made by a developer, integrate the work of other developers, and detect immediate errors if any. Jenkins is the most popular Continues Integration tool, which helps us to achieve this.
Containerization: All the required packages that are required to run the application can be grouped in a single docker file, which in turn helps us to build images out of them. We can simply compare the Docker images to the .exe files we get when downloading a particular application for Windows. Once we run these images, it helps us to run containers, that run the application along with its dependencies. We will discuss more on docker in future articles.
Usually, a huge application will be broken down into small docker containers, and to manage a large number of containers, we can use “container orchestrators” like Kubernetes. Selenium is one of the famous testing tools that are used in the CI process and Jenkins can also be used as a release tool.
Configuration Management: CM tools help using configuring the servers based on the minimum requirements for the application to work properly, like a specific apache version, DB version, application property files, etc. Some of the famous tools that help us in achieving this are Ansible, Chef, Puppet, etc. JIRA, ServiceNow are some of the ticketing tools which help us on the operations side.
Monitoring: Once the application is deployed to different environments, the main and difficult task comes next. We should be aware of the spikes in an application for reliability and performance. So that we can act proactively before customer complaints. We can monitor different metrics like CPU utilization, Memory consumption, Storage, etc. Some popular monitoring tools in the market are Prometheus, new relic, Datadog, etc.
So, this was my Definition of DevOps, I hope you
enjoyed reading the article. If you have any Questions, appreciation, or any
suggestions, do comment down below. Do check out my article
No comments:
Please let me know if you liked the post. Do share it with your friends