3 ms·
I think you are repeating a strawman argument against microservices that doesn't always hold. Microservices are about domains of logic and form nice clear boun
by lbriner 5y ago
I think you are repeating a strawman argument against microservices that doesn't always hold.
Microservices are about domains of logic and form nice clear boundaries. They don't necessarily need inter-service comms or much by way of environment setup/maintenance. We have an email microservice that was split up that way because the email logic was spread out everywhere and called from multiple apps. A microservice was a good way to encapsulate all of the email logic into a single place with a clean interface. We can make all sorts of centralised changes without affecting any of the apps. We can also scale it out as the amount of email we need to send increases.
- kortilla 5y agoEmail just sounds like a regular service. Separate SMTP servers where you encapsulate all of your logic of email dispatch frequency, retries, etc has been pretty standard for a long time. > encapsulate all of the email logic into a single place with a clean interface You can encapsulate and put stuff behind an interface with libraries too. This is not the value proposition of microservices.
- Chris2048 5y agoParent said: don't build microservices to start off with and you describe: because the email logic was spread out everywhere and called from multiple apps so it doesn't sound like a counterpoint to me - you didn't start off with the email service, and only split it off after it was already established across multiple entities. Plus, you added a bunch of justifications for this, i.e you could "bring a strong argument in favor of it" - so where is the strawman in your examples?