Towards a greener DevOps lifecycle

This is the last part of our series about the open-source project GitLab. Previously we have talked about the context, the architecture and the quality assurance processes of GitLab. To finish off, in this article we will make a sustainability analysis of both GitLab as the company and as the project. We will assess the supported and used infrastructure, search for features improving energy efficiency and investigate the impact of being an all-remote company. Additionally, we will see how GitLab employees value sustainability for them and the company.

Staying at home

At the time of writing this, urban areas are rapidly starting to show signs of lower pollution due to people working from home as a result of the 2019 Corona outbreak¹. In this section we will use available sources to give an estimation on what impact being remote-only has for GitLab’s carbon footprint.

There are several aspects of working from home that could influence the carbon footprint of employees. Perhaps the most obvious one is daily commuting. GitLab employees do not have to drive or take public transit to work. Especially in countries where public transit is not widely available, this can make a significant impact.

However, to compensate for the lack of real-life encounters GitLab employees have, they have a yearly summit called Contribute. While this is probably a necessity to keep a healthy work environment, it has the downside that a large number of people are flying all over the world. The figure below indicates of how this compares with not having a car².

Comparison of emissions from individual actions from research by Wynes & Nicholas²

This leads us to conclude that while it may be beneficial for local pollution as a result from both not having to live in already densely populated areas and not having to travel to work, the total carbon footprint of flying outweighs not having a car on average. While no actions have been taken thus far, according to a comment on one of our issues an effort has been started to perhaps offset the carbon footprint of these flights and to start other sustainability projects.

Lastly, we had a look at the available literature on the environmental impact of an office. There is not a lot of research available, probably due to the various variables that come into such an analysis; construction, isolation and climate are just a few to name. Therefore, the results we will present are meant to give a very rough estimate and could vary greatly, so they should not be taken for absolute truth.

In their analysis of three fifty-year case studies of Finnish offices, the authors found that the buildings had between 3 and 4 ton CO2 equivalent pollution per square metre over their fifty year lifespan³. While we couldn’t find a study on the average office space needed per employee (which probably also differs per country and company), the Dutch government aims to have around 25m2 office space per employee. Using this indication would result in between 1,5 and 2 ton CO2 equivalent pollution per year per employee⁴. Looking back at the image, this would mean that not having an office compensates a transatlantic flight. However, as mentioned this greatly depends on the circumstances.

Awareness of sustainability at GitLab

In the week of March 30th, we had two calls with GitLab employees. The first was with Zeger-Jan van de Weg, who is the Engineering manager of the Gitaly team. The second was with Marin Jankovski, one of the first employees of GitLab, who currently has the role Senior Engineering Manager, Infrastructure, Delivery & Scalability. During both calls, we asked them about how they experienced sustainability within GitLab.

Zeger-Jan explained that for Gitaly, sustainability is not a priority. The responsibility is partially pushed off to their cloud provider, which we will look into in the next section. In terms of architectural changes and code development, sustainability is not a factor when making decisions.

In our call with Marin, the answer on what GitLab’s sustainability policy was, was quite short. He wasn’t aware of any. However, we also got to discuss the next big architectural change for GitLab, which is to move from GitLab as a monolith to running on Kubernetes. While this change was not motivated by sustainability, the automatically scaling nature of Kubernetes helps prevent idly running VMs. As a result, less energy is wasted while running GitLab, which is an improvement on the sustainability front.

GitLab’s handbook⁵ and the issue tracker shows no relevant hits when searching for sustainability, energy consumption, energy efficiency or carbon footprint. It would appear that GitLab indeed does not have a policy on sustainability. While that may be true, this does not mean sustainability is not relevant to its employees. In this issue, one can see the spirited discussion among employees on ways GitLab can reduce their carbon footprint. While there aren’t a lot of issues that address sustainability at GitLab, this does show that GitLab’s employees want to inspire themselves and each other to be conscious about the topic.

Pick your cloud provider

GitLab provides official installation support for different operating systems, container managers and cloud providers. We assume that large customers will most likely opt for a cloud solution or hosting at gitlab.com. In this section, we will asses, based on the Greenpeace Clicking Clean 2017 report⁶, the environmental impact of the supported cloud providers and the hosting of gitlab.com. Before assessing the environmental impact of the different cloud provides, we want to stress that usage of the cloud is, for most applications, already better than self-hosting, due to the higher utility of the machines⁷.

All of the three biggest western cloud providers, namely Amazon Web Services (AWS), Google Cloud Platform (GCP) and Microsoft Azure, come with official support. Both GCP and Azure score relatively well according to Greenpeace as visible in the snippet below. Greenpeace explains in the report that the low score of AWS is partly due to the lack of transparency. Obviously, the report is already three years old and things can be changed. However, AWS is recently accused by Greenpeace to break its commitment⁸ and thus it is not apparent that it is getting better.

Snippet from the Greenpeace Clicking Clean report.

GitLab also provides its product as software-as-a-service where one can create public and private repositories on gitlab.com. The infrastructure of this service is expected to handle significantly higher loads than instances of self-managed customers. Recently, GitLab has decided to migrate its complete production environment from Azure to GCP to reduce the costs, failure rate and latency⁹¹⁰. The details about the migration and the openness around it are a textbook example of the values of GitLab and could be the subject of another article. Although sustainability was not part of the objectives of the migration, it was a step in the right direction according to the Greenpeace report.

Automate deployment and scaling

At the time of moving from Azure to GCP, GitLab was already in the middle of another migration. Several hundreds of virtual machines were required to host gitlab.com, and the operations part of deploying these will soon become infeasible. Therefore the decision was made to enable GitLab to run on a Kubernetes cluster. This would provide automatic deployment and scaling which would reduce the workload of the operations department. This migration, however, was far from finished at the time of the move and caused the start at GCP with a similar setup as used at Azure.

There are two details important to mention about this migration. First of all, it is an incremental project which is currently still in process. And second, while Kubernetes is mostly used for microservices, this is not what GitLab is after. The whole software suite is split up into a small number, with only seven in the current proposal¹¹, of distinct services which will be separately scalable.

Usage of Kubernetes does not only decrease the load on the operations department, but it is also able to scale faster than the department can do manually. This reduces the number of idle resources which in turn decrease the cost and energy consumption. In some cases, the average CPU utilization increases with a factor of ten¹².

Conclusion

From our calls with GitLab employees and the available literature such as GitLab’s handbook, we conclude that GitLab does not have an official policy on sustainability. That being said, they do have a record of taking actions that are beneficial to environmental sustainability. Examples of this are picking the greenest cloud provider, moving their deployment to Kubernetes, but also being a remote-only company. It can also be seen that some GitLab employees value sustainability, which might help GitLab make more choices that are favourable for sustainability in the future. In terms of sustainability at this moment, GitLab does a good job and could keep this up by cutting their most environmentally unfriendly choices, such as transatlantic destinations for its yearly conference.