Welcome to Conf 42 DevOps edition. Let's deep dive and green DevOps building sustainable software guy hi, I am Neel Shah, a DevOps community guy building various DevOps communities in my local region like Google Cloud, Docker, CNCM, Hashicorp, managed more than 15 plus hackathons and working as a product manager at Internal Infotech. So here comes the false statement. I have all my data on cloud so I don't emit carbon dioxide. Is that true? No. Eventually, because each and every one of us who have hosted their website or application on cloud are emitting carbon dioxide indirectly as we have hosted on the data centers and the data centers emit carbon dioxide. So we are eventually emitting carbon dioxide as we reveal in the innocence driven by software development. We also acknowledge considerable carbon emission carbon footprint from our products. So how we can reduce that? Today we are going to talk around that. So what is Green DevOps? Green DevOps is a general terminology accused by the normal people to understand and building sustainable software. Unlike the traditional development where we were focusing on spare and functionality of our product, eventually in green DevOps we will focus on the environmental consideration in the forefront. Then we will consider the spare and functionality. So it will also benefit for the environment and eventually it will also benefit for our product. What are the benefits of brain DevOps? We will reduce the consumption of the energy, it will eventually optimize our product, our resources and it will eventually save our cost, save our pockets. So the two benefits are we will reduce the energy consumption, eventually it will reduce the carbon dioxide and it will eventually reduce the cost. So win win situation for all. Next is improve resource efficiency because eventually we are utilizing the resources in a go and go manner to give the customer a very smooth procedure. We will have a lot of lot of amount of big vms. Eventually we can do that stuff on a single vm also. So why we are not coding to have our customer a battery experience. So eventually precisely or measuring all the things we can cost down and we can slow down the number of vms. So eventually it will improve the efficiency and it will also have our cost cutting and eventually we can implement some code optimism techniques, we can resize our infra. In that manner we can have some efficient testing will eventually help us to improve our resources. Next is enhance software quality. So as soon as the developers work on the code optimization and also of techniques, eventually it will also optimize our software quality. So we are not wasting the energy in any manner. So eventually we are saving our cost and we are also working on carbon footprint. We have discussed around carbon footprint. Carbon footprint, but how the carbon footprint is measured on a water scale. So let's discuss on that portion. So that is GHG protocol. That is greenhouse gases protocol. And there are different scopes under it. And eventually from most of the big companies, from top ten companies. Most of the nine companies use this to differentiate their usages in different sectors. Different scopes. First is direct emission, indirect emissions. What we can consider is when we burn the fuel directly, when as a company or as a person, we are burning the fuel directly, it counts in the scope one. Next is scope two. That is indirect emissions. The indirect emissions consider when we are using some electricity, when we are using a tube light or a light. Then the energy came from the power supplier, the electric power station. So eventually they are burning their coal, their fuel. So it comes in scope too. And all of the things which are other things like business travel. So the plane, the airplane, lot of carbon dioxide, this sort of things could be considered in scope three from material purchase and what are the activities and each and every other activity is considered the scope three. So how it is working in our DevOps field. So when we host a website in private cloud, website or application, anything and private cloud, it considers in scope two. And when we do the same in public cloud or hybrid cloud, it is considered in scope three. It is a measures given by the grin software formulation under the GHS protocol. Yeah. So how we can find out this carbon intensity in our product or utilize our carbon footprint. So this is the formula from which we can generally gather the data and say the intensity in this region is less, the intensity in this region is more. So from this formula we can derive with that. And this formula includes the electricity or energy consumed. Also the carbon emitters through hardware and sole software. So this calculates all the things and it's formalized by Grimsoft foundation which is working on to use carbon footprint for each and every product in our world. Next is the major cloud providers are also working to help people to reuse the carbon footprint. So they also have their own calculators which will detect all the resources used in their products. So eventually AWS has AWS carbon footprint tool. Google has Google Cloud carbon footprint. Azure has azure sustainable calculator. So even the cloud providers, when we use any resources of them and when we choose some regions, they will also show the region which is having low carbon footprint. Eventually there is a small mark and which is telling us low co2. So it is saying like the carbon footprint latency, the efficiency of carbon in that region is low, so you can utilize that. So also the major cloud providers are focusing on that. Next is one of the open source tool and largely used tool is car cloud carbon footprint. It is widely used by everyone because it's open source and it is very easy to work on this. And this is a sort of dashboard which we can gather utilizing the carbon footprint from cloud carbon footprint tool. So eventually we need to give our bls over there and also to give us a large amount of data. So eventually it will make the dashboards over there. Next is the major thing. That is how we can reduce the carbon footprint in the DevOps techniques. Here comes a real green DevOps because it will eventually help all the DevOps people to reuse their carbon footprint. The first is cache static data. Eventually when we go on the same website, a large larger amount of time. So if the data, small amount of data is cached then it will benefit for us. So eventually it won't take another amount of time, another amount of strength energy. Together the same data again and again. Next is delayed unused storage resources. Eventually we should monitor all the things and also delayed all the things which are not necessary and we can have our infrastructure to bare minimum. Next is implement stateless design. Another thing is queue non urgent processing request because when we have multiple amount of requests, the storage will be optimized. No, the storage will be buckled up and it will also have a large amount of request on the same manner. So we should run this in a sense that if the requests are not urgent so it can be on the next tab after the requests which are currently going on. This is scale down your infra when not in use angel, it will also cost down your thing and use serverless cloud services. Why? Because serverless has a functionality where we don't need to manage the cloud functionalities. It will manage by cloud providers and whenever there is necessary of large amount of storage or large amount of vms, then it will scale up and automatically. When there is no need it will scale down automatically. So using this it will help us. Next is we can have software eco design sort of thing. Next is choice of instances and a proper type on AWS. We have on spot instances. They are just like server layers, they just use the bare minimum thing. When they are not in use they will also use the minimum thing. So we should use the right size of the thing. Eventually. If we need, let's say some x amount of storage, then we should see that sort of instance from the whole group of things. Next is capertom wherever it will be, auto scale groups or containers or anything, and change reason or zone. As per the low carbon latency shown by the cloud provider, we can easily improve the things. These are the things which is implemented in a day to day process. But yeah, we can slowly start slowly, we can gradually implement them and have a huge impact then, yeah. So what are cloud awareness? So temporal shifting. So when the carbon intensity in our region is very high, then we can shift over some work which are not necessarily urgent. We can schedule them. When the carbon efficiency, carbon efficiency is good or carbon latency is low, we can schedule them at that time. Next is demand shaping. So demand shaping, when we are working with image or video analysis sort of thing, let's say then we need to give the output and a high quality image or high quality video. So in spite of that, at the time of very high carbon latency in that region, we can do that. We can pixelate and pixel down the image quality and give them the pixel down quality. So the lower energy will be consumed on that node. Eventually. If we are working on a CICD platform, let's say something like jackians, where the architecture is like workers live nodes. So eventually, when the time is, the carbon dicency is high, so we can use some of the no worker nodes instead of, sorry, some of the slave nodes instead of all the slave nodes, and do other stuff after the things which is currently going on can be down to use them reconvene instead of doing all the things in a parallel manner. Next is partial shaping. So what it is done is you can like, let's take one example how the automatic load balancer works. We have the same thing in two different regions, and it will fetch the request, or it will give the request to that region which is nearby to the users. But what Google implemented in between, it's from the true facts from one of the research paper which can be published that they implemented on the top of load balancer. They also implemented to have the request from the region which has lower carbon footprint, sorry, low carbon latency. So it will help produce carbon in that manner also. So it will fetch the request from the region which has lower emission of carbon in spite of having the nearby region. So it is helping out that. And eventually from the report, it proves that using this 51% efficient work is done there. So yeah, that also helps a lot. Next is, is it a phenops plus green ops in green DevOps? Eventually, because as on the path of green DevOps, we are also saving a lot of money. Another use case is when we have a service. Let's say we have five nodes working on a day. On a day, we have a sunlight and we have a good carbon latency, but eventually, in night, we don't have sunlight, so the carbon emission would be higher. So on night, what we can do is we can scale down our nodes from five to two or three, which are bare minimum. And eventually, on the day, we can also scale up. So this kind of thing could be implemented. And eventually there's both helping and pin offs and also green ups. Green DevOps. Yeah. Connect with me for any queries and. Yeah. Thank you. Thank you, Khan for the shoe. Have a nice day ahead.