During development a monolithic component (one project in one repo) is actually quite useful:
- Especially in the early stages, renaming classes and methods is easy.
- Also integration tests can be written, since all services are available inside the same monolith.
- But also during development there is no need to start other services. Just start the monolith and everything works end2end.
- Dependency management can be done in one place.
However, when deploying, micro-services are preferable. That's why my question is, whether there are any examples or best practices for automatically splitting a monolith into micro-services, but only for deployment.
A few ideas that come to mind:
- Deploying the same monolith image for several micro-services. So basically pod1, pod2 and pod3 have the same image, but each pod has its own service1, service2 and service3 (kubernetes resource "Service"). Via a configMap the monolith image for pod1 for example is configured to only serve requests for service1. Same respectively for pod2 and pod3
- For REST services and Ingress configuration could allow only service1 requests on pod1.
- Using the CI/CD pipeline to build several different docker images from the same monolith repo. Effectively removing those parts that are not necessary. E.g. image1 only contains service1-implementation, but service2-implementation and service3-implementation have been removed. Already during build process several different jars (for a Java application) could be build.
I'd like to know, if anyone has experience with such an approach or sees clear counter-arguments to work like this.
Thanks.
