Replacing a Legacy Web App

You may have heard this old joke: the only way to move a mountain is one stone at a time. Legacy application migrations are nearly impossible to handle all at once. You have to break the problem into manageable pieces to even have a chance. Over the course of this section, we’ll walk you through this process. The resources available to you and the size of your platform certainly has an effect on how long this process will take, but the process will remain the same. There’s a political element and a technical one.

The political element involves setting expectations and managing risk. Throughout this book, we stress the importance of setting expectations. Programming is more than 1s and 0s. Successful programmers communicate.

The technical element is isolating small bits of the application to migrate, step by step. With a little time and effort, you can have a common web API that has two back ends, one for your legacy system and one for the new. Then, you can flip the switch, either all at once or one subsystem at a time.

Where you begin depends on a number of factors, including your company’s architecture and urgency. Let’s start with architecture, of which we’ll consider two general types: monolithic and service-oriented architecture (SOA). Many companies with scaling and code maintenance issues use a monolith of some sort. Monoliths are large systems written as a single project with little to no boundaries between its components. They are often hard to understand and maintain due to their size and the coupling they promote between components. Even worse, such large applications often take a long time to boot, followed by a long-running test suite, both undermining the development feedback cycle. Since monoliths are the hardest one to manage, we’ll assume your legacy system is a monolith.

Most organizations who adopt service-oriented architectures do so because they’ve been through the pain of managing a monolith. SOA is composed of many services that communicate via a protocol, such as HTTP+JSON or Apache Thrift. Replacing a service is a matter of looking at the Elixir ecosystem for libraries that implement said protocol and then replacing the problematic services by others implemented in Elixir while keeping the same API. One of the benefits of SOA is exactly the replaceability of subsystems and that’s what we get here.

Here is the plan. We will start with a case study from Bleacher Report on how they migrated their eight-year-old monolith gradually, discussing how they mitigated risk and their approach to incremental APIs. Luckily for us, the Elixir ecosystem has grown considerably since Bleacher Report took this effort and tools built specifically for interfacing with legacy systems have surfaced. After that, we will explore one of them called Terraform.

When Bleacher chose to adopt Elixir, their system as a single application was eight years old. Their monolith was designed as a desktop-first experience, and now the majority of the company’s traffic comes from mobile devices. Their business grew as they added the capability to follow individual teams and players. With the advent of the smartphone, notifications alerted users to breaking news and events, driving their traffic higher.

The problems that haunted their system were scaling and serving personalized content on demand. You’ve read about their attempts to cache or add servers. After that, it was clear they had to introduce a new technology, as they had reached the limits of their existing stack. They had to break up the monolith.

Around this time they forged their agreement with key stakeholders. The potential risk was enormous. The team decided to build their core content streams in a language that had only recently reached 1.0 (in 2014) and use Phoenix, a framework that was about a year away from 1.0. That was the core of their business.

The team drew the boundaries around this first Elixir service. The service would fetch a user’s subscriptions and built content streams for each subscription. As they built the service, they also had to change the legacy application to request the service using an HTTP client. Eventually the service would serve as the single source of truth for the rest of Bleacher Report. Today, mobile applications and the front end access the service directly without passing through the legacy application.

Once the team came up with the app boundaries, the next problem was deciding who should work on it. They wanted to balance two concerns. They identified leaders who were the primary Elixir advocates. They also needed to mix in enough business experience to solve the problem, so they identified the developers who wrote or supported the legacy code. That combination gave them both domain knowledge and enough Elixir chops to solve the critical problem.

It was high-risk, high-precision surgery with a small and confident team. The sports giant decided to replace a core part of their system but one very limited in scope. Doing too much or getting too many people involved would have increased risk even further, and that’s the last thing they wanted.

Once a prototype was ready, they didn’t deploy it to production right away. Instead, they ranked content streams roughly by ascending popularity to proxy to the new Elixir service.

They used less popular streams to test how the service performed. If a stream were to fail, they’d prefer to draw the ire from Olympic equestrian fans in a non-Olympic year than World Cup soccer fans at the peak of the tournament. They built a simple app to direct requests based on a static file, routing streams to either the Elixir servers or the existing legacy ones. As Bleacher Report has roughly 70,000 content streams, this approach was quite cumbersome. It did work though and it allowed both the development team and business side stakeholders to develop confidence until they completely removed the stop-gap.

That was the basic rubric that the team used to port its first critical legacy component to Elixir. To summarize:

• They isolated the part of the legacy system that was failing the most.
• They built a team just large enough to solve the problem.
• They included both Elixir skill and legacy domain experience.
• They tested their prototype in production gradually until they had enough confidence to fully depend on it.

With their first victory in hands, the technical team was ready to push forward and migrate other critical components to Elixir. They chose the strangler vine^[30] technique to move forward. The strangler vine means you build new pieces of a large application over months or even years using a new technology until the old system just dies and is subsumed. It was deliberate and incremental. Steady, iterative progress will win over time.

Three years after they started, they’re still porting the last few bits of the legacy system, partially because the urgency isn’t as great. Some of the stragglers aren’t traffic-dependent services and others are internal tools around the edges of their system. Now their performance is better, their teams are more productive, their customers are happier, and their software is easier to extend.

In the next section, we will add some technical depth by exploring the Terraform project and show how some of the techniques used by Bleacher Report translate to code.