DevGreenOps, also known as DevSusOps, is an extension of the DevOps approach, in which environmental sustainability considerations are integrated into every step of the DevOps cycle, Jochen Joswig said in his talk at OOP Conference. Applying transparency, minimalism, efficiency, and awareness, helps us to design sustainable digital services.
The promise of DevGreenOps is that it will bring all the benefits of DevOps, while also reducing the environmental impact of software, for example, by reducing the required energy, water, or other resources during every stage of the software’s life cycle, Joswig said.
There are many concepts, ideas, and approaches available. Joswig suggested categorizing them into the following four categories:
- Transparency
- Minimalism
- Efficiency
- Awareness
The transparency category contains actions like integrating meaningful sustainability metrics into the monitoring and observability of the service, as well as communicating them to all stakeholders, including developers, operations professionals, designers, and users or consumers. This can be done through things like sustainability reports, dashboards, or even just single KPIs, when they are relevant to their decision-making, adding the sustainability dimensions to this decision-making, Joswig said.
Some development teams may also benefit from other concepts like carbon budgets or scoreboards, Joswig mentioned. Like a fiscal budget limits the amount of money that can be spent for the development or operation of a service, a carbon budget limits the amount of carbon emissions that the development or operation of a service is allowed to cause.
For scoreboards, Joswig mentioned two major applications:
The first is to gamify environmental protection, for instance, by tracking which teams or projects have seen the most environmental impact savings in a given timeframe.
The second is to track which computational unit (application, class, method, machine, …) has the biggest environmental impact.
Scoreboards like the second example help to identify improvement potential, he said, while the former promotes and rewards sustainability excellence.
At the center of the minimalism category is the question: “Is this really necessary?” The earlier in the life cycle this question is asked and answered, the better, Joswig explained:
Imagine receiving actual user feedback from testing a paper prototype, which reveals that an entire feature is not actually necessary and thus never needs to be developed.
Joswig recommends scrutinizing every aspect of a software project. This may be painful, because it is not uncommon that parts, which teams have poured money, sweat, and tears into, are not actually necessary and thus can be eliminated. But it will most likely be worth the pain, because it will lead to not only a more environmentally friendly software, but also software which is easier, faster and cheaper to maintain, deliver, operate and monitor, also it may result in a better user experience:
There are many examples like this, which illustrate that improvement is possible on every level from each line of code to the most fundamental question: “Is there a need for this service or project at all”?
Once the development team is certain that what they are developing is necessary, then it makes sense to think about improving its efficiency, Joswig said. The efficiency category encompasses not only the resource and energy efficiencies of the product under development in all of its life cycle phases, but can also include the efficiency of the development process.
Joswig suggested thinking about programming patterns, algorithms, and data structures, data formats. Introducing caching or eliminating dependencies could be worth a look, he added. A very fundamental and fiercely debated topic is the selection of the programming language. Joswig referred to the paper Ranking Programming Languages by Energy Efficiency from Pereira et al. which shows that it could result in a 75-fold difference in energy consumption, when implemented in C instead of Python. However, it is rarely that simple, he said.
Joswig added the awareness category, as even if software is transparent, minimal, and efficient, its environmental footprint could potentially still be reduced. An example he mentioned was ensuring that the software is aware of the fluctuating supply of renewable energy and adapts intelligently, which means that computation is scheduled when or where renewable energy is available:
This is most powerful, when it is used to reduce curtailment situations, which happens, for instance, when more solar or wind energy is available then there is demand for it.
Awareness not only includes the software, but also the development team should be aware of what they are creating. The question of sufficiency is part of this awareness just like the question: how the software/product might fall into the Jevons Paradox trap, Joswig said.
The Jevons Paradox essentially says that efficiency gains do not translate into resource savings, because the more efficient a technology or system, the more it will be used. This could even go so far that efficiency gains cause more resource utilization, Joswig concluded.
