Availability • Strong module boundaries • Independent deployment • Independent scalability • Independent technology choice • Microservices are very small • No stable contracts • Tight coupling • Distributed tight coupling!! • Lackluster tooling support over multiple repos and nuget packages • Heterogeneity of services • Anticipating consequences is hard • Curious day-to-day development
Availability • Strong module boundaries • Independent deployment • Independent scalability • Independent technology choice • Microservices are very small • No stable contracts • Tight coupling • Distributed tight coupling!! • Lackluster tooling support over multiple repos and nuget packages • Heterogeneity of services • Anticipating consequences is hard • Curious day-to-day development
Availability • Strong module boundaries • Independent deployment • Independent scalability • Independent technology choice • Theoretically possible • But never used! • Different library versions in different services • => hard to debug / know, what is used where • => possibility of inconsistent data (in-memory state)
Availability • Strong module boundaries • Independent deployment • Independent scalability • Independent technology choice • Theoretically possible • But never used! • Different library versions in different services • => hard to debug / know, what is used where • => possibility of inconsistent data (in-memory state)
trade-offs and effect each other • Data persistence (event sourcing) & queries affect each other • Queries over all aggregates dynamic rehydration impossible • Always ask why • Horizontal Scaling • Fast responses during peak traffic cost-effectivity during low traffic
What id format should we use? distributed system database friendly Twitter Snowflake (52bit) 41 bit timestamp Machine id 10 bits 12 bits sequence No integers in JS-Land
What id format should we use? distributed system database friendly Twitter Snowflake (52bit) 41 bit timestamp 4 bits 6 bits Guid? What indices would suffer? Max 16 services? Max 64 Ids/ms 52-bit snowflake ids
the successful microservice stories have started with a monolith that got too big and was broken up. 2. Almost all the cases where I've heard of a system that was built as a microservice system from scratch, it has ended up in serious trouble. https://martinfowler.com/bliki/MonolithFirst.html
of its goals is that teams can develop and deploy their services independently of others. […] Spotify: >3000 Engineers A single team (~4 members) Quote from https://en.wikipedia.org/wiki/Microservices
organization • One team • One application • One deployment unit • One PR per feature • Main challenge: Hotfix & merging during transition Conclusion • Game changer • Easier day-to-day work • Productivity gains!
Advantages project references • Tooling support • Direct builds & testing • Reasoning over changes and consequences much easier • Main challenge: complicated pipeline triggers
bigger game changer • Immensely easier day-to-day live • Huge productivity gains! Together with the monorepo: Essential for moving foward with refactoring & features
why • Be curious! • Be mindful with complexity • There is no one size fits all! • Do not forget the people including developers • Improved dev live is a win-win situation
why • Be curious! • Be mindful with complexity • There is no one size fits all! • Do not forget the people including developers • Improved dev live is a win-win situation • Interesting and complex but also very successful project. Keep calm and refactor!
dotnetday
isaoshimizu
shift_evolve
rrreeeyyy
kitsuya0828
blueb
koichiotomo
sansantech
yoshidashingo
sugamasao
fujiwara3
akexorcist
oracle4engineer
sachag
shpigford
speakerdeck
chriscoyier
aleyda
tammyeverts
jponch
erikaheidi
honnibal
thoeni
marcelosomers
hatefulcrawdad
![Why Microservices? 05.09.2024 WE KNOW HOW. 68 • […] One](https://files.speakerdeck.com/presentations/64d45f8b081d435a849007abeb6ae271/slide_67.jpg){kind=link}
![Why Microservices? 05.09.2024 WE KNOW HOW. 69 • […] One](https://files.speakerdeck.com/presentations/64d45f8b081d435a849007abeb6ae271/slide_68.jpg){kind=link}
