From Legacy Application to Serverless With EventBridge
By: Marin Radjenovic
Tags: Event Driven Architecture, Sns, Serveless, AWS, Eventbridge

Most startup applications are built with the intention to use modern technologies with the intention to save time and money and make the application better than your competitors’.

However, once modern applications will at some point become a legacy burden. It will then be easy to assume that disposing of the old technology and building something new will solve all the issues. Yet, many times the old application still holds information that is crucial for business survival.

So, depending on the application’s condition and the team behind it, any intervention might be risky and expensive.

Also, it can very often happen that there is almost no documentation and most of the people that started it, already left the company and there is nobody to consult with.

Moreover, stakeholders might reject the idea to change the system that works, without some serious reasons.

Again, depending on the circumstances, you need to find the right strategy. You need to allow overall IT business to progress, so not to lose customers but to gain customers.

In our case, the idea was to just start switching off the lights in the old infrastructure, one by one, and moving pieces of old business logic into the modern cloud infrastructure.

A legacy monster which was hunting us…

I believe that in most software solutions (a couple of years old), there is a monster with serious technical depth. In the beginning, it was aimed to be just a simple CMS. However, as the business progressed, the app constantly grew and nobody really cared about documentation nor the technical depth that much.

Over the years, the CMS had so many integrations with 3rd party applications so nobody could clearly explain how the integrations work anymore. Even worse, some of the integrations that weren’t useful anymore, remained in production as nobody was sure if they will break something else by removing it.

In parallel, the business thrived and required modernization of the existing solution. Therefore, there was a set of independent projects based on a serverless architecture that consisted of microservices and micro frontends.

However, modern applications were not aware of some crucial user states. For example, they didn’t know if a user was a paying user and which subscription package did they bought.

Last but not least, no one at the company wanted to change the legacy application. The team that worked on it was not comfortable with making changes in that area; they only supported it. Similarly, the management team was uncomfortable with the idea of change, as they had already had issues with previous attempts to change the app

Plan to attack the legacy monster

Dealing with such a legacy application was not an easy task. Moving all of the business logic & integrations into the serverless architecture would be too risky.

The management identified that Subscription is a very important aspect that serverless applications are not aware of.

Previously, subscriptions worked over a third-party system that was responsible for payments and subscription management. The legacy application was in turn connected to the thirds party subscription service via webhooks (so webhooks informed the legacy CMS about new subscriptions, cancellations, etc…).

Now, the idea was to connect modern applications with subscription 3rd party service that was hooked to a legacy (CMS) application by webhook.

The easiest solution would be to add one more URL to the webhook that would point to the API Gateway…

Unfortunately, that wasn’t an option. The Subscription service offered a configuration web console for configuring webhooks. However, just 2 webhook fields were available and unfortunately, both places were occupied.

Even if the solution above worked, it wouldn’t be flexible much. A better approach would be, to fan out events coming from webhooks and spread to the applications of interest.

Another approach could be via PUB/SUB architecture using SNS and subscription filter policies. However, filter policies can be very hard to test.