Sustainable APIs benefit most from minimalism, Jochen Joswig said at OOP Conference. Deployment should consider energy, usage, carbon intensity, hardware acquisition. Remote work, long device lifespans, and green office practices can lower emissions. Efficient CI, selective builds, smaller artefacts, and optimized assets can further reduce energy use.
DevGreenOps is an extension of the DevOps approach, in which environmental sustainability considerations are integrated into every step of the DevOps cycle. Applying transparency, minimalism, efficiency, and awareness, helps to design sustainable digital services.
There are many ideas for ensuring the ecological sustainability of APIs, Joswig said. The API Thinking collective has an overview of best practices in their Sustainable API Green Score. Most of the practices fall into the transparency, minimalism, and efficiency categories. Joswig argued that projects will see the greatest benefits from practices in the minimalism category, like: “decommissioning unused APIs”, “exchange with the smallest size”, “optimize queries to limit returned information”, or “collect only required data”:
These best practices not only reduce the bandwidth, hardware resources and energy footprints of software providing the API, but they are also a clear indication of clean and well maintained code.
The recommendations of “deploy API near consumers” and “Be near Data Centers” are among the most controversial, because they seem to contradict the idea of location shifting, Joswig said. But location shifting itself is also controversial; it might be less sustainable than it looks:
- Leaving resources in “suboptimal” locations under utilized or idle is hardly efficient.
- Constantly moving data from location to location will increase the load on the network in between, which results in the need to expand it, which results in more emissions during the build out and during the operation.
Deploying software into data centers in a sustainable way depends on multiple factors, like:
- How much energy is needed to host and run the software vs. how much energy is needed to transfer the data
- How big is the expected average difference in carbon intensity for the particular use case
- Does the software deployment result in new hardware acquisition at the deployment site
It is important to look at use cases for expected average carbon intensity, Joswig said. If, for example, you can be sure that your software won’t run during the night, then your software will benefit from the presence of solar energy in the grid, which helps keep the energy carbon intensity low during the day. Even if during the night the carbon intensity of the grid is very high, your use case won’t be affected by this, he said.
One of the most sustainable actions any software-building company can take is allowing remote work. The study from the Öko-Institut Arbeiten im Homeoffice – gut für die Umwelt und die Mitarbeiter:innen? shows that working from home can greatly reduce CO2 emissions, especially if no additional hardware has to be acquired. Joswig mentioned that when employees commute, then providing convenient infrastructure for bicycles and supporting ride sharing among employees can be very impactful too.
Joswig mentioned that other factors of sustainability are devices like laptops, smartphones, monitors, keyboards, mice, routers, servers, etc. Utilising them for as long as possible and ensuring a long lifespan is important. When devices must be replaced, they should find a second home e.g. through refurbishing or donation programs.
Inside the office, we can do a lot to be more sustainable, Joswig explained:
We can choose green energy providers and save energy by turning off lights, monitors, coffee machines, etc. during the night and over the weekends. We can shift towards a paperless office, and we can try to save water.
Applying DevGreenOps, a tool like EcoCI can measure or estimate the energy required by any pipeline run, including a build pipeline run. For the “minimal” category, Joswig advises a “build once deploy everywhere” approach, for teams working with different environments for development, testing and production. Teams working with mono-repos only need to run builds for the parts of the code, which have actually changed. Only build the frontend, if the frontend code changed, only build the backend, if the backend code changed, don’t build anything if only the documentation was updated, Joswig suggested.
There are tools that help you reduce the size of your build artefacts, like SlimToolkit for Docker containers. Most build tools and frameworks, especially for frontend web applications, already come with support for optimizations of the build output, Joswig said. Tree shaking, minification, and compression of static assets should already be the standard in every production build.
Some tools can also do more, like Parcel, which supports differential bundling, development branch removal, and image optimization. Image optimization is an especially interesting feature, because images are typically responsible for most of a web page’s weight, Joswig explained:
Having a build tool like parcel, which can automatically convert images into web optimized formats, and resizes them to only what is really necessary, can save a lot of bandwidth, memory and unnecessary computation on the client.
However, overrelying on such features may result in unnecessary load during the build process itself, Joswig concluded.
