Breaking a website into a bunch of micro services

Question

Imagine we have a website happy-cooking-together.com. (I made it up so if becomes available all of a sudden don't take it for real.) It's getting quite a lot traffic and multiple teams are working on it. The codebase has become huge and mostly unmaintainable so each of the teams struggles in its own way. Some lack modern front-end tech to empower amazing new user experiences while the others have issues with performance and outages. The business grows so stakeholders want to have a bunch of new pages, as well as some changes to the existing ones and all that at once, which leads to priorities collision. Nobody owns the whole codebase anymore and the release pipeline together with tests has become a huge bottleneck.

So the development team comes up with a solution: break the monolith into micro services. After brainstorming possible ways of doing that, they decide to split by different pages, so each of the new smaller services will render a chunk of existing URLs. They want to have a maintainable, scalable and manageable system that can adapt to business needs, enable them to launch different experiments, drive innovation in a safe and low risk manner.

Here's the grand scheme of things they want to try out and see if it works.

1. URL proxy decides where to route every request. For instance, /blog/cooking-potatoes will go to Blog while all the /recipes/* will be handled by Recipes micro service.
2. Each service becomes discoverable and sends to the URL Proxy and Sitemap Builder the list of URLs it serves. For instance, Homepage will only report serving / URL.
3. Sitemap Builder itself acts as a consumer of those events (or signals in an implementation agnostic terminology) and an emitter, rendering /sitemap.xml.
4. Every service is totally self contained, having its own database if needed, maybe caching layer, for instance, Sitemap Builder will cache the discovered URLs for 5 minutes to not overwork.

At surface, everything seems to be logical and promising. The team thinks they can start by implementing the URL Proxy component together with Sitemap Builder and make the rest of URLs served by an existing monolith. Then they proceed to extracting services one by one and see how things work.

There're some details as well they have thought about:

1. All the request headers should be proxied as is to the corresponding services to make sure User-Agent, Cookies, Referrer and anything else are not lost.
2. To maintain visual consistency for the entire website, they extract a library of UI components that they reuse so the menu is always the same as well as their nice logo.

Although it seems nice at the surface, I'm still uncertain about the following:

1. Does the described above make sense?
2. What are the flaws and downsides of this architecture?
3. What are the ways to make services discoverable by the others?
4. Is there something missing to make this work?

Answer 1

From my point of view, there's a pitfall here. At some point, it's going to appear overlapping functionality (an obvious example is auth layer) and teams start to compete for implementations because they have independent release cycles, stakeholders push their teams and so on.

Surely it's not a dead-end and necessarily has to be that way. Obviously, CTO and VPs have to have a broad view and handle it in advance, but in real life, I've seen a lot of competitive web services which are obviously appeared not because of a reason but the fact that people couldn't make an agreement.