0

I have a huge monolith application, a ASP.NET MVC Framework service offering ~50 different "groups" of unrelated data, separated into 50 different controllers/business logics. I was tasked into breaking this monolith into 50 microservices (each one hosted in Docker containers).

So far so good. What I'm planning to do is to create a "template application" using ASP.NET Core (an evolution of the ASP.NET Framework) to serve as a reference project and, for each of the 50 applications, I will fork this "template" project, add the corresponding controller with the necessary business logic and may need or not to customize this template to add some specific features.

For example, one application may need to respond to requests using a CSV format instead of the JSON, which is the standard for ~45 apps. So, I would modify the "template project" to include this "CSV response" feature and it would be used by the other ~4 projects that would use it.

What are the pros and cons of this approach using a "template" project?

What I can see currently:

PROS

  • Developing a ASP.NET Core application is easy, but it requires some configurations and customizations (CORS, Cache, routes, etc.) that would be already defined into "my company template" project.

CONS

  • Forking and merging the template project can be troublesome. If we find a security issue in the template, it would be necessary to manually update all of the 50 projects.

PS: I have already studied the pros and cons about migrating or not to Microservices. For this questions, I would prefer to focus on HOW to migrate to microservices and not WHY.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.