1

We have a monolith C++ application and I consider doing some major refactorings. Since we're not completely ready to go full "microservices only" (maybe in about two years time), I want to structure the new architecture in a way so that the application can be run as both, a monolith with every microservice compiled to one app, or each app split into it's own executable to be scattered across the infrastructure.

What is an idiomatic way to do this considering project structure / cmake targets usw.?

Atm we seperate our concerns into three blocks: API, processing and storage. It would be nice if I could somehow deploy only processing and storage on one node or on a seperatore node. Similarly API and processing should be able to be compiled together and also benefit from a speed increase.

I thought about compiling using some cmake options which conditionally add server/client capabilities to single services. If the app is compiled together, it should allow direct transmission of memory between services for performance reasons. But my fear is that the app will grow to become a so called "distributed monolith", so I want to take every measure against that from the start. Any (anecdotal) experiences that I can learn from are highly appreciated.

Improve this question
3
  • 2
    A good first step would be to split the system into multiple libraries, introducing seams. For now you're linking them together directly, but later you could wrap the libraries with a server and deploy them separately. Take care to design your libraries' APIs for very low coupling. No callbacks, no pointers, no shared data, nothing dynamic. Just data transfer objects that can be easily serialized. Copying isn't free, but it's cheap compared to distributed system overhead. When designing APIs, think up front about whether you're going to wrap it with HTTP+JSON, Kafka+Avro, gRPC, …
    – amon
    Commented Jan 24 at 8:50
  • I'm not convinced that the separate modules you're addressing here should be independent microservices. Secondly, seriously consider if the effort of designing this hybrid system is not eclipsing the effort to just cut over to microservices directly, because I get the feeling that it very well might.
    – Flater
    Commented Jan 25 at 2:29
  • API, processing and storage sounds like horizontal layers to me. A microservice architecture will usually introduce vertical layers, where each service has its own API, its own storage and its own processing layer. Can you please clarify?
    – Doc Brown
    Commented Jan 25 at 15:36

1 Answer 1

Reset to default
1

This kind of flexibility comes at a cost. Cost to design, development, testing, and deployment. Be sure the flexibility gains outweigh these costs.

You may think this is taking baby steps towards your goal. And it can be. But likely not how you thought.

Rather than throw a sudden architectural change at the whole project break off one small piece. Make that piece into a library that can be used by both the monolith and the micro service.

Doing this will mostly show you the limits, costs, and inefficiencies of this approach. That will give you an idea how much work this will be.

While you’re supporting both ways of working the costs will be higher. You can expect them to fall when you pick one.

But being able to dip you toe in before committing can be invaluable.

Improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.