DEV Community: MOmentum

How Migros Online protects its assets with Cloudflare - a DDoS Story

Marc Schär — Thu, 29 Jan 2026 07:35:48 +0000

Nowadays, attackers are more and more eager to get your website down, to gather your data, to exploit every little vulnerability you might have. It has become a major concern for every company to protect itself against any malicious activity.

When thinking about what to put in place to improve your security, you have mainly two situations:

You're big enough and have the knowledge in-house to manage the whole security stack
You don't have the expertise or you don't want to spend a huge human effort on setting up the security

In the first case, you need to have one or multiple teams dedicated to the security to build a safe and secure infrastructure and to keep it up to date with the latest vulnerabilities found. Knowing that you should ask yourself "when" and not "if" you're going to be attacked, this team should also know how to react when something goes south at each security level.

For small companies or companies that don't want to invest in a highly-skilled security team, you will probably search for market solutions and providers that are able to handle these concerns for you, or at least that are going to ease the management of many security aspects. Nevertheless, it won’t prevent you from having security dedicated people to manage the selected solutions as well as other security aspects, like people awareness to prevent phishing for example.

Beware that choosing a third party comes with its downsides: you become, at a certain level, dependent of their infrastructure, their partners and their problems (availability, security). Thus, you can encounter issues over which you have no control.

Migros Online and Cloudflare

At Migros Online, we decided a few years back to work with Cloudflare to have a unique entrypoint for our infrastructure (on-premises back then, in the cloud today).

Using such a tool brought us many security and performance aspects for our website and our mobile applications:

Content Delivery Network (CDN): edge caching allows us to serve assets without hitting the backend on every requests
Web Application Firewall (WAF): we are able to protect our public endpoints with simple rules in a few clicks (or a few Terraform line of code ;-))
Basic sets of rules that are managed by Cloudflare directly allowing us to fix deeper issues with serenity (as an example, the log4Shell vulnerability was automatically handled by Cloudflare, giving us the time to patch our backend systems without pressure)
Bot protection: automatic categorization of the traffic and possibility to easily act on requests based on the rating done by the platform
Distributed Denial of Service (DDoS) protection: automatic discovery of DDoS attacks and direct mitigation
Zero Trust mechanisms: we are able to expose private endpoints, but secure them behind the Zero Trust product, bound with our authentication provider
Cloudflare Warp: a tunneling solution to access internal resources that we don't want to expose publicly, even behind Zero Trust

Thanks to Cloudflare, we were able to consolidate our public exposure, simplify its management and get confidence that we are in good hands when problems arise.

Cloudflare Immerse 2025

As an example of Cloudflare's usage for Migros Online, I went on stage (for the first time!) during the Cloudflare Immerse 2025 event in Zurich to present how Cloudflare helped us in mitigating DDoS attacks we faced in the past.

The recording is available below and outlines the Migros Online context, what issues we faced and how Cloudflare was a key element in solving the problem.

English - the hottest programming language of the future

Sven Scheffel — Fri, 10 Oct 2025 17:26:33 +0000

We are all passionate engineers who love to follow our favorite frontend or backend framework, keeping up with new features, releases, or additions. Using various methods, we like to stay up-to-date, attend conferences, read blog posts, and even engage in communities that revolve around a specific framework. However, most frameworks are also tied to a specific language, a programming language most of us (hopefully) have learned to love and are fluent in.

These circumstances haven't changed for years, even decades, at least not beyond common tech trends and industry standards in the form of Microservices, Event-Driven Architecture, Domain-Driven Design, Serverless, you name it. Our beloved frameworks and languages eventually adapted to the needs of the industry, and we were able to keep using the tools and languages that we hold dear. Picking a different language or framework with similar features remained a matter of preference and personal bias, about which we have probably all, at some point, spent hours arguing over a hot coffee or cold beer.

Brace yourselves: Changes are coming!

Dark clouds of unknowns emerge and a storm of change is brewing. Visible on our horizon are changes that scare us and threaten our existing ways of working and comfort. It’s not a new language syntax or the 100th web framework that I am referring to, but an established language: English. English?? You might ask yourself: how is that a new programming language? English is the language that makes up the training data of most state‑of‑the‑art large language models (LLMs) (1). It’s one of the languages that every LLM is able to speak, but more importantly, it's the language spoken and understood by most people in the world (2). It is the language of humans. Why should it not also be the language of developing software?

