23 ms·
I feel that. At my shop, we have given up on debugging altogether, because the tooling simply doesn't work. To run one service on our local machine would requi
by knallfrosch 3y ago
I feel that. At my shop, we have given up on debugging altogether, because the tooling simply doesn't work.
To run one service on our local machine would require us to adapt the other 9 to run against this one. And god forbid you build a "feature" for the "customer." Now you have to, of course, touch at least 2 services at the same time to move more data.
A breakpoint on one end is a timeout on the other.
So every developer is deploying release builds (no hot reload) on a local VM, inserting console.logs, System.PrintLines() and _loggers and then reading the disparate log files. Needless to say, I'm jumping ship.
- masklinn 3y agoSounds like the third paragraph could at least be somewhat improved on by switching everything to structured logging and being able to point them all to a local aggregator. Moving everything to distributed tracing would be even better, but there’s a larger investment as the tracing metadata then has to be unified across the board to properly track requests. Would likely help more with ops than with dev but should help nonetheless, even just getting proper spanning information can provide a lot of insight into a clusterfuck. > A breakpoint on one end is a timeout on the other. No dev mode to increase or disable timeouts?
- mrelectric 3y agoTelepresence!
- angio 3y agoWe use mirrord together with a staging environment to run specific services without the need to bring up the rest of the stack locally (we have ~5 services so it wouldn't even be an issue).