3 ms·
That's fair. In the specific case I have in mind, load was very bursty and scaling was a major concern; we were always looking to minimize both latency impact o
by throwanem 6y ago
That's fair. In the specific case I have in mind, load was very bursty and scaling was a major concern; we were always looking to minimize both latency impact on revenue and infra cost impact on profit. Having the critical path live in its own heavily optimized services made demand scaling very easy and very fast; I don't think we could have done as well with less separation, and once you've already got the necessary infra and practices in place, it becomes very natural to apply them to the other problems you have to solve.
Not to say you can't get in trouble that way, for sure. It's its own kind of tradeoff, not least in that you need more ops support than a simpler infrastructure would require, and you need someone with the architectural vision and authority to ensure things don't get out of hand. It's definitely not where I'd want to start with anything, and you need a strong team to make it work, but I can say from experience that it can work amazingly well. Like, about twenty people supporting about $2B ARR well.
- emodendroket 6y agoThe truth is that even for very large companies there's always push and pull between service separation and ops burden. If you're thinking about it you're already in a better place than many.