Read on Twitter
For the record, at Uber, we're moving many of our microservices to what @copyconstruct calls macroservices (wells-sized services).
Exactly b/c testing and maintaining thousands of microservices is not only hard - it can cause more trouble long-term than it solves the short-term. https://twitter.com/copyconstruct/status/1247130488667394049
Exactly b/c testing and maintaining thousands of microservices is not only hard - it can cause more trouble long-term than it solves the short-term. https://twitter.com/copyconstruct/status/1247130488667394049
- Microservices _do_ help teams move fast early on.
- By the time you realize fewer services would be great, it's too late. You need to solve the "hard" part of many services.
- We keep adding more services, but also retiring, and putting more thoughtfulness in new ones.
- By the time you realize fewer services would be great, it's too late. You need to solve the "hard" part of many services.
- We keep adding more services, but also retiring, and putting more thoughtfulness in new ones.
I'm probably overdue with a post on the hard-learned downsides of microservices. There's lots of talk of the blissful honeymoon period, but people rarely talk how they later get into nasty fights with microservices, then make up but change a few things. For good.
