DevOps Periodic Table Explained | Periodic Table of DevOps Tools | Edureka Live

Hello. Welcome everyone in our today's session of uh DevOps periodic table. In our today's session, we are mainly going to talk about what exactly is DevOps, DevOps life cycle, DevOps periodic table. So, DevOps periodic table is nothing but mainly about the what are the various tools uh tools that are used in the IT industry. So, those tools are arranged in some form of periodic table. Like in our school times, we used to learn a periodic table in which about chemicals, like a chemical periodic table. Same way, these DevOps tools that are being used for development, testing, deployment, automation, all these tools are also arranged in form of some periodic table. So, we will see what that periodic table is all about, what are various tools that are available in the market. But, before that, we will start first with what exactly is DevOps and understanding the life cycle of DevOps over here. So, let's get started over here.

What exactly is DevOps? And these are some of the tools. We'll talk about those tools over here. But, let's try to understand DevOps. So, DevOps mainly constitutes of two keywords. One is the dev, which is stands for your development. Okay? And the other one is your ops, which is operations. Okay? So, dev simply stands for developing a software. Ops simply stands for operating a software, deploying it, managing it, monitoring it. That comes under operations part. So, now, when I say DevOps, so DevOps is not any tool. technology. DevOps is basically a methodology. Methodology or you call it as a process. Process of delivering the product from its raw code. code. Like from my raw code, I deliver the final product to the customer, okay? This whole journey, okay, all basically the process that we follow here is DevOps.

Okay, so DevOps is not any tool. technology. DevOps is a methodology. It's a way of automating your stuff, automating the life cycle of the entire software. Okay, so when I say software life cycle, so software life cycle comprises of various stages. Which is simply called as your SDLC, your software development life cycle. Okay, SDLC. Now, what exactly is this SDLC? Let's talk about that first over here. Okay, SDLC is basically various stages. Like for example, I want to build a product for my customer. up a software. So now, if software, definitely to build that software, I have to go through various stages. Right? Like first, I will be getting some kind of requirement from my customer. Hey, you can you build this? So now, if I want to build a product, I need to ask my customer, okay, what needs to be built, how it what are your problems that you're facing, what is the features that you're looking to inculcate in the product? So basically, the very first stage of my software development is gathering of requirements. We call it as requirement gathering. This is the very first stage of my software building. Now, once I have all the requirements with me, now Now, now next I want to do is I will Once I do show my customer, "Hey, you need to do this. Hey, that. I need this. I need that. " Once I have everything with me, I will start with the planning of the project. A planning phase of the project. Now, this planning phase basically includes your technical planning as well as non-technical planning. Like, if I talk about technical planning, it includes creating a Non-technical basically means creating a hiring people, okay, creating teams who are going to develop, test, who will be the architect, who is going to deploy, okay, so to start building the team, okay. That comes under the non-technical planning, hiring resources, costing, budgeting, okay, if we need to meet the customer, any kind of travels with plan travel plans for the customer. All these things will come under the planning phase. And apart from that, there will also be technical planning. Technical planning will be creating documentations, creating road map for the product. Okay, what we need to deliver in the first 3 months, then in the next 3 months what we need to deliver. That will be your technical planning. Non-technical means we need to create budgets, we need to get the cost approved from the customer

we need to start hiring the people. That comes under the non-technical planning of the project. So, after and we have all been We have everything on the paper, customer has agreed that this is going to be the start date, end date, and this is the final budget. The cost has been approved, everything has been approved. You get the final confirmation. We normally call it as like your the uh contract basically you've got. You did not get the money, but you definitely get a contract. Okay? A customer signs a contract and give it to you. Okay? Once you get the contract, you will start actually working with the customer. So, you will start designing the product. Now, as you don't have to do all these steps, there are going to be multiple people who are involved over here. Like for example, if it comes to the requirement gathering, that will be mainly done by your business analyst. Okay? Business analyst or by your product managers, those are the guys that are mainly doing all those stuff. Okay? If I talk about the planning, planning will be mainly done by your project managers. Who is managing the entire uh communication with the customer, who is doing risk management, who is doing the cost management, everything. Handling of people, handling of resources, everything. That will be done by your project managers. Then coming on

