Not all “Microservices frameworks” are made the same
summary
Argues that all-in-one microservice frameworks create accidental complexity and lock teams into bad abstractions, while runtimes and platforms let business logic stay simple. Recommends using Dapr building blocks (service invocation, state, pub/sub, actors with pluggable components) so components swap by configuration, and hosting on Knative serving and eventing to handle networking and scaling. Claims frameworks slow teams, force shared code, increase startup times, and make recovering from wrong assumptions much harder.
AI-written summary · about
chapters (8)
- 0:00Introduction
- 1:28Frameworks
- 2:25Frameworks vs Libraries
- 3:33The two main causes of frameworks
- 5:00Why frameworks are bad
- 9:00Framework vs runtime
- 11:55Runtime overview
- 14:55Conclusions
related talks
38mMicroservices, a bittersweet symphony
55mMicroservices, Where Did It All Go Wrong
01h 02mDesigning Microservices
20m3 reasons why micro-services aren't the miracle cure
42mMicroservices are Not Worth the Trouble!!??
37mKnee Deep in Microservices
01h 00mMicroservices, Where Did It All Go Wrong?
52mI Have a Microservices Architecture and I Didn't Know.