How Asergo Is Building a Fault-Tolerant Future with BEAM and Gleam

Introduction

Picture this: It is Monday morning, and the Asergo team is logged in from across Europe for our weekly meeting. Coffee mugs in hand, we are all on camera, ready to tackle another week. During the meeting, the same familiar challenge comes up. One of our senior developers is deep in maintaining a legacy module he wrote years ago because, let’s be honest, he is the only one who truly understands it. Meanwhile, our newest team member is finding it tough to get up to speed and contribute meaningfully. Why? Because our codebase spans multiple languages and frameworks, each with its own quirks.

This scene is all too familiar. After 25 years of innovation and growth, our software stack has become a complex web of over 200 repositories written in various languages. While this diversity once served us well, it is now causing bottlenecks. Developers often find themselves waiting on each other because only a handful of people can maintain specific parts of the system. Onboarding new team members takes longer than we like, and development slows to a crawl as we navigate the intricacies of our polyglot environment.

We have come to realize that having everyone mostly using the same language and leveraging shared cross corporation frameworks is a necessity for our future growth.

In this blog, I will explore how we are addressing these challenges by adopting BEAM and Gleam, the benefits and risks of this transition, and our pragmatic migration path.

The Challenge: A Complex Legacy

Our current software stack, while rich in diversity, presents significant challenges that impact our development efficiency. The complexity of maintaining multiple languages and frameworks has created maintenance bottlenecks, where only a handful of developers can effectively work on specific parts of the system. This situation leads to dependencies that slow down our development cycles and create operational inefficiencies.

Additionally, the variety of technologies in our stack complicates onboarding for new team members, extending the time it takes for them to become productive contributors. The intricate web of over 200 repositories spanning multiple languages has also made scaling and maintaining our system increasingly difficult as we continue to grow.

Recognizing these limitations, we have decided to implement a strategic shift in our development approach. While we will continue to use languages like Go, Python, and Java where appropriate, we will primarily focus on standardizing around one core language for the majority of our development work. This consolidation aims to streamline our processes, enhance team collaboration, and ensure the long term maintainability of our systems while still leveraging the strengths of our existing technologies where they provide the most value.

What is BEAM

In the mid-1980s, engineers at Ericsson were working on a programming language that could handle concurrent activities efficiently. This language was Erlang, and it was designed to manage telecommunication systems that needed to run continuously without failures.

To bring Erlang to life, Ericsson created the BEAM virtual machine. BEAM is the runtime environment that executes Erlang code, much the same way that the JVM is the runtime for the Java programming language.

What makes BEAM special is its ability to handle real world problems where things can go wrong, but the system needs to keep running. This makes it a great choice for applications in telecommunications, banking, and other critical applications, such as Kubernetes infrastructure management, where uptime and reliability are crucial.

The Solution: BEAM as Our Strategic Foundation

After careful evaluation, we are making a strategic shift to BEAM, the Erlang virtual machine that powers some of the world’s most reliable systems. Unlike traditional runtimes, BEAM is purpose-built for distributed, fault-tolerant applications with features like

Lightweight processes that enable true isolation between components
Supervision trees that automatically restart failed processes
Hot code swapping that allows zero downtime updates
Message passing architecture that eliminates shared state concurrency issues

This is not just an incremental improvement, it is a fundamental shift toward an architecture designed for resilience from the ground up. BEAM’s proven track record with companies handling massive scale at WhatsApp, Ericsson, and Goldman Sachs demonstrates its capability to meet our reliability requirements.

Why Change Programming Language?

With our decision to adopt the BEAM virtual machine as our foundation for software development, we face a fundamental constraint, most of the well known programming languages we have used in the past simply do not run on BEAM. This architectural choice necessitates a change to a new programming language that can fully leverage the unique capabilities of the BEAM platform.

While we have extensive experience with languages like Go, Python, and JVM based options such as Java and Scala, these technologies are incompatible with our new BEAM based architecture.

Why Gleam?

By choosing BEAM as our platform, we committed to embracing functional programming, a paradigm shift from our traditional object oriented approach. This decision required careful consideration of which BEAM language would best facilitate this transition.

After looking at more languages, we ended up evaluating three BEAM compatible languages: Erlang, Elixir, and Gleam. While Erlang is the foundation of the BEAM ecosystem, its Prolog like syntax presents a significant learning curve for developers accustomed to more mainstream languages. Elixir, with its Ruby like syntax, offers a more familiar approach but still requires developers to adapt to different paradigms. Gleam, however, provides a simpler and more intuitive syntax with a strong focus on readability and maintainability.

The decision between Elixir and Gleam ultimately came down to two key factors. First, Gleam’s syntax is designed to be more straightforward and easier to learn. Second, and most importantly, Gleam is statically typed, a feature neither Erlang nor Elixir offers. This static typing provides compile time safety checks that can significantly reduce runtime errors and improve overall code quality.

We acknowledge the risks associated with adopting a newer language like Gleam, particularly the smaller ecosystem and community support compared to more established options. However, we believe these risks are outweighed by the benefits. Gleam’s combination of familiar syntax for OOP developers, static typing for reliability, and full BEAM compatibility offers the best foundation. The language’s focus on simplicity will help our team transition more smoothly to functional programming on the BEAM platform while still leveraging all the power that Erlang/OTP provides.

Our Pragmatic Migration Path

Recognizing our resource constraints and the need for a smooth transition, we are taking an incremental approach focused on strategic components. Our migration path is designed to minimize risk while maximizing the benefits of BEAM and Gleam.

Starting with the Consumption Billing System

The first system we have tackled is not a new system but a rewrite of our consumption billing system. This system is responsible for tracking and processing overuse of bandwidth and storage consumption for our remote storage systems. It collects data usage from various sources, processes this data, and then pushes it onto our message bus to be picked up by our invoice system.

Why We Chose This System:

The consumption billing system represents an ideal starting point for our migration to Gleam and BEAM for several strategic reasons. As a rewrite project, it provides our developers with a practical template and hands on experience with the new language and runtime in a controlled environment. This allows the team to become familiar with Gleam’s syntax and BEAM’s operational characteristics without the immediate pressure of production critical requirements.

Importantly, this system is not essential to our core operations, which means any initial challenges or learning curve issues encountered during the migration process will not affect our customers’ deployments. This noncritical nature makes it the perfect candidate for experimentation and iteration as we develop our expertise with these new technologies.

While the consumption billing system operates somewhat independently from our main services, it still maintains important connections to our message bus and invoice system. This integration provides valuable opportunities to test and refine our approaches for connecting Gleam based components with our existing infrastructure. By beginning with this system, we can build both technical confidence and operational competence within the team, establishing a strong foundation for future migrations of more critical systems.

Looking Ahead: The Journey with Gleam

The road ahead may present its share of challenges, but the promise of enhanced reliability, boosted developer productivity, and a scalable foundation makes every step worthwhile. We’re thrilled to keep sharing our progress as we evolve our architecture, ensuring we continue to deliver outstanding value to our customers.

Stay tuned!