3 ms·
The easiest approach I've found to this whole debate: start with a monolith, making notes about where you think a server is most likely to have bottlenecks. Pu
by rglover 4y ago
The easiest approach I've found to this whole debate: start with a monolith, making notes about where you think a server is most likely to have bottlenecks.
Push the monolith to production, monitoring performance, and if and when performance spikes in an unpleasant way, "offload" the performance intensive work to a separate job server that's vertically scaled (or a series of vertically scaled job servers that reference a synced work queue).
It's simple, predictable, and insanely easy to maintain. Zero dependency on third party nightmare stacks, crazy configs, etc. Works well for 1 developer or several developers.
A quote I heard recently that I absolutely love (from a DIY construction guy, Jeff Thorman): "everybody wants to solve a $100 problem with a $1000 solution."
- hbrn 4y agoThis is something folks have been doing long before the microservices hype. That said, server bottlenecks are not the only thing (micro)services are trying to address.
- rglover 4y ago> This is something folks have been doing long before the microservices hype. Yes, and that's the point. > server bottlenecks are not the only thing (micro)services are trying to address. The only other real advantage is scale of network throughput and isolation from other processes (in case some service is particularly volatile or prone to errors). Even those are a stretch as they're both solved/solvable by modern infra and just isolating code into its own job server (technically a "microservice").