How do you go from DevOps to DevGreenOps?
How do you go from DevOps to DevGreenOps?
Summary
The transition from DevOps to DevGreenOps seems essential if we are to meet the major challenge of reducing the environmental impact of digital technology. It means putting in place a new tool-based approach, but also a change of culture.
In this article, we’ll start by defining what DevGreenOps is and what its fundamentals are in each stage of a DevOps cycle. We will then look at how to implement it in a framework such as CALMS. We’ll identify a few best practices for success, and finish with the metrics and tools that are useful in the process.
1. Green and DevOps context
1.1. Devops context
The increasing digitisation of services – the famous “digital transition” – has confronted IT teams with the need to deliver more software products, with more functionality, more frequently… while maintaining or even increasing quality and security.
In this context, traditional development practices, i.e. ‘V-cycle’ or ‘waterfall’ development and the clear separation between software development (by the ‘Research Department’) and hosting (by the ‘Operations Department’), were not sufficient to meet this challenge.
The adoption of agile methods and the move towards continuous integration and deployment have made it possible to meet this need. DevOps” (a catchword for “Development” and “Operations”) can be defined as a set of software production practices combining development, quality assurance, deployment and monitoring. This culture enables teams to deliver regularly – up to several times an hour! – while maintaining a high level of quality and security.
By accelerating delivery, DevOps enables organisations to better adapt to customer demands and innovate more quickly.
According to an Atlassian study mentioned by Cisco in its article The Rise and Rise of DevOps Adoption, 83% of organisations have adopted DevOps practices, but only 18% have a fully integrated approach. The general trend is towards the deployment of these practices.
1.2. The impact of digital technology
Awareness of the environmental impact of digital technology has led to a need to integrate best practice and specific tools into software factories. To the existing constraints of maintaining quality and security have been added those of calculating, maintaining and even reducing the impact of software. This last constraint is sometimes at odds with the acceleration of releases, with teams providing ever more functionality but also using an increasing number of new frameworks and libraries. The need to continually measure, control and reduce the impact of digital solutions, given this context, is now emerging in teams.
DevOps brings with it the risk of increasing the impact of digital technology, but also an opportunity to improve it: implementing a DevGreenOps culture should help us to meet this challenge.
DevGreenOps is a culture of integrating environmental considerations into the development of digital services through practices that measure and continuously improve the impact of the application.
“DevGreenOps or Green DevOps?
The two terms are easily understood, and as this is a new concept, there is not yet a dominant term. We have chosen to use the term DevGreenOps for two reasons:
- It is based on the “DevSecOps” model, which describes the integration of security practices at the heart of DevOps processes. However, it is the integration of “green” practices at the heart of DevOps that we are talking about here.
- There is already a “Blue/Green DevOps” name for a particular deployment management method. When we talk about Green DevOps, we run the risk of confusing it with Blue/Green DevOps.
2. The foundations of DevGreenOps
DevGreenOps is a natural evolution of the DevOps methodology. The 8 phases of the improvement loop used in DevOps can be impacted by DevGreenOps.
Throughout the cycle, the aim will be to adopt a sober approach (to requirements, resource consumption, etc.) and to control the “environmental quality” of the software product.
Plan
This discovery and planning phase is crucial to the integration of sobriety. It must enable environmental constraints to be integrated into the design of functionalities and interfaces, as well as the choice of technologies and libraries.
During design and ideation workshops, thought must be given to both the usefulness and the impact of the solution and its functionalities. To find out more, see the Ethical Designers guide.
When setting up the architecture and choosing the tools, the environmental criterion will be integrated alongside the criteria of security, maintainability, etc., by integrating the software’s overall life cycle. Frameworks such as the RGESN or the INR will be useful in this phase.
In particular, the choice of third-party services and other external libraries could be challenged. Third-party services are easy to integrate, but have a significant impact on software.
The planning phase is also a phase for improvement: of the DevGreenOps process, but also by analysing the metrics measured during the previous phases.
Code
Although the code is not solely responsible for the impact of the service, this phase is important for integrating good eco-design practices. The use of a code analysis tool in the developer’s IDE will enable this type of good practice to be implemented as early as possible.
The PIC commit process will enable structured code analysis based on Green IT best practice.
Initial impact measurements can be made during this phase, provided that the solution is deployed in parallel.
Build
In particular, the build phase will provide an opportunity to review the code from a “sober” perspective. The build followed by deployment on a staging instance will also be an opportunity to launch the first impact measurements.
Test
This phase is critical for DevGreenOps. Sobriety or impact requirements are new non-functional requirements, and compliance with them must be verified. This is a new area of testing that has its place, like performance testing, for example.
The test strategy implemented will depend on the conditions of the project. For example, consumption measurements will be carried out under stable and regular conditions, to monitor changes in indicators from one build to another or from one release to another. In addition, extreme tests, particularly on low-end terminals and limited connections, will enable compliance with specific requirements to be verified, and may help to detect anomalies in resource consumption.
Release
The “quality gates” with checks on good green coding practices and sobriety tests have been passed. There’s still time to refuse a production start-up if one of the KPIs set out in the Plan is not met.
Deploy
Automatic deployment may trigger resource consumption tests in production. There may be a number of differences between the tests carried out in the test phase and in production: certain third-party services are activated, configurations are potentially not the same, etc. A check carried out directly after the production launch will detect any anomalies in resource consumption.
Operate
During this phase, server resource consumption will be monitored. A good understanding of the dynamics of consumption as a function of load will help to avoid oversizing the architecture and scaling too early.
Monitor
This phase makes the system observable, enabling anomalies to be detected and quality to be improved. Monitoring will help to identify unused functionalities (to improve functional sobriety), as well as slowness or over-consumption. In addition, continuous measurement of the impact of the solution will provide KPIs for the continuous improvement loop.
As we have seen, “Green” infuses every stage of a DevOps process. But how do you implement it? Let’s take the CALMS framework as an example.
3. Framework for implementing devGreenOps: CALMS in Green
The CALMS framework was introduced by Jez Humble in his book The DevOps Handbook. It enables an organisation to measure its progress towards DEVOPS. CALMS stands for Culture, Automation, Lean, Measure, Share. Applying CALMS to DevGreenOps will, in the same way, enable you to measure your progress.
C – Culture
Like DevOps, DevGreenOps implies a new culture of collaboration between teams. Reducing environmental impact means changing the way we work. The Agile culture has made it possible to prepare for this change, but more profound changes are needed.
On the one hand, reduction targets must be shared by everyone: Product Owner, Designer, Developer, Ops… These are referred to as new OKRs (Objective & Key Result). Any choice or action taken by a team will have a positive or negative impact on the overall product and therefore on the OKRs.
In this context, the Plan phase will be useful for discussing these objectives. In this way, a design choice made by the UX team can be challenged by the developers in relation to a complexity that would have an additional environmental impact.
Collaboration between Dev and Ops will be necessary to optimise infrastructure sizing and avoid waste. Similarly, feedback on resource and energy consumption from servers and data centres will be useful for the Dev team to improve observability, either directly or through the use of measurement tools.
It will also be necessary to integrate new types of players such as the CSR (Corporate Social Responsibility) team when defining objectives. More generally, we need to move away from a techno-solutionist culture (responding to any business demand by adding functionalities) to a culture of real sobriety (responding with functionalities that are selected, sized and developed as closely as possible to the need expressed, taking into account the environmental impact).
A – Automation
In the same way that DevOps will enable us to move from “it works on my machine!” to automatic deployment on a remote environment, DevGreenOps will enable us, via continuous deployment, to measure impact metrics on a controlled and representative environment. Resource profiling via IDEs or performance evaluation on the developer’s workstation (see “shift right quality” below) is costly and unrepresentative of the user environment. This is why it will be necessary to automate the deployment and measurement of resources.
In the same way, automating tests will make it possible to obtain metrics on the environments deployed. This automation means that the same path can be measured several times, giving more accurate data. What’s more, with DevOps deployment methodologies (A/B, Canary, etc.), the same tests can be run several times under different conditions, making it possible to study the impact of a particular subject (functionality, library, component, etc.).
L – Lean
The lean approach will enable us to gradually learn what the impact of the service is and gradually optimise it. Best practice guidelines exist and are useful. However, given the diversity of technical contexts, and the lack of knowledge about the potential benefits of each good practice, it is important to learn from experience and set up a feedback loop.
Failure must be accepted: deactivating a feature that will ultimately be of no use or will be too demanding in relation to the overall objectives of the project, going back on an unsustainable technological choice, etc. These are all actions that can be taken to lean.
The Lean approach will also be very useful in optimising the overall DevOps chain to avoid waste.
M – Measure
Measuring the impact of the solution will be key to improvement. Without measurement, the feedback loop will not be possible, or in any case actions will be taken without validation of a real gain.
Measurement will provide KPIs that can be shared between teams and improve the culture of collaboration. What’s more, it will act as the judge of peace: for example, the decision to deactivate or optimise a third-party feature or service will be backed up by non-debatable measurements.
Measurement will also provide metrics for system observability. Technical metrics such as CPU and RAM consumption, which already exist in DevOps observability practices, will be expanded to include energy consumption. Environmental impact indicators will be added: at the very least greenhouse gas emissions in CO2e, ideally a set of varied metrics to avoid postponing impacts.
Finally, measurements of the behaviour of the digital service in extreme conditions (no connection, old or low-end terminals, etc.) will provide important information for improving the sobriety of the service and validating its social inclusiveness.
S – Sharing
We need to change the way we develop, and in particular the way we work together. Sharing between teams will be necessary to move towards a common OKR for reducing impact. Raising the awareness of all those involved in the project to the concepts of Responsible Digital Design in general, and eco-design of software in particular, could be useful in sharing a common culture.
Sharing will also be necessary more generally with suppliers and partners. Traditional contractual relationships make optimisation complex (need for contracts, TMA, etc.). A change of culture, but above all more sharing upstream of contractualisation, will be necessary.
Sharing good practice and experience will also be beneficial outside the organisation. Given the complexity of the systems and the challenge of reducing them, it is necessary to collaborate and bring together all the digital players.
4. DevGreenOps best practices
4.1. A reminder of DevOps best practice
Agile practices have led to less formalised specifications. At the same time, deployments in the cloud have increased the complexity of a more “monolithic” system. These changes have made it necessary to modify the verification of the system. In particular, it has been necessary to anticipate upstream tests (shift left) and postpone downstream tests (shift right). Shift left allows development teams to launch tests to detect problems as early as possible. The right shift is used to launch production tests to analyse anomalies in the system (more info).
4.2. Shift right quality
Checking good development practices by analysing code will help to avoid certain practices that would consume resources. The use of quality gates will make it possible to block the following stages (testing, deployment, etc.) if the desired criteria are not met.
However, it is important to focus on good practices that have a significant and proven impact on the sobriety of the final product. It would not be very effective to correct violations of good code practices that have no real impact. Unlike traditional code quality categories (maintainability, readability, etc.), good sobriety practices have the advantage of having a measurable effect… as long as they are measured.
4.3. Shift left and Shift right for measurement
The impact must be measured as early as possible to identify ‘hotspots’ in terms of consumption of energy or other material resources.
Deploying the software from the code and build phases on dockerised environments will enable automated tests to be launched and the consumption of APIs, the backend and even interfaces to be measured. You can also monitor the impact of mobile applications by compiling APKs and IPAs. By testing at a very early stage (shift left), it will be easier to identify the causes of any over-consumption, because the observation will be made as close as possible to the coding stage. You can then correct the situation as early as possible and keep the project in line with its impact objectives.
It should be noted that unit shift left tests are not necessarily useful from a DevOps point of view, as they are similar to microbenchmarking practices, with the associated interpretation bias (representativeness of the test, need to run numerous iterations, etc.).
Downstream, shift right tests can also be run to detect hotspots. The advantage of testing in the downstream phases, even in production, is to detect violations that cannot occur in the development environment: for example, because they are caused by third-party services that are not present in the upstream environments.
4.4. Feature flipping and A/B testing to assess impact
Good DevOps deployment practices can of course be used in DevGreenOps, particularly in the context of learning and improvement loops. Deploying best practice implementations and using A/B testing, coupled with impact measurements, will make it possible to identify the real gains or quite simply the environmental gain or cost associated with a best practice or feature. For example, feature flipping can be used to activate a function, measure it during a user journey, then deactivate the function and run the measurement again. The difference between the two measurements will reveal the impact of the feature being tested.
4.5. New metrics and environmental projection
In a DevGreenOps approach, CPU, RAM and exchanged data metrics should take on even greater importance than usual. They are good indicators of bottlenecks or aspects that consume code. However, we need to go further: we need to introduce new, less common metrics such as energy consumption. Energy will be a very useful metric for determining the impact of the software during its usage phase on the server and on the terminal. It can also be used to calculate the impact during the hardware manufacturing phase.
Particular attention will be paid to the environmental projection model used to calculate the impact of the digital service in terms of CO2e and other environmental metrics. This impact model is responsible for converting the technical metrics measured (energy, CPU, volume of data transferred, etc.) into environmental impacts. Calculations based on secondary metrics (number of requests, DOM size, page weight, etc.) or using an impact model that is too simple risk giving a very inaccurate view of the impacts, leading to ineffective optimisation work and giving the illusion of progress by missing the essential points.
Note on metrics:
The metrics monitored include:
- Energy, for the user terminal and server;
- Greenhouse gases in CO2e, by third party (terminal / network / datacenter) and/or with breakdown by life cycle phase (at least: manufacture, use);
- Impacts on criteria other than greenhouse gases: see the RCP (Rules by Product Category) published by Ademe for the digital sector;
- Any ecodesign score that takes into account primary metrics (energy, CPU, etc.).
5. DevGreenOps tools
Specific Green tools will be added to the existing DevOps tools. They will have to comply with the best practices set out above. They will be integrated with existing sequencing tools (Jenkins, Gitlab, etc.) and/or potentially with reporting tools (Zabbix, etc.).
Here are just a few examples, although the list is not exhaustive.
| Référentiel NR | Greenspector Studio | Scaphandre | Power API | Carbonifer | Easyvirt | Ecocode | ||
|---|---|---|---|---|---|---|---|---|
| Plan | Guideline for decision-making and management | X | ||||||
| Language and architecture benchmark | X | |||||||
| Analysis of metrics from previous loops for improvement. | X | X | X | X | X | X | ||
| Code | Analysis of best practice | X | ||||||
| Measurement if deployed on a stagging environment | X | X | X | |||||
| Build & test | Measurement in a stagging environment | X | X | X | X | |||
| Release | Use of metrics to decide if Go/NOGO | X | X | X | X | X | ||
| Deploy | Measurement in production for validation following production launch | X | If hosted solution | X | ||||
| Operate & Monitor | Continuous measurement for monitoring | X | X | X |
Note on measurement tools :
Greenspector
Scaphandre de Hubblo
Carbonifer
PowerAPI
EasyVirt
Measuring websites and mobile applications on real devices
Measurement of backends in a containerised or virtualised environment (frontend measurement possible in a virtualised environment)
Measuring Cloud solutions
Measurement of virtualised or physical environment (PC, Server)
Monitoring virtual machines
6. DevGreenOps metrics
The metrics used to manage the DevGreenOps approach are not technical metrics or even environmental metrics. They are metrics that will enable us to measure progress in improving the impact of the digital service. Here are 3 suggested metrics:
6.1. Rate of teams (squads/feature teams/projects, etc.) that have implemented an OKR Green
The integration of DevGreenOps into teams will be a gradual process. You need the right tools to measure regularly… Each team, depending on its area and workload, will be able to integrate Green metrics or KPIs, as part of an OKR (Objective & Key Results) approach. The target will of course be 100% coverage over time.
6.2. Rate of improvement in key indicators
The environmental budgets and KPIs that have been set will be monitored over time. Improvements to these indicators should be studied during the Plan phases: what targets should be set for the next iteration? We can monitor the progress of the DevGreenOps approach by evaluating the percentage of teams whose key indicators (for example, the CO2 impact for a typical user journey) are improving.
Please note that an increase in the number of functionalities or their enhancement should not be used as a reason to justify an increase in these KPIs. It will be necessary to find ways of maintaining this metric, or even reducing it. We also recommend monitoring unit impacts (per page, per transaction, per user path, etc.) as well as the overall impact (unit impact x number of uses) in order to keep the impact of the digital service under control and avoid rebound effects.
6.3. Correction rate for the number of “Green” anomalies detected
Code analysis and measurement will detect breaches of good practice or lead to the creation of Green bugs. These anomalies need to be taken into account if the DevGreenOps approach is to be truly integrated into the process. The rate of correction of these anomalies is therefore an interesting indicator to monitor, and to compare with the rate of correction of other categories. For example, the way in which this metric is monitored can be modelled on security metrics.
7. The challenges of DevGreenOps
Let’s finish by mentioning a few specific challenges that you are likely to encounter when implementing a DevGreenOps approach.
7.1. Green in the DevOps chain itself
Reducing the impact of the digital solution developed will be the main objective of DevGreenOps. However, it will be necessary to monitor the impact of the tool chain itself. Accelerating releases and increasing the number of tools will naturally lead to a higher impact. A one-off assessment of the impact of the software factory will be possible to identify the relationship between the impact of the digital service produced and that of the factory – other tools, dedicated to assessing the impact of the IS, may be useful for this. This observation can be used to identify improvement actions. It will also be necessary to rationalise the tools and consider the pace of release.
7.2. Professionalisation and structuring of measurement tools
Environmental measurement and projection tools are emerging. Their promises are sometimes similar, but their impact measurement and projection methodologies are often very uneven. There is no standardisation on these subjects – although some work is underway, and we are contributing to this through ISO and W3C – but in the meantime it is important to be vigilant when choosing your tools.
The metrics measured, the measurement methods, the impact model applied, and of course the compatibility with integration into the DevOps chain all need to be taken into account. This is a requirement of the new versions of the RGESN.
7.3. Integrating a culture of sobriety
Over and above the tools and metrics that need to be put in place, we need to really integrate a culture of sobriety. The solutions for reducing impact are not only technological. Radical changes are sometimes necessary, including changes to the business model, for example. In addition, it will be essential to integrate new concepts into the teams (impact, energy, sobriety, etc.) that have not been learned in the university courses of the current teams. Beyond environmental impacts, a more general reflection on responsible digital is essential.
Without a real change of culture within the IT Department, there is a high risk that efforts to implement DevGreenOps will not lead to improvements. If there is a gap between communication and results, there is even a risk of greenwashing.
Conclusion
The transition from DevOps to DevGreenOps seems essential if we are to meet the major challenge of reducing the environmental impact of digital technology. It means putting in place a new tool-based approach, but also a change of culture.
Application projects are incorporating new requirements, expressed in terms of environmental impact or other sobriety indicators, which in turn are driving the need to measure new technical indicators. Throughout the project cycle, we therefore need to add the measurement and monitoring of compliance with these indicators. The metrics collected will be used to initiate an impact improvement loop. This will be achieved through close collaboration between current DevOps players, but also with new players such as CSR teams.
So, are you ready for a change of culture?
