CODEWITHSUNDEEP
restmicroservicessoa
Gaurav Sharma
Gaurav Sharma

Reputation: 586

Transformation from Legacy to Microservices architecture

I want to discuss a transformation from fat DB to microservices architecture.

A bit of history: So we have a legacy loan application system, which captures customer detail into a FAT database with some 1000+ tables. The application is doing a lot more than just just capturing loan with 100+ screens/processes built that are beyond loan capturing. Like administration, reporting, config etc.

Current State: The whole Presentation Layer, Logic Layer, DB Layer, ORM layer is part of the one project.

Current Task In Hand: The app is built in Win Forms, and my job is transform it to Modern UI as we need modern feature.

Approach: The approach I am taking is to built some Micro Services on current DB Structure. Using the same DB will allow the current application to run as it is, and we can write a new DB Layer, Logic Layer in some Micro Services. We can then write Modern User Interface (angular/react) that will consume those services. The second step then will be then stop the use of capturing operation from legacy app.

Third step is to move the specific DB tables out of the legacy databases to their own databases.

This approach seems best by keeping the current operation running as it is. Also, this approach allows us to run both applications parallel on the production environment.

Confusion: The question I have is on detailed design. I am struggling to understand the context split in Micro Services. The information in the scope of first iteration is: - Some Qualification Questions - Contact details - App requirements - Bank Details - Income details - Expense details - Previous loan information

The microservices I am thinking to have is - Application Service - Qual questions - App requirements - Previous Loan information - Income/Expense details - Demographics Information - Bank Details - Contact Details

Questions: - Does the approach sounds correct from legacy to microservices? - The microservice split. Can someone suggest if this is right?

Thanks a lot in advance. Regards Gaurav Sharma

Upvotes: 4

Views: 476

Answers (2)

jmhostalet
jmhostalet

Reputation: 4649

The great advantage of the micro-services is that you can adopt your migration project with an incremental orientation, so I would try to identify the individual functionalities that could be migrated and allow you to develop a quick-win, avoid a big-ban approach.

Perhaps the greatest challenge you face is to know the proper granularity of your first microservice. How big or small it must be.

A good point of reference is that a microservice should try to follow the principle of single responsibility, and in general all SOLID principles also apply.

If you DB is fat you'll probably have many foreing keys, and you have to plan carefully how to face the database per service pattern

This article may also be helpful 'How Small Should Microservices Be?'

Upvotes: 0

Robert Bräutigam
Robert Bräutigam

Reputation: 7744

You've said:

built some Micro Services on current DB Structure

I think that is fundamentally the wrong approach to take, I would urge you to think about alternatives. The problem with this approach is, it will lead to the same level of coupling and interdependencies you have now. You are just introducing an additional HTTP layer above an SQL one, and may be pushing logic then into the UI.

If you want to have long-term maintainability you will have to minimize interdependencies between the microservices. Basically microservices need to be able to do their job independently of other microservices.

Take a look at Self-Contained Systems.

Admittedly just mirroring an SQL interface (CRUD) through HTTP is easier to do, and there are frameworks that do that for you if you want, but it ultimately does not make the architecture better.

Upvotes: 2

Related Questions