to design. Now, designing basically means creating some kind of high-level, low-level diagrams for the customer. Okay? Some kind of networking diagrams, network flows, all those things we will be discussing in the design part. And we will sit down with the customer and we will ask customer to give his input. Okay? We will present some solutions to the problem that he has given. We will present some solution and we will be asking customer, "Hey, can you give us the inputs? " Okay? And we will need to have a go, no-go signal from the end customer. Like whether customer agrees on the design or not. All those things will be a part of the design phase. And this will be mainly lead by your architects. By your solution architect, by your technical architects. Those people will be actually working in the design phase. Okay? Meaning designing is mainly designing, creating diagrams, any components that need to be designed. Okay? What tech stack we are going to use, which language what framework will be my back end, how APIs will be developed? All those things is part of designing. And we present it to the customer. Customer says, "Yes, I'm happy with your designs. Start the development. " So, once designs have been approved, we start with the development phase. Now, this development phase is basically

the coding phase. The developers will be doing it. So, we call it as the coding phase. The phase where development team will come into the picture, developers picture. And they will start writing the code. In some language, Java language, Python,. NET, Go, some language. Okay. So, that is being already decided during the design phase, what language we are going to use. Okay. So, that will be the phase. Okay. Where developers will come into the picture and start with. Now, once the coding phase is completed, after this, the next phase is your build phase. And the job of DevOps team starts from here. The stage number of fifth after the coding phase is done. So, here the DevOps team will start basically with your building of the product. They will build the product. They are going to When I say building, compile the code base. They are going to test the code base. And they are going to also What they're going to do is they're going to package it. Package means creating a artifact. A file, a single deployable file. Like There can be thousands of code files

thousands of Java file. As a administrator, as a end user, I cannot use those thousand files to deploy my solution, to deploy the product. I need a single file. file which can be ready to go and deploy. Like for example, on my screen you see this Notepad++ So, to install this Notepad++ I would have used the Notepad++. exe. That file would have been used to deploy it. So, that exe file is the package. So, we need that particular package. So, that package compiling, testing, packaging will be done by DevOps team. After that, any further testing that has been required, like you want to perform load testing, any kind of UAT integration testings, you want to perform any kind of um staging environment or non-prod testing, all those will be done by DevOps team. Now, these are automated usually, but manual testing is also been done. But, nowadays manual is very obsolete. Automation is more in place. And that's where DevOps team come into the picture and they start playing the role of automation testing as well. They integrate these automation test cases in their pipeline and they run it. Okay. After testing, what next you have to do is you simply deploy. Let's suppose all the test cases have been Now, I'm happy with the product. It's all good. I will deploy that. It will first happen in non-production. Once everything is

working fine in non-production, I will ask my customer, "Hey, everything is working fine in non-production. Can I simply go and deploy in production? " If customer says, "Yes, you can go and deploy in production. " I will simply go and deploy in production environment, the live environment, the business environment. Okay. And after that, if there is any kind of requirement for monitoring the product, okay, you want to do secure it, you want to take any backup, these are the non-functional aspect, okay, of DevOps, but it definitely required security, monitoring, backup, all these things are required. Okay. And very important pieces. Okay. Because in the end, you need to make sure that your application is working fine. And it is secure with backup as well. Uh Uh high-level stages of SDLC. Requirement gathering, planning, coding, building, testing, deploying, then monitoring, security, and backup. These are some of the high-level stages of your software development. So, a software will be passing right from the start from requirement gathering and with the deployment and followed by monitoring, security, and any backups that need to be performed. In this cycle, the job of DevOps engineer will start after the code part. Building testing, deploying, all those things. Right? And over here, DevOps is a methodology. DevOps is a process. So, to perform SDLC to perform SDLC, there are a lot many approaches. Like we have waterfall approach, we have iterative approach, we have agile approach. Along with that, we also have DevOps.

So, DevOps is a approach to perform this SDLC. Okay. So, the big question is why is DevOps? Why DevOps? Because we have other approaches like waterfall, iterative, agile, then why exactly we are moving towards DevOps? What is the problem that DevOps is solving? Okay. So, for understanding DevOps, why DevOps, we need to understand some basic legacy model. What were the problems with those legacy models? Okay. So, to understand those legacy models over here, let me just open up a pen. So, let's talk about the waterfall model. So, what does it say? Waterfall model simply says that a developer is coding. Okay, let them code. Once the code part is completed, you go and build it. Okay. After the build is completed, you go and test it. And after testing is complete, you do and you go and simply what do you need to do is deploy it. That's it. So, waterfall model is a very simple approach that says that you go to a stage when the previous stage is completed. You go to build once coding is completed, you do the test once build deployment once testing is being completed. That's it. It's a very simple model that simply says, go to a stage when the previous stage is already completed. That's it. Now, the big problem here is that now let's suppose my development took 2 months of time. Now, during that 2 months of time, the other teams are sitting idle. They have nothing to do. They are completely sitting idle. Yes? They There is very less amount of work