Programming languages have evolved and changed over the past decades. The overall trend in these developments is an increased level of abstraction. Programming languages opened their doors to wider audiences, requiring less deep technical knowledge in the field of computer science. We usually do not need to worry about low‑level hardware optimization like manual memory management with pointers or hand‑crafting registers and stack frames for function calls. Just like me, you probably last heard all these things in university and did a small demo application on a microcontroller to let some LEDs blink like a Christmas tree, beautiful!

The language used was Assembler, which, by my standards, especially while also learning Java and C# in other lectures, seemed quite cumbersome. That's just one of the reasons why C and later languages like Java and C#, gained popularity. The profession of a software developer quickly shifted toward being able to focus on solving business problems by writing good and clean code, without worrying too much about the underlying low-level details. Heck, we even call it craftsmanship, that's how proud we are of our "craft"!

Once again, a new, much more drastic layer of abstraction has emerged: Large Language Models (LLMs)! More specifically, with the tools evolving around using LLMs to support engineers and other professionals to “craft” applications. However, this time the evolution is very different, as we are not only changing our flight level and the level of abstraction. We are also moving sideways into non-determinism at the same time (at least at the moment; there are experiments of LLMs being deterministic (3)).

Determinism, especially, is important for us engineers to ease our logic-oriented minds. Running an instruction twice with different outputs is not something we like. Overall, we have achieved a fair amount of abstraction with various frameworks but have not reached the level of being close to human thinking. This changes if we use our native tongue (for example, English) to express our thoughts and turn them into code.

Illustration: Birgitta Böckeler (source: LLMs bring new nature of abstraction)

AI Coding disappoints us?

Hopefully by now you've dipped your feet into AI coding using LLMs to supercharge your development workflow. On one day, you're one‑shotting results for tasks we expected AI to fail (and that would have taken quite some time if done manually); and on another day, you're trying to solve what seems (to us) like a pretty obvious bug, but the AI completely derails and suggests bits and bytes of garbage.

Overall, our trust and confidence in AI coding tools is dominated by these pivotal (but sometimes first) impressions. We try to wrap our heads around how "good" or "ready" the AI models are and how mature the tooling that uses LLMs is, when we do this only to give ourselves peace of mind and protect our software engineering craftsmanship. Studies show that at the moment software engineers are even less productive due to a high skill ceiling and the learning required when using AI coding agents (4). I am pretty sure all of us went through the same rollercoaster of emotions, for which I have a good analogy displayed as an illustration below. There are various resources on how to get the best results out of AI coding.

Illustration: Geoffrey Huntley (source: What do I mean by some software devs are "ngmi"?)

However, most of the time the simplest advice is to clearly specify your thoughts by translating them to English as input for an LLM. That's the point I want to touch on: our abilities as software engineers to express our thoughts and plans in English, to make them understandable.

Various memes make fun of the different languages that software engineers and business speak, often cited as reasons for missed deadlines, failed projects, or abandoned products. To cure this, we came up with Domain‑Driven Design practices to align on a so‑called "Ubiquitous Language" inside a domain or "Bounded Context" of our application and system. While speaking at the same level with business, we as software engineers are still translating the domain models, business rules, and specifications into a different language (hopefully the one we are so passionate about!). Need good startup performance and a low memory footprint? It's fine, we can use a language that has not been specifically designed for that and adjust it so that we do not need to learn a new language. Worst case, it's a language we were even arguing about in the past years of our professional life.

Instead of focusing on the mere translation into a more technical language, we often let other aspects like observability, testing, and resilience draw the short straw during prioritization. This leads to them inevitably ending up in the "Do eventually" section of our backlogs.

If you followed the last paragraphs, you’re hopefully asking yourself why we translate from English into Programming Language XYZ. We are aligned with our business on a shared language; we put effort into building our architecture to mirror our product domain. Why do we keep translating? Can’t we develop using only English?

Spec-Driven Development

If you feel your software engineer heart hurt when you hear the term "Vibe Coding," the next lines are especially for you! By Vibe Coding I am referring to the viral idea of a less technical user quickly building and deploying products by conversing with an AI Agent. Vibe Coding scratches the same no-code-utopia itch that has been promised for a long time: making software development accessible in a reliable and scalable way to a wider and less technical audience. "Build me a chat application" as a command rather than a suitable prompt leaves too many questions unanswered.

