4 ms·
One thing a microservice architecture does really well is enforce bounded contexts. Oh you want to access that data? Well you need to go through the public API
by LennyWhiteJr 7y ago
One thing a microservice architecture does really well is enforce bounded contexts. Oh you want to access that data? Well you need to go through the public API because it exists in a separate process. In a monolith it's all too easy to just 'call this piece of code and grab what I need' (no one will ever know). Project isolation can help but it's not a silver bullet.
The author makes good points though, there are many places doing microservices because it's the hip thing to do and a monolith would easily suffice. But if you have independent software teams in your org that should be able to deploy code independently, then microservices makes a lot of sense.
As in all things engineering - it depends :)
- vbrandl 7y agoThe actor model also gives you a good amount of isolation between your contexts (no public API, just async message passing). It gives you the advantage of running everything on a single node as long as it's feasible without having to go through some `data -> JSON -> HTTP -> JSON -> data` route and still when you need to scale out, it is easily and transparently done.
- cc81 7y agoThat is true and when you are at big enough scale it probably works. But when you have chosen a cool new microservice architecture for your team to implement and you grab that small user story that spans 3-4 different services things suddenly went from. "Hey, easy implementation and refactor and the compiler will tell me if I fucked up" to something much more time consuming and error prone. In an ideal world that would not happen of course. Just like it in an ideal world a monolith is built correctly as well.