Layout Service — The Backbone of Modanisa Website Replatforming

Legacy projects, can’t live with them, can’t live without them. They’re a misery to work with but they also create a lot of job openings, which is nice I guess.

We also have one of those…

The Problem That Needs to Be Solved

As it stands Modanisa website is a monolith built on good old LEMP stack (Linux-Nginx-MySQL-PHP). By itself being a monolith is not the main problem. We probably wouldn’t have made a move on replatforming, if not for other issues. It’s called legacy and it’s a combination of issues such as:

• No automated tests
• Slow for all users (both customers & employees)
• Too many bugs
• Poor or non-existent monitoring/logging
• Tech is outdated/unsupported
• There is no documentation

More relatable list:

• Developers don’t want to work on it
• Adding a feature creates bugs in seemingly unrelated areas
• When you get an error during some action you retry and it works
• Only certain people know which parts work how or worse, no one knows how those parts work because the relevant people left the company
• “if it works don’t touch it”

Some of these may be true for even non-legacy projects, but if you have most of these issues then I’m sorry but it’s probably a legacy.

In addition to these issues we also wanted to change our tech stack from LEMP to whatever the projects require. We started with Go, Vue and NoSQL but there is nothing preventing us from using other tech too as the need arises. And while we are at it we moved to microservice architecture. But this post is not going to be about monolith vs microservice so let’s leave it at that.

Options at Hand

1. Refactoring

Depending on the project it might be possible to solve issues caused by legacy without rewriting the whole project. Not for us though.

2. Complete Rewrite (Big Bang Replatforming)

Pros:

1. In total, takes less time and work compared to strangler fig pattern (we will talk about that below).

To be honest I can’t find any other pros. Let me know in the comments.

Cons:

1. Until replatforming finishes it doesn’t add any value to the business, which makes it difficult to convince the stakeholders to wait and be patient.
2. Because of feature freeze in the legacy codebase, it also stops adding any value even to the legacy business. And if you choose not to enforce feature freeze, then the rewritten project also needs them so you will have to implement the same feature twice at the same time.
3. If replatforming suddenly needs to be stopped — and that’s not a rare thing — , incomplete project goes to waste.
4. When creating the new project it’s very possible to accidentally skip some undocumented features in the legacy system.

Let’s continue with our next option.

3. Strangler Fig Pattern

This pattern is about gradually replacing your project piece by piece with replatformed tech until the legacy disappears.

Originally the name got popular as Strangler Pattern but apparently Fowler hopes the name will catch on as Strangler Fig rather than Strangler as he mentioned in his original post:

… The original post was entitled “Strangler Application”, and when used, the pattern is often referred to as a “strangler”. But its usage often gets separated from its metaphorical root, and takes on a unpleasantly violent connotation.

…

If I rename the post to “Strangler Fig Application”, and use the term “Strangler Fig” as much as possible, then hopefully that would reduce the violent connotation by reinforcing the metaphorical link that is the whole point of the name. …

With strangler fig pattern while it’s technically possible to not touch the legacy codebase, it’s not a viable option in reality. Because more often than not, that codebase doesn’t have a proper architecture to implement the strangler fig pattern properly. So you will have to add little pieces of codes here and there.

Pros:

1. Changes are reflected in the production website as you develop it, hence the business can reap the fruits of the renewed functionality without waiting for replatforming to finish.
2. And that makes it easier to convince the stakeholders.
3. Not much is wasted even if replatforming suddenly stops. Which reduces the risk.

Cons:

1. In total, takes more time and work compared to complete rewrite. Especially if you intend to use microservices and your team is not used to microservice architecture.

Let me know of other cons.

I tried not to list the pros/cons of microservice architecture because strangler fig pattern does not enforce microservice architecture — although they get associated most of the time.

Among these options strangler fig pattern is the best option for us — and to be honest for the most projects. So let’s talk about the details.

Strangler Fig Pattern Options

Choosing strangler fig pattern was just another step. Now we need to choose how to implement it.

1. Adding Conditional Calls to Legacy Codebase

This simply means calling the new microservices within legacy codebase if that part is replatformed and using the old legacy system if it’s not replatformed yet.

We didn’t want to tinker too much with the legacy system because it’s written in PHP and we’re trying to switch to Go. So for us it doesn’t make much sense to go with this option.

2. Micro Front-end

Micro front-ends are great, but you need to know the page layout for it to work. Unfortunately we — the replatforming team — don’t know the page layout, legacy does. While searching for options we’ve stumbled upon a project called Tailor. It felt close to what we needed but as far as we could tell Tailor was also designed for page layouts known by the new system rather than the legacy system. Apparently to work with the legacy you need to implement custom solutions and also to get cookies & headers you need to customize it even more. At that point it made more sense to create our own solution.

Which brings us to the next and main item.

3. Custom Layout Service

This service sends a request to the legacy website (from now on will be referred to as upstream), replaces necessary front-end parts and serves the updated website to the user. Let’s break it down.

Sending request to the upstream means we need to wait for the upstream AND the replatformed website. Which is worse than the original response time. To solve this we need to tell the upstream that x, y, z parts are replatformed so you don’t need to generate them for this request.

Replacing necessary front-end parts means we need to know which parts to replace, and replace them with what. This also comes in 2 parts:

1. Which parts to replace gets deduced from the intersection of our configuration and the user’s parameters. E.g. 50% of users using the website in Sweden with English language should see the replatformed slider on the homepage.
2. Getting correct replacements from our new services.

As you can see generating the correct replacements is not Layout Service’s job. If it was, that would mean we are replatforming monolith with another monolith. Instead we delegate that work to our microservices. Which means we are replatforming monolith with microservices.

Conclusion

We still have long way to go until replatforming is finished. No matter which option you choose, replatforming takes long time — relative to the legacy project’s size.

When our replatforming is finished we will become independent of legacy codebase and we will be able to drop it completely. At that point we can probably drop the Layout Service too since services specifically designed for micro front-ends should be enough and simpler.

If you have a migration project in your hands similar to what we had to go through you will also need to research and choose the best suited option for you.

Good luck to you all.

Acknowledgements

Special thanks to Tuncay Kılıçoğlu for sharing his knowledge about the beginning of the Layout Service.