However, we all know software engineering usually goes beyond what's achieved in a simple vibe-coding session. Especially if the product matures from an MVP state to a product that requires maintainability and resilience, Vibe Coding quickly reaches its limits and leads to frustration. Bugs are introduced, fixed and then reintroduced. The application is vulnerable to attacks and proves to be unreliable.

How can we keep the language English and use it to generate software in a more reliable way? That’s where the idea of “Spec-Driven Development” comes in (5)(6). AI is (thankfully) bad at mind reading, so we need to be clear when expressing our intent in terms of technical requirements to fulfill the needs of our application and covering our business/domain rules.

So how do we achieve this?

The key difference is that we no longer separate the language used for describing the specifications and the language we use for implementation; instead, we leverage LLMs to do the translation into code for us. We are in charge of outlining the architecture and implementation details by clearly stating our intent as specifications rather than code. By doing this, we stay true to a real shared language across our product development lifecycle, as well as making sure that the technical requirements are documented in a central place and in the language everyone understands.

We are moving from code being the source of truth to intent being the source of truth, staying truly faithful to Domain-Driven Design.

Instead of "vibing" our applications together in a Ping Pong session commanding a new fancy Agent what to do or playing whack-a-mole on bugs, we want to properly outline the specifications of our application. We need to put our analytical and technical thoughts in words and clearly specify our intent to eliminate any ambiguity. The specifications need to be as clear as code and it is up to us to learn how to write them. We implement new features by adjusting the specifications, no longer by touching the code. In contrast to vibe coding where we usually start hitting walls and move to operate on the code level instead.

How about rewriting your application, or, more likely, a part of your system, to another programming language? If done right, and using Spec-Driven Development correctly, this should, in theory, be effortless, at least on a per-component level. You probably guessed it, but that goes hand in hand with the idea of Test-Driven Development (TDD)! It's even an abstraction of TDD since we should always check our product against the created specifications and use them as the source of truth! We mix the native-language advantages from vibe coding but enrich our instructions with clear intent and high-level technical details. This in itself requires the experience of software engineers to build a sustainable application or system.

Illustration: Dusan Omercevic (source: Beyond Vibe Coding)

Conclusion

Hopefully, my post inspired you to take a step back from low-level technical details and the specificities of languages or frameworks. We engineers usually have brains more tinkered towards logical thinking, and sometimes we have trouble expressing our thoughts in words. Work on your communication skills and how you express your thoughts in a natural language like English. Bring your technical writing skills to the next level to allow AI Agents to do the language to code translation for you.

Focus on understanding the foundations of crafting reliable applications and systems, and do not get carried away by a new syntax introduced in your favorite language XYZ. Let the LLM, and your development process with linting and tests, worry about that! Focus on what’s important and what your product has to fulfill, and let the LLM pick the suitable language that is created for that purpose. Most important, as you do by keeping up with new framework and language version releases, stay curious and keep learning how to use AI coding best in your position.

Will we see more frameworks and languages doing more or less the same things as existing languages but with a different syntax? Unlikely. Most likely we will use the languages the LLM is fluent in and that fit our specifications in the future, and we will need to look for other technical details to argue over hot coffees and cold beers!

Sources

Disclaimer: An LLM was fed with cookies 🍪 to find typos and generate the header image of this post.

How to run services locally with no fuss using spring-boot-docker-compose

Gabriel Dinant — Tue, 02 Sep 2025 05:42:28 +0000

Running services locally hasn't always been easy and still has its quirks. As soon as a service is integrated with external systems it can become challenging.

In this blog post, we will walk through how to set up a Spring Boot application that connects to multiple systems such as a message broker or a database, while using spring-boot-docker-compose to manage these dependencies as part of the application lifecycle.

Why & When to consider?

Using live environments during development has its own set of pros & cons.

✅ Common technologies supported by Spring Boot / Spring Cloud such as Kafka, MySQL, Firebase, RabbitMQ, and so on, are technologies that can and should be substituted whenever possible.

⚠️ On the flip side, mocking the behaviour of upstream services introduces complexity and should be carefully considered.

Use case

