Understanding DevOps

Suraj Jeswara
6 min readApr 10, 2022

DevOps has been a term that often confuses a rookie. While it can have several explanations I will take the pleasure to explain it to you all in a simple manner here.

Before we get into DevOps. Let us understand a problem that stakeholders used to face while developing a software product. Earlier most of the software was developed using a model known as WATERFALL. For those who are not familiar with this model, it is noted as a series of development steps that are followed in a top to down approach, very much similar to a waterfall as once you are down to the bottom of the waterfall you can not go up in a waterfall model of software development or once you surpass a step of development you can not go back. For example, if you have gathered the requirement and now you are in the Designing phase you can not go back to the requirement gathering phase. So, the manager had to be meticulous in each phase of development ensuring that no loopholes are left.

Fig 1: Waterfall model of software development

To talk of my experience I have worked on multiple projects where the requirements were completely gathered first as SRS(Software Requirement Document) then FRDs were prepared (Functional Requirement Document) and then after scrutiny which happens to go for months we start with the development. 😥😥 This resulted in the involvement of a lot of time in documentation and left with little time for development for a fixed width project. The testing and deployment would also go for long. I remember having raising request for deployment and it would take a day Or two for the code to get deployed in a dedicated environment. 🥲

In the modern era product development has to be put in focus and the time to bring a product to the market has to be minimal to have a first movers advantage. Hence, wasting too much time on planning is ignored and the focus is to bring an MVP to the market as soon as possible. Also, adding automation at some steps of testing and deployment will speed up the process.

My Experience of working in Agile

Having worked for 3 years in the waterfall model I did often hear about DevOps, Scrum, and Agile but nothing made a clear sense to me until I started working in Agile. When I joined my new company I was supposed to work on an analytics platform that had integration of AI, Data Engineering, Backend, and Frontend. It is a huge project with 20+ people spread in 4 different teams working. What I experienced here is that there are documents in word, excel, and PowerPoint describing the features and functional requirements. Less focus was on documenting everything. For instance, when I was assigned a task to create a pipeline/mapping to bring data from some sources and load it into a table, I was not asked to first create a functional document and get it approved first before implementing it. Instead, I read the document and connected right away with my managers if any clarifications are needed following it I start the development. In the end, I do see some loose ends like for some processes we don’t have a concrete step in place to get the data loaded or some code still needs optimization. But by this approach, my focus as a developer is more on actual development rather than spending hours on making documentation on word and excel 😎😎. And as we progress those loose ends could be fixed in later iterations. Along with this there are integrated checks that gets trigerred when code is pushed to repository and issue in code is reported automatically before creating a build. Imagine the kind of hastle this checks reduces 🤓. The changes then get deployed to the dev environment in no time.

fig 2: Agile model of software development

So this is how I enjoyed being Agile. Well Agile is an umbrella term and to develop software in agile there are certain frameworks like:

  • SCRUM
  • FDD
  • XP
  • Kanban

We have followed SCRUM in the project. No need to get confused as SCRUM just adds some terminology and process to AGILE. An analogy could be of a Pizza. If you take a piece of bread apply Flour, yeast, mozzarella cheese, white sugar, tomatoes, and onion to it you get a Pizza. You take Agile and add a few more methodology, rules, and terms to the process of development and you get the SCRUM framework. If you compare fig 3 and fig 2 they would seem similar. Right? At least the loop in the middle is the same for both. What adds up in SCRUM is a few more practice and steps which are: Product Backlog, Sprint Planning, Sprint Backlog, Daily Scrum, Spring Review. Just the way I mentioned you take the bread add a few things to it and get Pizza 😅

We worked in the same fashion in my current project where:

  • we create a list of features to implement(Product Backlog/ToDo)
  • we plan a sprint which is for 2 weeks. In the sprint of 2 weeks, we add some Product Backlogs known as Sprint backlogs.
  • We have a daily call to discuss updates on the work. (Daily Scrum)
  • At the end of the sprint, we have a sprint review.
Fig 3: Scrum framwork

Then How does DevOps comes to the Scene?

DevOps has many confusing definitions but for the sake of simplicity, I would like to describe it as a set of practices to be Agile. It combines philosophies, practices, and tools. There is some slight difference between SCRUM and DevOps but for basics let’s avoid it.

Let us understand this with an example. We recently got acquainted with the aforementioned term product Backlog, which specifies a ToDo list. This toDo list is generally maintained in a tool like Jira or Trello. Now comes the point of collaboration on code and maintaining change history. Here the tool GitHub, BitBucket, etc comes to the rescue. When it comes to automating testing, creating build, and Deployment a CI/CD pipeline comes into the picture which uses some more tools like Jenkins, Chef, and Nexus. Phew!!! So now if we see the defination of DevOps which describes it as combines of philosophies, practices, and tools I guess it makes more sense to you.

Fig 4: DevOps CI/CD

If you have a lingering question in your mind that Why DevOps??? then I should mention that Teams with DevOps Practices:

  • Deployed changes 30 times more frequently
  • Had 200 times shorted lead times
  • Experienced 60 times fewer failures
  • Recovered from errors 168 times faster

Some companies have brought these DevOps tools together under a single roof. One such great example is Azure DevOps. It has developed a suite of tools that helps in following all DevOps practices right from creating product backlogs to the deployment of a project. AWS too has a similar service. Github has CI/CD in place as GitHub Actions. So if you want to go DevOps you must learn first about the ideologies and practices of DevOps and then the tools to implement them. 😎

Hope this blog helped you develop a better understanding of DevOps. Do follow me as I will keep coming up with such interesting blogs for you.

Follow me on Linkedin :)

--

--

Suraj Jeswara

I am passionate about learning new things and sharing it with others. :)