|
|
|
|
|
by mikeocool
404 days ago
|
|
I pretty much agree with everything in this article — it’s next to impossible service boundaries right in a startup environment. Though, if you’re on a small team and really want to use micro services two places I have found it to be somewhat advantageous: * wrapping particularly bad third party APIs or integrations — you’re already forced into having a network boundary, so adding a service at the boundary doesn’t increase complexity all that much. Basically this lets you isolate the big chunk of crappy code involved in integrating with the 3rd party, and giving it a nice API your monolith can interact with. * wrapping particularly hairy dependencies — if you’ve got a dependency with a complex build process that slows down deployments or dev setup — or the dependency relies on something that conflicts with another dependency — wrapping it in its own service and giving it a nice API can be a good way to simplify things for the monolith. |
|