Consider a Blog Application that consumes Kafka events from a topic (blog.updates), calculates the sentiment of the given blogpost and pushes the final update in a RabbitMQ queue. For this exercise, let's pretend the publisher is also the consumer and eventually saves the processed result in a MSSQL server database.

Setup

Let's take a look at the complete picture of the project before diving into each part.

.
├── pom.xml 👈🏻
└── src
    ├── main
    │   ├── java
    │   │   └── ch
    │   │       └── migrosonline
    │   │           └── blog
    │   │               ├── BlogApplication.java
    │   │               ├── context
    │   │               │   └── RabbitMQContext.java
    │   │               ├── kafka
    │   │               │   ├── BlogPostUpdateEventListener.java
    │   │               │   └── model
    │   │               │       └── BlogPostUpdateEvent.java
    │   │               ├── processor
    │   │               │   └── BlogProcessor.java
    │   │               ├── rabbitmq
    │   │               │   ├── model
    │   │               │   │   └── ProcessedBlogPostMessage.java
    │   │               │   ├── RabbitMQListener.java
    │   │               │   └── RabbitMQProducer.java
    │   │               └── repository
    │   │                   ├── BlogRepository.java
    │   │                   └── model
    │   │                       └── BlogEntity.java
    │   └── resources
    │       ├── application.yml 👈🏻
    │       ├── application-LOCAL.yml 👈🏻
    │       ├── compose.yml 👈🏻
    │       └── init.sql
    └── test

This guide assumes prior familiarity with some bricks of the Spring Ecosystem such as @SpringBootApplication main class or @Configuration contexts. What is important to focus on here is the resources marked with a '👈🏻'.

pom.xml

The key dependency that must be added to the dependency management system is spring-boot-docker-compose. Any important details regarding spring-boot-docker-compose can be found on the Spring reference documentation.

<dependencies>

    ...

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-docker-compose</artifactId>
        <scope>runtime</scope>
        <optional>true</optional>
    </dependency>

    ...

</dependencies>

<build>

    <plugins>

        <plugin>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-maven-plugin</artifactId>
            <executions>
                <execution>
                    <goals>
                        <goal>repackage</goal>
                    </goals>
                </execution>
            </executions>
        </plugin>

    </plugins>

</build>

spring-boot-docker-compose is primarily a dev tool therefore Spring Boot won't be adding this dependency as part of the repackaged application (fat .jar). In other words, it won't be available in production builds unless explicitly specified.

When starting the application locally via IDE's plugins or the Spring Boot plugin, all runtime dependencies will be available on the classpath.

./mvnw spring-boot:run -Dspring-boot.run.jvmArguments="-Dspring.profiles.active=LOCAL"

Application properties

The application.yml file provides the default, production-grade configuration. By using Spring profiles, we can later define a LOCAL profile that overrides and leverages the compose.yml definition.

application.yml

spring:

  application:
    name: blog

  datasource:
    url: <URI_TO_A_REMOTE_DATABASE>
    username: SA
    password: ${DATABASE_PASSWORD}

  docker.compose.enabled: false

  kafka:

    bootstrap-servers: <URI_TO_A_REMOTE_KAFKA_SERVER>

    consumer:
      group-id: ch.migrosonline
      key-deserializer: org.apache.kafka.common.serialization.StringDeserializer
      properties.spring.json.type.mapping: blogpost-update-event:ch.migrosonline.momentum.kafka.model.BlogPostUpdateEvent

    security:
      protocol: SASL_SSL
      properties.sasl:
        mechanism: PLAIN
        jaas.config: |
          org.apache.kafka.common.security.plain.PlainLoginModule required username='kafka' password='${KAFKA_PASSWORD}'

  rabbitmq:
    host: <URI_TO_A_REMOTE_RABBITMQ_SERVER>
    port: 5672
    username: rabbitmq
    password: ${RABBIT_PASSWORD}

application-LOCAL.yml

spring:

  datasource:
    url: jdbc:sqlserver://localhost;encrypt=false

  docker.compose:
    enabled: true
    file: classpath:/compose.yml
    stop:
      command: down # 'docker compose down' on application stop
      timeout: 10s

  kafka:
    bootstrap-servers: localhost:29092
    security.protocol: PLAINTEXT

  rabbitmq:
    host: localhost

  sql:
    init:
      mode: always
      schema-locations: classpath:init.sql

