When talking about carbon footprint of an application, we should normally consider two angles. How much energy was used to run it (i.e., number of cores, time of execution, hardware efficiency, etc.) and how much producing that energy impacted on the environment, which is called carbon intensity and depends on the location, time, and type of energy utilized (gas, coal, wind, etc.) for datacenters. A study from 2016 proved that around 55% of the consumed energy depends on the computing systems, and the remaining 45% is used for supporting the compute (cooling, ups, etc.). In addition, if 80% of U.S. small datacenters were moved to hyperscale providers, the electricity consumption usage could drop as much as 25%.

The year 2020 marked the beginning of a common global awareness in the IT world: software and applications have a footprint that must be taken in consideration, and algorithms are being developed to assess such footprints.

I have been recently exploring with a bunch of fellow Cloud Solution Architects the innovation of Dapr, a recently created open-source project for a distributed application runtime. According to its main page, “Dapr is a portable, event-driven runtime that makes it easy for any developer to build resilient, stateless and stateful applications that run on the cloud and edge and embraces the diversity of languages and developer frameworks.”(Find additional information) The main dream-like features of Dapr are indeed its simplicity of implementation and its ability to work across any programming language, framework, and infrastructure.

In a recently released Dapr book, there is a specific passage on sustainability with Dapr, which prompts developers to start thinking about sustainability when they approach their software architecture. While figuring out the way Dapr works, I have tried to apply the sustainability angle to it, and found out three main aspects where a green developer might want to focus:

1. How the application can measure its own carbon impact.

This might not seem difficult, but you need to remember that in a distributed solution we can have several different infrastructure environments and programming languages. Ideally this should be done via a dedicated microservice that can continuously monitor the carbon impact across every source of energy, and that is able to feed the other parts of the application with this information. Dapr is very precise in measuring the performance impact of its infrastructure and to offer guidance on how to measure the performances used by the microservices adopting Dapr. As mentioned in the public documentation, there are ways to retrieve CPU and memory usage that can help carve out the overall carbon impact. Also, in a recursively fashion, this microservice should also monitor its own carbon impact. 😊

2. How the application can drive/change its carbon impact by steering its IaC (Infrastructure as a Code)

Imagine that you have a microservice that can instantly monitor the carbon impact and feed the results to any subscriber of this information. Because the carbon impact is not a fixed amount, and largely depends on the energy conditions of the datacenter where the infrastructure resides, the application can have an automation that triggers the move of all or parts of the infrastructure towards less impacting sites or regions. This might not be immediate or even feasible for some regions (think of data sovereignty and latency, for example), but where applicable, the result would be a highly optimized sustainable infrastructure for the distributed application, that can guarantee to run in the less impacting infrastructure (and probably the cheapest, for the same reason) at any given time. As a side effect, this adds to its resiliency as the application can span several different environments.

3. How the application can drive/change its carbon impact depending on the user behavior.

This is an Sustainable Software Engineering technique that requires special attention because it involves the user experience and the education of users towards sustainability. The application can provide different levels of features depending on the carbon impact of such features (as measured by the above mentioned microservice) and offer a diversified user experience, according to the impact level of the feature, leaving the informed choice to the end user. Have more time to spare? Why don’t you try this slightly-higher-latency level which saves xx% of carbon by using a greener infrastructure? Do you really need to load all high-res pictures? Try the low-quality site for some additional carbon saving, and so on.

This obviously presents some overhead on the programming side, but the beauty of its execution is that the application will define and educate the end users to have a saying on their impact, and after a while by monitoring the choices users made, you can also have feedback on how they want to interact with your software. With time, you’ll have a clear picture of which combination provides a better trade-off of performance and energy savings. Dapr favors asynchronous architectural patterns, especially relying on a publish/subscribe interaction between microservices. Handling requests with this approach by scaling out and in can achieve the best compromise between dynamic response to user demands and control on the resources we want to provide for our workload.

Since Dapr is a open source and community-driven project, this is a call for action for developers to create an explicit branch of it dealing with the green impact of a distributed application: a blueprint to measure, control and optimize the energy efficiency of the microservices that cannot be left out of a modern innovative software architecture.