Read this before you start your DevOps journey - The Essence of DevOps

Read this before you start your DevOps journey - The Essence of DevOps

Caution

This is a special note or warning you could say for the freshers in the DevOps world - In order to get the most out of this article, please put your knowings aside as of now - whatever you have ever heard or learnt about DevOps, just keep it aside for sometime. If you are able to do this, I can guarantee you that you will be gaining the most out of this article and can start your DevOps journey very smoothly because these are the foundations.

People just don't know the immensity of not knowing something. Only when you realise that you don't know, the possibility of knowing exists and when the possibility exists, the seeking arises naturally.

Welcome to the world of DevOps. Before you get started with DevOps, these are the fundamentals that you will need to go through in order to thoroughly understand the foundations of DevOps - the WHAT and WHY of DevOps you could say and why it came into existence and why as an IT professional do I need to learn DevOps ? So these all things we are gonna discuss in this article and also we'll gonna touch some buzzwords or DevOps Jargons you could say in this article. So let's get started. In this article, I will gonna talk about the mindset behind the DevOps, some of the principles and terminologies behind DevOps. So in case you wanna get started with DevOps, this will be going to give you a brief overview and a lot of insights about what the DevOps is.

DevOps is an exciting world and it's not just a combination of developers and operations which people usually believe. In this entire article, I will walk you through various DevOps terminologies and mindset and how it can help your organisation to ship better code to the production environment. There is a concept in the DevOps world called "Concept to Cash" which is really popular in the DevOps community and you can also find this sentence in various books and this is one of the most common terminologies which is getting used so often.

So What the Hack Is This DevOps ?

A lot of people believe that it's just the docker and k8s (kubernetes). But does it defines what DevOps is ? I am pretty sure it doesn't. Now a lot other people says it is terraform - to put it in laymen terms - Infrastructure as a Code (IaaC) - no, it's not. Some people say it's all about CI/CD pipelines - no, that's also not what DevOps actually is. So now the question comes - what exactly is DevOps ?

There is no official definition for DevOps but still if I wanna define it, then here it is what the DevOps is......

It's a cultural practice in an organisation by development team and operations team to use each others' tools, in order to smooth out the process of software delivery.

The most important part here is, it's not just a combination of development team and operations team - rather it's more over a methodology or philosophy in order to smooth out the process of software delivery

For example, for years we have seen that the operations team hardly uses the GIT (a Version Controlling System). They have always been keeping those scripts in their hard drives and they always used those scripts whenever required. I mean, that's all they were doing previously.

Before DevOps, we have never seen that the development team is worried about that why their build is getting failed while shipping the code to production. They were always concerned about how to roll out maximum functionalities as much as possible.

So in the world of DevOps, you share each others' work and responsibilities so that you can collaborate with each other and deliver the software smoothly, in a more efficient and in a speedy way. The whole idea is, that we as a team have a same goal - from DBA (Database Administrators), to your operations team, to your networking guys, to your developers, we all have the same goal that we need to push a feature as quickly and as efficiently as possible. But as in a general scenario, we generally don't interact with each other and there is a lot of delay and the wall of misconceptions between these guys, it's very tough to roll out a particular feature into the production.

In a smaller scale, let's say you wrote your code in an HTML file and you just push it to the production and it just works out eventually, but in reality when you are working in an organisation where you are a part of let's say 100 people or 200 people, than it's not that easy to simply ship your code to the production in a smooth way. You definitely need a different kind of approach or a methodology to follow and that's what the DevOps is.

So in this DevOps world, operations team uses a lot of dev tools, the development team is generally responsible for pushing out new features of the product. The testing team checks out whether the things are working as expected or not like performing various kinds of testing onto the feature. And also there might be the deployment team as well. Now this deployment team has a lot of work in hand. A lot of time developers think that hey, we just need to give our code to the deployment team and they will roll out the actual code to the production servers. But in reality, that's not the case. They have a insane amount of work to do in hand. They need to make sure that the system is up and running. There are various OS updates, kernel updates, there are certain agents that needs to be deployed onto those servers and various other updates that the deployment team needs to take care of. There are load balancers that the deployment team needs to configure.

  • What happens when there is an extra load onto the configured environment or server/servers ?
  • What will happen if a given server or servers crashes and why does it crashed ?

So these all things that the deployment team needs to figure out and constantly monitor. And then comes the operations team as well in this whole picture. So this all will now act as a singular team in a collaborative way and that's what the DevOps is all about - making sure that each and every individual not just understands each others' goals but also shares each others' responsibilities.