By default, the docker.compose.lifecycle-management property runs docker compose up when the application starts and docker compose stop when it stops. These commands can be customised by redefining the start or stop command as shown in the application-LOCAL.yml file.

compose.yml

The compose.yml file is fully customisable and describes services to be substituted.

In the example below, a Kafka cluster (with a topic and partitions), an MSSQL database service, and a RabbitMQ service are defined.

services:

  kafka:
    image: confluentinc/cp-kafka:latest
    container_name: kafka
    ports:
      - "29092:9094"
    environment:
      CLUSTER_ID: clusterId
      KAFKA_PROCESS_ROLES: broker,controller
      KAFKA_NODE_ID: 0
      KAFKA_LISTENERS: PLAINTEXT://:9092,CONTROLLER://:9093,EXTERNAL://:9094
      KAFKA_ADVERTISED_LISTENERS: PLAINTEXT://kafka:9092,EXTERNAL://localhost:29092
      KAFKA_LISTENER_SECURITY_PROTOCOL_MAP: CONTROLLER:PLAINTEXT,EXTERNAL:PLAINTEXT,PLAINTEXT:PLAINTEXT
      KAFKA_CONTROLLER_QUORUM_VOTERS: 0@kafka:9093
      KAFKA_CONTROLLER_LISTENER_NAMES: CONTROLLER
      KAFKA_OFFSETS_TOPIC_REPLICATION_FACTOR: 1

  kafka-initializer:
    image: confluentinc/cp-kafka:latest
    depends_on:
      - kafka
    entrypoint: [ '/bin/sh', '-c' ]
    command: |
      "
      kafka-topics --bootstrap-server kafka:9092 --create --if-not-exists --topic blog.updates --partitions 2 --replication-factor 1
      kafka-topics --bootstrap-server kafka:9092 --list
      "

  mssql:
    image: mcr.microsoft.com/mssql/server:latest
    container_name: mssql
    ports:
      - "1433:1433"
    environment:
      ACCEPT_EULA: Y
      MSSQL_SA_PASSWORD: ${DATABASE_PASSWORD}

  rabbitmq:
    image: rabbitmq:latest
    container_name: rabbitmq
    ports:
      - "5672:5672"
    environment:
      RABBITMQ_DEFAULT_USER: rabbitmq
      RABBITMQ_DEFAULT_PASS: ${RABBIT_PASSWORD}

Alternative approach

Testcontainers is an alternative to substitute external services not only in tests but also in dev mode. If you are interested to know more you can read the official Spring documentation.

Conclusion

We saw how to wire production grade technologies all together in a seamless way with Docker and spring-boot-docker-compose, why and when this setup should be considered.

The full source code can be found ➡️ here ⬅️.

Happy coding! 👨🏻‍💻👩🏼‍💻

Written by Gabriel Dinant, Staff Software Engineer @ MigrosOnline

Green IT: for the planet and the wallet

Aurélia Rochat — Thu, 07 Aug 2025 09:11:32 +0000

IT systems play a major role in climate change.
What if we could all play a part in reducing the damage? The good news: we can and we’ll show you how.

A few months after witnessing the extreme drought situation in the Drâa Valley, Morocco, I attended Devoxx Conference in Antwerp. This was before the AI wave, full of inspiring sustainability talks which opened my eyes: having already made personal lifestyle changes to reduce my environmental impact, I needed ways to mitigate my professional impact. Devoxx talks—such as Towards a carbon aware cloud and The Fast and the Sustainable: Unleash the Power of Sustainable IT & High Performance Green Code—inspired me and motivated me to introduce the Green IT topic at Migros Online.

Drâa River: Morocco’s longest river, where no water can be seen

2030 is just around the corner, leaving us with less than 5 years until the first milestone of the Paris Agreement. Unfortunately, we are far from being on track to meet the agreement's goal of limiting global temperature rise to a maximum of 2 degrees Celsius compared to pre-industrial levels.

Digital technologies are responsible for 4% of the Greenhouse gas (GHG) emissions, overtaking the aviation industry. With increasing access to these technologies, especially in emerging countries, this figure is expected to rise exponentially. However our environmental impact extends beyond GHG emissions, and our digital habits impact various domains. The 9 planetary boundaries illustrate what is at stakes:

