Re:The Death of Microservice Madness in 2018
by bonesss on Monday January 22, 2018 @06:57AM
(#16203717)
I think that kind of process, slow decomposition based on performance and requirements, is the only sane approach.
It's also reflected in how we manage code at the micro-level: collecting related logic into a module until it becomes unwieldy and then separating out independent sub-functionality into their own modules and dependencies as they grow...
There is no right size for a class. Smaller is better, but the ideal is "right sizing". What's right? Well, that's tricky, but whatever doesn't hurt is pretty ok.
There's no right size for a service. Smaller is better, but...
Re:The Death of Microservice Madness in 2018
by chillidoor on Monday January 22, 2018 @08:31AM
(#16204164)
Yep, there is no real "one size fits all" to microservices
I found that a lot of the time developers start moving towards microservices when they find that a monolithic app becomes too difficult to work on. For example, multiple teams working on the same codebase will often have accidental code conflicts. Plus, scaling a monolithic app because one part of it is under load isn't always cost effective or logical. So, teams will start to break off components into microservices to make development easier and less painful. Naturally this has to be weighed up as microservices bring a different set of challenges, 'gotchas', etc, etc but in my experience the teams have done a proper job discussing the pros and cons.