for them to do because they are waiting for development to get completed. They're waiting for coding part to get completed. So, the first drawback is lack of collaboration. Right? Other the build team, test team, deployment, they have nothing to do. They are not collaborating. They don't know what coding team is doing. Development team is doing their development, other teams are not aware about what exactly is happening. Lack of collaboration. Now, even let's see some more problems. Let's suppose after 2 months of time, I coding part is completed, I go the I start with the build is also completed. Now, testing part. Now, in the testing part, I some kind of bugs. I found some kind of bug. Bug means when the functionality of the software is not working as expected or when the functionality of the software error. That is called as a bug. When the functionality is not working as expected or when the functionality of a software is giving an error, that is called as a bug. So, in the testing phase, I found a bug. Now, it can be one bug, there can be hundreds of bugs that you found. Now, the problem is you are reporting

those bugs after the coding is completed. Now, fixing bug is not a problem. It may be one line change. It may be just one line change. I just need to make a one line change to fix that bug. But the problem is to make that one line change, I have to review the entire codebase. Because that one single line can break something else. It might be breaking something else. So, proper code review has to be done even to make that one single line of change. And that is the big problem. Because this bug fixing will take huge time. Yes, because my entire code is written and now you're asking me to fix the bug. So, definitely fixing bug is time-consuming. Why? Because entire code will has to be reviewed. In time to market TTM, overall time to market the product, this will increase. Right? Apart from this, you will develop who has written the code, they will also get frustrated. Why? Because they are getting the bugs after the code is written. After everything is done, now you are reporting, you're coming with the issues. Now, here developers will get frustrated. So, developers are not getting a continuous feedback on what job they are

doing. This is a big problem. Lack of collaboration, fixing bugs will take time. So, my time to market the product will increase and my developers are not getting feedback at a regular interval. This is the problem. They're getting feedback after everything is done, then they're getting the feedback. So, this is not a good thing. Right? Now, apart from that, let's suppose the customer come up to you and customer says, "Hey, I have some change of requirement. Can you accommodate some changes? " So, the problem is you are doing testing. Your code is already completed. How will you accommodate any changes now? Okay, I have to tell Mr. Customer, "Hey Mr. Customer, I cannot accept any requirements right now. You have to wait

for the upcoming cycle, for the next cycle. I cannot do any changes right now in the system because right now we are in the testing phase. Code part is already completed. Okay, so we have to tell Mr. Customer a simple no. And this will lead to frustration in the customer as well. Like you are telling customer a no. So, the customer satisfaction is very less. Customer has to wait for something to be getting implemented. He has to wait for this complete cycle. After in that in the next cycle, the changes that customer want will be implemented. And this is a big drawback. Customer satisfaction is not of a greater level. So, these are some of the very common challenges with the waterfall model. My time to market the product increases. Lack of collaboration between team customer satisfaction is not good. Developers will get frustrated because they are not getting a continuous feedback. Okay, they're not getting feedback on what they're developing. So, this is the some of the common problems. Right? Now, how to overcome this? To overcome this, we need DevOps. DevOps comes in picture to help us out. How exactly? Let's understand that. So, in DevOps, DevOps like in waterfall model, what we were doing? We were doing things serially, one after the other. One complete, go to second. Second complete, go to third. Third complete, go to fourth. We were doing things serially. Now, we just have to do things parallelly. That's it. parallel. Nothing more than that. When I say, "Okay, I will develop uh I'm doing the coding, okay? Let coding run parallelly. Like my developers, developer number one, developer number two, developer number three, let them run the code, let them write the code, does not matter. Coding is happening, I will simply go and build it. I will start with the building process. I know my build may be not successful. Why? Because coding is still happening. But at least

the development team will get a fair idea on what is happening. If you start creating a build, definitely it's a good idea that whatever developers have are writing, they are getting a build and you'll start also testing that build. Okay? And let's suppose build is successful, but in testing something is breaking. Let's suppose there are 10 features in the product. Out of those 10 features, developers have written four features. Okay, build it. Test it. At least they can get a feedback on what is happening in those four features that they have written. All right? Instead of waiting for the entire code to get complete, run everything in parallel. My all the teams are well synchronized, are well collaborating. Okay, everything I have their piece of work to do. My developers, whatever they are writing from 9:00 a. m. to 6:00 p. m., whatever the code they are writing, I'm or 7:00 p. m., I'm just building it. In the night, I start automation testing. In the morning, they get the report. What is successful, what is failed. So, understand, DevOps is just a strategy to make you fail fast. Fail fast, that's it. That is the overall strategy here is. As faster as you fail, more chances that