Evolution of the 9 planetary boundaries. Licenced under CC BY-NC-ND 3.0 (Credit: Azote for Stockholm Resilience Centre, Stockholm University. Based on Richardson et al. 2023, Steffen et al. 2015, and Rockström et al. 2009)

Most of the figures and reports regarding the impact of digital activities were published before generative AI became a thing. The substantial consumption of electricity, water and rare earth metals by AI systems makes any sustainability objective even more difficult to achieve and thus every sustainability effort even more important.

In this article we will go over the goals of Green IT, the benefits of a sustainable IT strategy and how we started implementing this strategy at Migros Online.

Why Green IT?

Green IT is a discipline aiming at minimising the environmental impact of digital systems. For an online retailer such as Migros Online, IT systems might only be a small portion of the overall environmental footprint. So why do we consider it to be important?

As the saying goes, we have to start somewhere, and green IT is a good starting point because many potential mitigations are easy to enact. Employees will have a positive impact by adapting their digital practices. Raising awareness helps build a broader understanding of sustainability, which in turn leads to lower energy consumption and reduced operational costs.

As AI becomes part of our daily routine, it is necessary to fully understand the impact of our actions to prevent the environmental impact from skyrocketing.

Companies have power, companies have impact. If you have power and impact, hopefully you also take the responsibility that goes with that.
— Feike Sybesma, Chair of the Supervisory Board, Royal Philips

After gaining the support of management, a bunch of people ready to roll up their sleeves gathered: Migros Online’s Green IT Guild was born.

Where do we start?

Since the beginning our objectives were clear: raise awareness among our peers and decrease the environmental impact of Migros Online digital systems.
However, the path to achieving those goals was much fuzzier. How could we make this happen based on some ideas sketched on a Miro board?

A little research made obvious that we needed a baseline—calculating the environmental impact of an IT system is a complex task that we would not achieve on our own. The digital environmental footprint of a company includes more than just the software it builds and the infrastructure behind it. It also covers all the digital systems and devices the employees use for their daily work: laptops, monitors, internal softwares (business, HR, product related, development, communication, wiki, etc.).

Additionally, when evaluating the impact of a system, we must consider the following three phases:

🏭 Manufacturing: mining of earth metals, hardware production, etc
💻 Usage: either by end-users or in data centers
🚮 End-of-life: disposal or recycling of the devices

We cannot improve what we cannot measure

Consequently we searched for experts, ideally a local company familiar with the Swiss market. We decided to partner with Mikujy, whose CEO and founder is currently the only person in Switzerland certified as a Sustainable IT expert. Our first objective with Mikujy was to conduct an audit which would provide us with the needed baseline and with an actionable plan.

Our action plan

The audit report in hand, we began addressing the most impactful items of the action plan:

Raising awareness
Cloud processes and data storage
Hardware renewal and purchases

Raising awareness

A key outcome of the audit was the need for awareness: empowered people make informed decisions. This can be achieved by providing training, impactful and relevant content, as well as communicating actively on Green IT topics.

None of us being environment specialists, we decided to involve external parties and rely on existing large-scale events:

Inspired by the Digital cleanup day, we launched the “Digital cleanup week” at Migros Online, encouraging employees to declutter their mailboxes, sharepoint, and other online storage systems. This simple action revealed that deleted emails were, in fact, never removed from the global system.
Mikujy presented a Green IT webinar open to every office employee
We started publishing ISIT (Institute for Sustainable IT) online MOOC in our internal channels

We also started creating our own content and organising internal events:

We gave a talk about the environmental impacts of AI and provided recommendations for a more efficient usage
We ran a sustainable IT challenge during our internal hack days
Sustainability was one of the jugement criteria for the internal hack days projects

We plan to continue promoting awareness by offering such content and challenges on a regular basis.

Cloud processes and data storage

The audit revealed a substantial volume of legacy data residing in the cloud, with 357 TB of data stored on GCP. Data engineers identified the most costly and environmentally harmful project, cleansed it from Migros Online’s data and processes, and returned it to its rightful owner. This allows us to save 3000 CHF per month and reduce our carbon emissions by 23t CO2eq, which is 14% of our systems emissions.
Moving forward, data engineers will revise the tracking data retention policy and evaluate other significant projects to further minimize their footprint.

