3 ms·
I've had good luck with more of a hybrid architecture: one central monolithic-ish service and numerous supporting microservices to perform specific (usually asy
by jcadam 7y ago
I've had good luck with more of a hybrid architecture: one central monolithic-ish service and numerous supporting microservices to perform specific (usually asynchronous) tasks. The microservices tend to be things that are easily separable from the core of the system and can be turned on or off without affecting core functionality (they also tend to be long-running and/or resource-intensive tasks). This is especially helpful in instances where we might not want to even deploy some capabilities depending on the environment.
I think you get some of the benefits of both approaches here: A single monolithic service that encapsulates the functionality needed for a minimal working system, and the ability to carve off and maintain clearly non-core functionality into separate programs to avoid bloating up the main service.
- flamtap 7y agoI agree with this. Microservices have their place. So do monolithic, centralized services. Using both in the same system is certainly not a sin, can can certainly be correct. I'm currently reading through Juval Lowy's latest book, Righting Software. Juval is widely credited as one of the pioneers of microservices [1], and he states in the book that even he doesn't appreciate the term. He illustrates his point by comparing the small, eight-inch water pump in his car versus the huge, eight-foot city water pump that moves water to his home. Both perform an unarguably essential service. But just because the pump in his car is orders of magnitude smaller, does not make it a "micropump". A service is a service no matter how big or small it is. Should you use microservices? As is the answer to any sufficiently interesting question: it depends. [1] https://en.wikipedia.org/wiki/Microservices#History https://en.wikipedia.org/wiki/Microservices#History