There's trade-off's. They are using a fairly complex CI while with micro-services you release each service individually. It's hard to turn a monolith architecture into a architecture with micro-services. So it all depends on what works best for you. The idea with micro-services is that with a much smaller service - development is faster and cheaper, you can for example rewrite the entire service, use different software stacks (the best tool for the job), etc. Where as a total rewrite is not feasible in a monolith.
Why do you believe development would be faster and cheaper? Because the individual services are smaller?
Come on. The system is as large and as complex as will be necessary. Separating components with network calls doesn't make them any less interdependent.
There's a saying that if it takes one man one year to build a wall, you hire 20,000 workers and the wall would get built in a couple of seconds. That's the monolith thinking. Now if we make several small teams, and each team build a very tiny wall anywhere they like, each team could iterate faster, and quickly rebuild that tiny wall if needed, that's the thinking of micro-services. The later plan is of course not so smart if the wall is intended to stop people from entering, so not all systems are a perfect match for micro-services.
It's hard to turn a monolith architecture into a architecture with micro-services.
It’s only hard if your monolith wasn’t designed properly. In C# parlance...
1. From day one create your monolith with different domain specific projects where the functionality is exposed as an interface.
2. All consumers of each service use a dependency injection framework to map the interface to the service - not http service, in process domain service/module/namespace.
3. When you need to separate out a module to a separate service, it’s easy to split that specific module into a separate service by putting an http front end on it. If you integrate Swagger into your API, there are tools to automatically create proxy classes for your client.
4. Your proxy client can implement the same interface the interface
from step 1. Just change your DI appropriately.
5. If you have modules that are shared between the monolith and new microservice, create a package and a private package repo.
