As I read the first five items on that list, each one made me think more and more "then isn't the answer to not write distributed systems?". But then the last item gives almost the opposite advice: "Extract services".<p>If you don't need (micro)services, don't build them -- they only introduce complexity in communication between components, build tooling, diagnosing issues, and they slow things down. It's amazing what you can do on a single machine, or, beyond that scale, a simple two-tier architecture with a few web nodes and a big SQL database. Systems like that are much cheaper, more predictable, and easier to understand. Of course, if you're Google or Facebook scale, distributed systems are (a) necessary (evil).<p>Additionally, I'm not sure his last point "extract services" is a good rule of thumb. If something can be a library, it'll be much simpler as a library. Don't make an "email service" when you can just import an SMTP library, wrap it in a couple dozen lines of code, and be done with it.
See also:<p>2016 <a href="https://news.ycombinator.com/item?id=12245909" rel="nofollow">https://news.ycombinator.com/item?id=12245909</a><p>Discussed at the time: <a href="https://news.ycombinator.com/item?id=5055371" rel="nofollow">https://news.ycombinator.com/item?id=5055371</a>
"Using a mean assumes that the metric under evaluation follows a bell curve but, in practice, this describes very few metrics an engineer cares about. “Average latency” is a commonly reported metric, but I’ve never once seen a distributed system whose latency followed a bell curve. If the metric doesn’t follow a bell curve, the average is meaningless and leads to incorrect decisions and understanding. "<p>I was never great at stat's. Can somebody explain why this is?