you will be successful with at a very early stage. Right? You fail stage rather than failing at a very later stage. Because that will help you in reducing the time to market. Time to deliver the product this will go down. TTM will go down. Time to market. Right? Now, let's suppose even all the four features build successful, test is successful, you go and deploy it as well. You test whether deployment is successful or not. And at the deployment, let's suppose you find a bug. You report that bug to the developer. And tell them, "Hey, this is the issue. " Developers will start working on the bugs as well. Apart from the features, they will start working on bugs simultaneously. Rather than reporting bug at the very last stage after the entire code is completed, report the bugs along with the development of features that is happening. So, developers are making a continuous

change in the code on a daily basis. Code dash, you run the build every day, deploy it. Any voting bugs, report those bugs. We'll start working on the bug next day. Developer will fix the code changes, run the build again, deploy it again. Nothing but a cycle, a continuous cycle that is which is nothing but your continuous integration, CI, that you see is continuous deployment. Whatever developers are doing, you are continuously get as well. As integrate and you continuously deploy. This [clears throat] is what DevOps is all about. Fail fast. Okay? Whatever developers are

take it, build it, test it any stage if at a if at the build stage or at the test deployment stage anything is failing, report it as a bug to the development team. That's it. Report report it as so that they know the feedback. They're getting a feedback at regular intervals. On a daily basis they're getting those feedbacks. This is important. This is what DevOps is all about. Performing CI/CD, continuous integration, continuous deployment, and passing a continuous feedback to development team. Now, how to achieve DevOps? Like that is the big question. So to achieve DevOps, we need some tools. And that periodic table that we are going to see is set of those tools only. See this periodic table, let me show you. Yeah, see the periodic table of DevOps. See this. Okay, in this period lot many tools. Okay, over here. And I'm not going to talk about all these tools because even I don't know all these tools.

