When to Microservice
I’m enjoying Microsoft Build 2022. Developer experience (especially in the face of common and complicated IaaS and PaaS scenarios) was my favorite topic of the day 1 keynotes.
Later, watching the keynote after hours, I stumbled on a gem of a conversation between Scott Hanselman and Scott Guthrie.
Great informal discussion/perspective on when to use micro-services & containers from @shanselman and @scottgu at 33:18.https://t.co/1tNahY1VSk
— Clint Parker (@clintcparker) May 25, 2022
Lot’s of classic “it depends” which is totally true. For me it depends on at least one of three macro factors being present:
- Teams/people need to develop and deploy at different paces.
- Parts of the system need to scale independently
- Parts of the system need to be segmented for security purposes. Ex: only engineers from the payments team can make changes to payments systems.
You can have any decomposition you like, but in that video Scott Guthrie alludes to the challenges you can face on either end of the spectrum (1 engineer with 100 micro-services or 100 engineers with one service).
One last note, I may start saying containers instead of micro-services going forward. I usually try say that I prefer macro-services, but then we have to have a whole discussion about the difference. Maybe the term container will become the defacto descriptor of services and their boundaries.