Hello Rubyists,
Sometimes I feel like there's a perception in the Ruby community that in order to have a fast Ruby and/or Rails site, you have to follow all the latest trends. Serverless, microservices, service objects, React - even slightly more benign choices like GraphQL or Serializers. Of course, there are reasons for choosing all of these approaches that aren't performance related - and I'm not really qualified to comment on them, so I won't here. Instead, I'm mostly just talking about this vague sense that because an approach is "modern" or "lightweight" or "scoring highly on Hacker News" it's just *better* and therefore *faster*.
By the way, before I get too off into left field on this rant - I am reducing the number of tickets required to get a group rate for my workshop tickets from 5 to 4. Interested in bringing a group to one of my workshops coming up in NYC, Denver, Dallas, Austin, Atlanta, or Chicago? Reply directly to this email and I'll get you set up. Space is running out at a few of these workshops and NYC's are just three weeks away! For more info, check out https://speedshop.co/workshops.html.
Anyway, *microservices*. This is one that comes up probably the most. I think the connection to performance in people's minds is that microservices means smaller chunks that are easier to reason about, and, as I have said and agree with - you can't optimize what you can't understand and simple code is therefore fast code.
The problem is that attempting the split into services doesn't always reduce code complexity. Many would argue that it's orthogonal - and I think I would agree. Ruby gives you a lot of tools for increasing modularity that don't involve adding HTTP calls and network latency.
Speaking of HTTP calls and network latency, let's talk about that.
This excellent article about benchmarking microservices (https://blog.acolyer.org/2019/05/13/an-open-source-benchmark-suite-for-microservices-and-their-hardware-software-implications-for-cloud-edge-systems/) came to me from Colin Jones on Twitter (@trptcolin). It's actually an open source benchmark suite that was tested at a handful of Extremely Web Scale companies whose architectures involve 3+ dozen services each. The benchmark shows that microservices actually require much more careful attention to performance both in performance targets and predictablity at each service (e.g. this service must return in 10ms +/- 1ms) but also in the network layer (if your microservice architecture makes 30+ network calls, your network config sudden matters quite a bit). Even more important is that horizontal scaling is now happening at *each service* rather than at just the monolith, and latency spikes cascade across the infrastructure in ways that automated load balancers cannot deal with. The authors of original paper and benchmark also found that microservices take longer to recover from latency spikes than monoliths, even with automated load balancing.
What would I have you do instead? What do I tell my clients?
I think you should do whatever the simplest and most understandable approach for your team is. For most teams, I think that's the Golden Path - Rails defaults all the way down. It's important to remember that *the largest Rails websites in the world*- Github, Basecamp, Cookpad, Shopify - all more or less follow The Defaults. None of them are SPAs. Three out of the four use stock Turbolinks. Github uses a Turbolinks-like approach that eschews JSON and instead sends server-side-rendered HTML over XHR. Next time you browse in Github's File Explorer or click between the issues and pull requests tab, open up the Network tab in Google Chrome and see how little JSON and how much HTML is being passed back and forth.
I get it - standard is old and boring. But it scales. And it can be as quick as any other approach, and sometimes even faster because it's easier to understand.
Anyway, that's my complexity rant of the week. Hope to see you at a workshop this summer if you live in the US of A.
-Nate
-Nate
==============================================
You're receiving this email because you opted-in at nateberkopec.com or speedshop.co
Unsubscribe <<Email Address>> from this list:
https://speedshop.us11.list-manage.com/unsubscribe?u=1aa0f43522f6d9ef96d1c5d6f&id=840412962b&t=b&e=[UNIQID]&c=4893ea6b11
Our mailing address is:
Nate Berkopec
PO Box 541
El Prado, New Mexico 87529
USA
Our telephone:
Forward this email to a friend:
https://us11.forward-to-friend.com/forward?u=1aa0f43522f6d9ef96d1c5d6f&id=4893ea6b11&e=[UNIQID]
Update your profile:
https://speedshop.us11.list-manage.com/profile?u=1aa0f43522f6d9ef96d1c5d6f&id=840412962b&e=[UNIQID]&c=4893ea6b11