In addition to data cleanup, we can apply temporal and spatial shifting to our cloud processes:

🕐 Temporal Shifting: Running tasks when electricity is sourced from green energy, such as solar panels or wind turbines.
☀️ Spatial Shifting: Relocating tasks in regions powered by green energy.

GCP provides a list of their cloud regions indicating the carbon-free energy ratio and grid carbon intensity. If a low-carbon region can meet our service needs, we should consider relocating our tasks there.

Hardware renewal and purchases

Renewing hardware at a certain frequency is highly desirable but has a significant impact. The largest part of the environmental impact of an end-user device occurs during manufacturing, while the impact during the usage phase is negligible:

IT footprint lifecycle by equipment, from Mikujy's audit report

"Outdated" laptops are resold to a refurbishing company. However, as long as we keep renewing hardware as frequently, new devices must be produced. No matter what happens once the warranty has expired: whether the laptop is refurbished or thrown away, it has to be replaced with a brand new one.

In our consumer-driven society, we need to distinguish the wish from the need. Who hasn’t eagerly awaited the last MacBook release? Who is not thrilled about unpacking a brand new pristine device? Most of our laptops still run effectively after their warranty expires and we want to encourage our employees to make a sustainable choice by extending the lifespan of their laptop to:

☁️ Reduce carbon emissions: through research of 230 laptops the average CO² emissions during production of a new laptop is 331kg where the majority of emissions come from production and materials used. More here: What Is The Carbon Footprint Of A Laptop?
🛠️ Reduce mining of earth metals: half of the greenhouse gas (GHG) emissions in the production of the graphics cards comes from the mining of earth metals
🌪️ Reduce pollution: producing 1 ton of rare earth elements produces 2000 tons of toxic waste
🌊 Save water: Approximately 39 million liters of ultra pure water is used daily by an average chip manufacturing facility, which is equivalent to the water used by 125’000 Swiss households daily
🚮 Avoid producing e-waste: only 17% of global e-waste is documented to be collected and properly recycled. E-waste ends up in landfills where it releases chemicals contaminating water, soil and air, endangering people and wildlife. More about e-waste: The Growing Environmental Risks of E-Waste

This table illustrates how our environmental footprint would decrease when extending the lifespan of laptops beyond the 3 year warranty:

Devices lifespan	4 years	5 years
Carbon emissions	-6 tons co2eq	-10 tons co2eq
Water consumption	-14%	-22%
Soils pollution	-17%	-26%
Abiotic resources consumption	-4%	-7%

Next Steps

Website optimisations

An audit of the 20 most visited pages on our website showed that its footprint is already quite low compared to our overall footprint. However, implementing eco-design principles where possible will be beneficial, and we are eager to dig into the the green software patterns recommended by the Green Software Foundation. In addition to reducing the ecological footprint of our website, eco-design principles should

improve the user experience: lighter and more efficient pages results in a smoother browsing experience
reduce⁠ hosting and maintenance costs: less resources and less bandwidth should decrease associated costs

Governance

In addition to the KPIs provided by Mikujy, we are developing our own set of KPIs to effectively monitor our progress and impact within the company.
We also intend to communicate more frequently about our actions and successes.

Roadmap

We drafted a roadmap running until 2027. This roadmap will evolve together with the outcome of the next internal audit we intend to run early next year.

Conclusion

Companies and their employees might be torn between AI and sustainability. However we cannot consider one at the expense of the other. AI has become part of most companies' toolbox, making the need for sustainable actions even more urgent. In addition to making our future possible, those sustainable actions will also reduce operational costs: usually making a smarter usage of resources leads to lower financial expenditures.

We strongly believe that by fostering awareness and implementing concrete actions we will make sustainability part of Migros Online core values.
As the Green IT guild we hope to be an example within the company but we also hope to influence others in the industry.

About the author

My name is Aurélia and I’ve been at Migros Online for more than 10 years, first as a front-end engineer, then as a team lead, and today as a staff software engineer.
I gained interest in the impact of digital technologies after attending the Devoxx conference in Antwerp in 2023. Having already made personal lifestyle changes to reduce my environmental impact, I sought ways to mitigate my professional impact and I am glad to lead the Green IT topic at Migros Online.