123 ms·
The orchestration overhead must be huge, but it sounds like they have focused on automating the pain of that away as much as possible. To me it looks like an A
by Fr0styMatt88 7y ago
The orchestration overhead must be huge, but it sounds like they have focused on automating the pain of that away as much as possible.
To me it looks like an Alan Kay style of OOP design. From that standpoint, replace 'microservice' with 'class' (or 'actor') and 1600 of them isn't that ridiculous.
It'd be an interesting system to browse. I'm actually curious if they've built any tooling around making the codebase easier to navigate and edit. Smalltalk handles a huge amount of tiny classes by having good browsing tools. What would you use for a Go codebase of this size?
- x3al 7y agoYou can replace 'microservice' with 'class, but completely asynchronous and any interaction with it can fail without caller knowing if it succeed or failed at all'.
- imtringued 7y agoYes, that type of class is known as "actor".
- cfontes 7y agoAs someone with a little experience troubleshooting actor based systems, having 1600 of them sounds (actors not instances) like a nightmare.
- vbezhenar 7y agoSome people love erlang.
- blackoil 7y agoI have some experience with Akka. The amount of praying you have to do during production issues, no surprise it feels like a religion. We tried it about 4 years back. Maybe there are some better debugging tools now, but for us both learning curve and prod issue pain did not make it worth it.