I am curious of what tasks are involved in the transition of a monolith site into microservices. What do you have to do to make it work, i.e. redirecting. To put this into practise what tasks are involved in the transition of an e-commerce website?
In short, I understand what the transition does but not what has to be done to make the transition.
There are many information missing here - e.g. what's the current architecture and technology stack of your website. Considering this is very broad question, I’d suggest these guidelines:
Don’t refactor everything all at once — it’s impossible to do it right.
Treat The Monolith as a black box with some APIs. They don’t necessarily have to be RESTful APIs — think of ways to interact with it.
When adding new features, create separate (micro)services with an API for each of them and have them interact with The Monolith’s APIs.
After some time you will see that the pieces of your Monolith are being accessed only through your new APIs, even though they are still a part of the monolith code base. Move out capabilities vertically, decouple the core capability with its data and redirect all front-end applications to the new APIs.
Once you see bounded contexts bubble up, it might be convenient to chop them of the Monolith and have them working as separate services.
With microservices, you will need much more automation than before. Think in advance about Continuous Integration and Continuous Deployment (CI/CD), containers & repository, central logging, and monitoring.
I will recommend to get some concise generalized idea before jumping into your specific problem. This can be a good start.
divide site into small bucket Module list. then as per the microservice patterns develop the Module one by one / part by part.
It’s difficult to tell the complexity of the site from the link you posted. I’ll assume you are doing your own inventory and order management instead of pushing those tasks to a service provider. I’ll also assume you cannot stop feature development during the migration process.
The most important thing for any legacy migration project is to first get Inversion of Control installed in the legacy code. This will provide way to separate out the separate concerns that are probably tightly coupled now. Without IoC, you’re going to have a tough time. Note that constructor injection is a non-starter when migrating a legacy app. Instead you’ll have to use the Service Locator pattern and keep constructor or property injection in mind for the future.
Once you have an IoC container in place, you can start looking for seams to break out services. You will probably find code that naturally lends itself to internal services, so refactor them to be resolved by the Service Locator. The system logger is a good place to start.
The goal of the first few months is to move to a Service Oriented Architecture where much of the business logic is contained either in the Domain entities or in services. Don’t stress about getting the perfect architecture right from the start – it’s not possible. The migration process involves moving from a smelly architecture to architectures with progressively fewer smells, not from monolith directly to modular. Just get the business logic out of the UI and Controllers, and later you can tweak things for the domain layer or app layer.
Note that repositories are a big focus here also. As you migrate to services, you must also migrate all DB access to use the repository pattern. This will open the door to real unit testing.
As you migrate the code to use services, repositories, and IoC, you’ll start to see seams where you can break some features out into APIs. Create the first API with just a single small feature, and refactor your monolith to use it. Make it small because it will take a lot of infrastructure and process changes and you want to make as few simultaneous changes as possible. Once you have that first API separated out, continue migrating more and more features to that API.
BTW, this is a great time to move to a CQRS architecture and DDD strategy. That first API should be a full Bounded Context and implemented using CQRS.
Good luck!
BTW, I wrote a book on this very thing. It's .NET focused, but the process holds for any language. Search for "Bradley Irby" on Amazon.
