4 ms·
> Memory leaks on the server side are also a consequence of long-running single-process server software. On a tangent to this. I noticed that one benefit my co
by algesten 10y ago
> Memory leaks on the server side are also a consequence of long-running single-process server software.
On a tangent to this. I noticed that one benefit my company reaped from embracing a micro service architecture was that we get away with _a lot_ of shit code.
Suddenly a NodeJS process can have glaring memory leaks and work fine for weeks because whenever it crashes, it restarts in 0.5 second and no one even bothered to investigate.
Compare that with the good-ol-JBoss monolith with a 3-4 minute startup time.
On the one hand, crap code can go unnoticed for weeks, which feels wrong and probably will bite us somewhere in the end, on the other hand, we can focus on function not code quality.
- koolba 10y agoPlus if you build for this from the get go and assign a max life to your processes with auto restart, it becomes a native part of of their lifecycle. With multiple processes listening to the same socket it's easy to create a continuously on service that under the covers respawns with no apparent loss of service.
- roguecoder 10y agoThis is the Google approach to scaling to thousands of developers: build rock-solid infrastructure so none of the code can go too badly, and you can worry a lot less about the quality of most of the code. For most functionality, writing amazing code would just be wasted effort when a less-amazing developer could have implemented something good enough.