Micro Focus is now part of OpenText. Learn more >

You are here

You are here

How to do DevOps without increasing your carbon footprint

Lars Rossen Chief Technology Officer, Micro Focus

DevOps is about continuously compiling, producing, and deploying artifacts, but there's little thought given to the practice's impact on your operation's carbon footprint—especially as you scale. Think about the cycle: Whenever a coder makes a change, it gets submitted to a software repository. That kicks off an automatic process where the change is run through compilers and linked with other modules and then tested. If it passes all the tests, the change is deployed to production. That consumes a lot of resources.

In a traditional coding environment, changes took anywhere from three months to a year to be implemented. In the DevOps model, a coder looks up the code and corrects the error, and a half-hour later it is in production. Some organizations claim to release changes into production every five minutes. But what's the impact of those processes on your organization's carbon footprint?

Like the rest of the business, IT organizations should be thinking about how to reduce their overall carbon footprints. Moving to a SaaS delivery model is an example of something that reduces your organization's footprint, while also providing the cost benefits of optimization. 

But you must also consider minimizing the compute, storage, and network resources needed to produce a release by promoting a focus on efficiency and not wasting resources. The good news that, with a little planning, you can achieve all the benefits of DevOps without increasing your carbon footprint—and have something to brag about to the business. 

Here's what you need to do to get your DevOps teams started.

Reduce the number of runs

Here's the issue with doing more runs: A typical transition from a classic code-build-test practice with a total of 100 coders, testers, planners, etc., to an agile/DevOps CI/CD automation pipeline will result in a sevenfold increase in the consumption of compute resources, on average.

Why? Because unlike in a traditional coding environment where there is a single main build and test environment, in a CI/CD setup, every developer runs the pipeline twice a day—and one run typically takes an hour.

So, if you want to correct a spelling error, you still have to run a complete compile to get the change pushed through to adoption.

Fortunately, there's a simple way around this. Let's say you have a small project that 50 people are collaborating on. You can set it up, wait until everyone makes the necessary changes to the code, and then press "publish this" on the pipeline at night. That reduces the usual 200 or so runs to one.

And honestly, that's not a long time to wait. It gets you thinking about how the DevOps practice pushes you toward constantly running the pipeline whenever you make updates as a team, get immediate feedback, make any further changes, and so on.

Granted, if you don't run the pipeline immediately, you delay knowing about any errors and you don't get immediate feedback. And yes, programmers' efficiency increases if they press the button every time they make a small change. But it would actually be okay to not do that and push the changes only when you have a decent amount of work to do.

Here's the bottom line: 

If you don't consider your energy usage when you run your DevOps practice, you could end up consuming more energy and emitting more greenhouse gases—especially in an aggressive DevOps setup—than you would otherwise.

Fortunately, there are a lot of things you can do to reduce that impact and make sure people are aware of the cost of what they're doing. By the way, you should know that your energy consumption increases as you move a lot of this work to the public cloud. You may not directly hear about carbon footprint consequences but, suddenly, the cost of running a server becomes real.

Reduce your energy consumption in the public cloud

While using a public cloud can amplify the problem, it can also be a part of the solution to reducing your carbon footprint. When you migrate workloads to the public cloud, you have access to unlimited compute resources—and your server usage tends to grow, increasing your energy consumption and carbon footprint.

Because the cloud operates on a per unit-consumed basis and there is still a bill to pay, that should be a wakeup call for your teams to rethink how often they run the pipeline. DevOps teams have a direct incentive to reduce consumption because it saves their organizations money.

Optimize your pipeline

The second thing you can do is to optimize what you do in your pipeline. It's easy, and therefore tempting, to let the pipeline do all the work, and combine everything and run all the tests you have defined. Most build systems are smart about compiling modules only for things that have changed, but you can also apply these techniques to the testing part of the pipeline.

Smart testing systems have algorithms that can figure out what needs to be tested when you change a module. There can be hundreds of modules that make up a project and lots of tests that need to be run, but you really only need to test something you've made a change to. So, by introducing more intelligence into the DevOps pipeline, you can save money and reduce energy consumption.

As you apply some of these principles, you may see a reduction to only a two times increase in compute resources, from as much as seven times. But DevOps teams typically have a throughput that's at least twice that of a classical team, so overall, your consumption per unit of work produced will remain unchanged, even as the speed of your organization has improved.

Think win-win

DevOps practices can raise your carbon footprint and negatively affect the climate, but there's a lot you can to do mitigate this and keep your carbon footprint in check while still achieving greater productivity. Applying these principles will give your DevOps team more deployment flexibility. So consider optimizing your pipeline, and automating with energy consumption in mind.

Keep learning

Read more articles about: App Dev & TestingDevOps