Now surely there are various tools which are being used in the DevOps community but until and unless you understand about this mindset or methodology of DevOps, it will be very tough for an individual to thrive in the DevOps world as these are called the foundations or pillars of DevOps that you need to know before you get started with it.

Now if you wanna implement DevOps in an organisation, this is what you will need to learn first :-

  1. Core Values
  2. Core Ideas
  3. Methods
  4. Practices
  5. Tools

Unless and until you know these Core Values, Core Ideas and Methods, you will not be able to gain knowledge on the Practices and Tools which are often used.

Why Learn DevOps ?

Screenshot from 2022-10-10 19-53-49.png Now obviously this question comes, that why anyone should learn the DevOps while the Agile methodology is still working fine then why any organisation needs to adopt and implement DevOps ? Yes, the Agile methodology is working fine, but there is a little bit flaw in that methodology. No offence. I am not saying that it's not useful anymore but what I am trying to say is everything comes with certain threshold or limitations you could say and that's how the technology evolves!

Now before Agile, there was something called as waterfall model. Now what waterfall model says is to collect all the specifications or requirements from the client and deliver it all at once. After that when Agile methodology came into the picture and it says, hey, instead of delivering all the functionalities or requirements at once, what we gonna do is we will break the large requirements into smaller segments and we will gonna deliver those small chunks of functionalities one by one as soon as it gets implemented and tested. But the problem with Agile model is, it just mentions about the software development life-cycle and doesn't include anything about the deployment aspect. How are we gonna move things to production environment, how we gonna manage it, how we gonna monitor it ? How we can keep an eye on various parameters while shipping our code to production environment. How are we gonna scale up or down the Infrastructure as per the traffic on servers ? What if our whole Infrastructure goes down ? So these all things is not mentioned in the Agile methodology. It just talks about the practices on how you can develop a software, that's it.

Benefits of Learning DevOps :-

  • Deploy faster - atleast 50%
  • less failure
  • Better Recovery Time

The CAMS Model

devops-cams.jpg

C for Culture

See, one of the core important things about any company or organisation is to create a culture and one of the cultural aspects that DevOps encourage is "Talk to each other". A lot of time we see that the developers team sits at one place, testers sit at another place and operations team sits at some another place within an organisation while working on a common software product. But in the world of DevOps, you will need to talk to each other very often. Because if you are not talking to each other, then the developers will not be able to develop a product in an efficient way because they will not know what's the condition of the Infrastructure or servers and how the product will get consumed on it. So it's very much essential to talk to each other and convey your thought process to each other. You always need to ask your team that what all tools they are comfortable working with before introducing any of the tools. And also there is also one more important thing which I will recommend you all to follow is => Value People over Process over Tools. In the DevOps world, we always value the people first, than comes the process and than at last comes the tools. A lot of beginners make this mistake is that they always want to implement every possible cool stuff that they come across, but that's not a good cultural process.

A for Automation

Remember, automation is not about introducing Puppet, Chef or Terraform. These are all just tools. When it comes to automation, people says that thousands of servers are impossible to manage but do you really need thousands of servers at first place ? How much can you automate the process ? Or should you even automate ? May be your application is just new, so you need just 2 servers or may be just 1 which could handle the traffic of 1000 people or let's say 10,000 people. So in order to automating the stuff, should you be injecting that much amount of Kubernetes config or spin up that much amount of micro services ? So always ask these questions that do you really need the automation and if yes then in what proportion you need. So have a discussion with your team first, then follow the necessary process and then apply the tools in order to follow the process. Also the Automation in the CAMS model stats that you should be automating your stuff in such a way that you can replicate it further.

M for Measurement

It's not just about infra measurement, business measure, client activity and other pointers. You might have heard about that we need to monitor some stuff. We need to take measurements of some stuff. Like for example you need to monitor that how much amount of bill will gonna generate when you use this much amount of resources or services of the cloud for example, let's say you have made some configuration like hey if the bill amount crosses 2 dollars, just notify me. You also need to monitor that when a particular server gets the load or consumes more 80% of the CPU, then just notify me or just divide the traffic onto a different server. So a lot of time in the DevOps world, where you need some kind of measurement in order to monitor your system and take further decision. But this should not be restricted to just infra management, there should be some measures of client activity and incentivise it. The monitoring is not just about the infra, you also monitor how a particular decision is gonna impact your developers and other teams as well.

S for Sharing

Now this is the most important part of the CAMS model. Now what needs to be shared ? It is the sharing of goals and responsibilities so that the shipping of the end product or software becomes a smoother, faster and efficient at the same time.