Frankly speaking, as a DevOps engineer, you don't need to work on thousands of tools. You just only need to focus on few of the tools which are very relevant in the market, which are high demanding in the market, and which people are using, which community is using. You get a good support for the tools. Right? So, mastering thousands of DevOps tool is not the key idea. Mastering those tools which are which are industry by the IT professionals and which have a good community support, those tools we need to learn. Okay, so here what are those tools? Let's talk about that. For example, Git. Okay, so now to perform DevOps, we need these tools. As I said, DevOps is not a tool. technology. DevOps is a methodology. It's a process. And to achieve that particular process, we require some set of tools. Okay, and what those tools are that we are going to discuss now. So, the first tool that I'm writing over here is Git. Okay, then we have Jenkins, Maven, Ansible, Terraform, Docker, Kuber, then we have your other tools for monitoring like Prometheus with Grafana, Prometheus and Grafana. These are two different tools, but yes, used very widely. Okay, so over here, what is the use case of these tools? Let's try to understand that. Okay. So, when I talk about Git, Git is a version control system. Guys, now these are not the only tools that are available in the market. As I said, there are many tools. 500 plus tools are there. If you want to see some tools, like only for source code management, see eight tools are available. I have GitHub, Subversion, Perforce, Bitbucket, GitLab, JFrog, Sonatype Nexus, Compuware, ISPW. There are a lot many tools. Right? Then for database automation, we have continuous integration, we have See this, the number of tools. Okay, but again, these are the tools that I have written over here. are very widely used in the IT industry with community support. So that's why we are mainly focusing on those two. I will also talk about the alternatives of Okay, side by side I Like Git. Git is a version control system. Now when I say is that at you lock many things. You do automation on lock many things. Like you're going to compile, test, package, deploy, monitor, secure. Lot many things you're going to do. But the big problem here is that will you do it manually? Will you be compiling manually, testing manually, packaging manually? No, you need quiet tools. You will be writing lot many configuration files. some kind of scripts. Right? And the big problem is that you will be making changes in that script as well on a daily basis. Let's suppose I wrote a script today. I made some changes tomorrow. day after tomorrow. After that I also made some changes. So I'm making changes at a regular interval. So the question is how will I track those changes? What changes I made on what day? How will I track it? Let's suppose I want to revert it. Then I need some tool that helps me in controlling the version of the files. That's where Git come into the picture. So Git will track, okay, on Monday this was done, Tuesday this was done, Wednesday this was done, Thursday this was done. Now you want to go back from Thursday to back to Tuesday, you can do using Git. So Git is nothing but a version control system of VCS. Alternatives of Git if I talk about you have SVN, Mercurial. These are some of the alternatives of Git. Okay, SVN, Mercurial. Okay, GitLab, Bitbucket. There are more. You will see more alternatives of source code management. Subversion, SVN is subversion. Yeah, JFrog Artifactory, Bitbucket. There are a lot many. Okay, but Git is one of the most popular tool. And tools are open source. Whatever tool I have written over here are all open source. This is one of the very big thing. You don't have to pay for licenses. the cost. Understand that. Okay, then Jenkins. Jenkins is nothing but an integration tool. A tool that will be performing from where you will be doing all these automations. Like you need a platform from where you can download the code, where you can compile, where you can build, means test, where you can package, and where you can from where you can deploy. I need a common platform. Right? That particular platform platform That particular tool is nothing but Jenkin tool. A tool that integrates various stages of DevOps. Like I need a platform from where I can do building, compiling, the deployment, all those things. That tool is Jenkins. And those And when I talk about Jenkins, there are a lot, Bamboo, the Circle CI, this a lot many. Let's go into the PPT and let's See, Bamboo, CI, Circle CI, AWS CodeBuild, like on cloud as well you have something AWS CodeBuild. This is one of the tool which is similar to your Jenkins. Okay, which is building your code. Okay? Then we have another These are alternatives. And your periodic table is nothing but a table which includes all these tools. Like what is periodic table, guys? Periodic table anyone says DevOps periodic table, it is nothing but a collection of these tools. Like for example, over here all these tools in the black that you see. See these black tools. What are these? These are your integration tools. Two A tool that integrates various stages stages of DevOps. A tool from where you can perform various stages of DevOps, that is called as integration tool. Jenkins is one of the integration tool very highly used. However, you have other Bamboo is there, CircleCI. Travis. Okay, you have this code What is this CodeShip? TeamCity. VSTS, AWS CodeBuild. See these tools. Okay? The one in the blue. The one in these blue. What are these blue ones? Okay, so I don't know. You can check. In the DevOps table. And you know already what these tools are, but you can check if you don't know. These all are testing tools. Right? What are these red ones? These red ones are nothing but your source code management tools. Right? These are different tools that we are using on a day-to-day basis. Now, as I said, you don't need to master all these tools. No. Just one tool is fine. Which is very popularly used in the industry and Jenkins is that tool. So, it's good to learn Jenkins definitely. Understood? So, here get is coming on to Maven. Maven is nothing but it's a build tool. We compile the code base, test the code base and that package the code base. This that is Maven. Now, if I talk about Maven alternative, you have ant, you have Gradle. You have g r a d l e. These are the alter Maven. Right? Again, you can see all these tools. Then, we have Ansible. Ansible is a con management tool. And Terraform is a infra as a code tool. Structure What do I mean by that? Let's try to understand. About the coming up package. And that package Java my application the Java file. Now, I will find 100 The question is will you do this manually? Will you go and deploy this 100 servers? You need to deploy this application on 100 servers. So, there are two questions. How you will create 100 servers? How will you create servers? That is a question. Okay. And second, how will you deploy? So, okay. I have the simple answer. I can create all those 100 servers manually. I can do it, but the problem is if I'm doing it manually, it is time consuming and chances are I can make mistakes. There are chances that I may make some mistakes. Okay. Apart from that, I can also deploy manually on those 100 servers. But again, time-consuming and chances are I can make mistakes. So, how are you going to put it deploy these 100 servers? Manually? Time-consuming. Chances you got you are making mistakes. So, here I will be using tools like Terraform. Terraform is nothing but a IAC tool. We call that IAC infrastructure as a code tool, IAC tool. And the main use of this tool is to provision your infrastructure. To automate your infrastructure provisionings. Okay, I want to create 100 servers. I will write a script. Terraform script. I will execute that Terraform script. The entire infrastructure is ready in like 15 minutes, 20 minutes. If I'm doing it manually, creating 100 servers will take me 1 week of time. Let's suppose I'm just creating 15 or 20 servers a day. So, 1 week of time it will take. Within 20 to 30 minutes using Terraform, you can do the entire infrastructure deployment. Right? And that's where Terraform come into the picture. And if you talk about the alternatives of Terraform, AWS CloudFormation. You have Crossplane. You have Pulumi. Okay, you have Azure Resource Manager. These are some of the alternatives of Terraform. Terraform provides infrastructure provisioning. Now, once servers are created, let's suppose you have all servers 1 2 3 Okay, once these servers are created using Terraform, I want to deploy the application application. jar file on these servers. How will you do? Will you deploy this manually? Will I go and deploy these application manually? Answer is yes, I can do. Time consuming and chances are I make mistakes. So, how will you automate application deployment? Any configuration deployment, I want to automate configuration deployment. This is configuration. Here, I will be leveraging Ansible. Ansible is nothing but a config management tool. A tool that allows us to create any to deploy to execute any configurations or to deploy or any applications to de- deploy any settings on our servers on