Re:Avoiding the Distributed Monolith
by SmirkingRevenge on Tuesday April 10, 2018 @10:24PM
(#16807550)
Great observations.
In my experience, microservices get perilous when you have a few junior level devs seduced by the mistaken idea that they only need to think hard about a single component of a complex system, and the rest can just sort of take care of itself later.
Re:Avoiding the Distributed Monolith
by Traubenfuchs on Wednesday April 11, 2018 @11:11AM
(#16811890)
Googling "TFA microservice monolith list" leads to your post. Where are the lists? (-;
The key that was not mentioned was the interfaces. In my experience, the key is to carefully define the functions and scope of each separate component, then do a lot of up-front work building a clean interface for sending data and/or messages between the components.
Once this is done, the team on Componnt A should be able to make, rollout, and/or move to different hardware, and/or add/subtract hardware at will without the team on component B even noticing. All teams should be able to keep their paws 100% out of each others' code and data structures.
Then, you have independent components that can actually be immediately scaled to meet unexpected load changes by throwing HW at them, thus buying time to streamline the code. You also have a structure that you can upgrade and maintain with much greater freedom.
Without the clean and stable interfaces, he's right, you have only a distributed monolith.
I'd recommend starting the first version with a quick-to-build near-monolith throw-away, get some experience with the actual data flow, then decide on the actual components and interfaces.