Jorge Manrubia

April 19, 2021

Complexity-inducing narratives

I recently gave a talk on software complexity, Single Page Applications and Hotwire (slides). Due to time constraints, I ended up cutting off a whole section on narratives that are often Trojan horses for unjustified complexity and decided to write it down instead. These narratives are:

  • It doesn’t scale
  • Tech giant uses it
  • In the real world

It doesn’t scale

You see this advice so often that it’s almost a cliché: Be wary of premature optimization; modern hardware can move crazy loads with very little. And yet, you see scalability as a recurring selling point for every next hot thing. Just from the very first google results searching these: serverless architectures are inherently scalable, NoSQL databases can accommodate unprecedented levels of scale, and it’s easier to scale using microservices.

HEY processes millions of inbound emails every day. It uses Postfix as its mail server. When ingesting emails, Postfix needs to check whether recipients exist or not, to form a proper SMTP response, and it does this by checking with the app. This request is pretty critical, well-isolated, and receive a high load of requests. Do we use a microservice for it? No. It’s a regular request to the HEY monolith running in a separated pool of servers. No additional service to operate, no contortions for reusing logic, no separated system to test and deploy. 

Similarly, HEY stores email contents and associated structures that, ignoring attachments, represent a multi-GB daily growth. Are we using some NoSQL database to ease horizontal sharding? Again: nope. We store those email contents in MySQL, which is a technology where Basecamp has years of operational experience at scale. 


Tech giant uses it


X : Why are you so bullish on serverless?
Me : AWS creates the future by industrialising the past, it concentrates on shifting product to utility. Amazon then migrates onto this once convinced … the first “huge” cloud transformation project was Amazon moving onto AWS …

… if you listened carefully at reInvent last year then you would have heard Jassy say that 50% of all new Amazon apps are built on serverless … that’s all the signal you need. AWS owns the underlying space, Amazon itself is building on top (including the practices) …

Amazon, Facebook, Google, and friends operate at a scale that makes them lonely outliers in any analysis you can make. Because their tech is the result of throwing endless resources to incredibly complex problems, it is rarely shaped by development costs. Blindly following their example without taking those into consideration is a recipe for disaster. 

Take the serverless example. Even if it’s true that Amazon, the major seller in the space, is all-in, should that affect how you architect your app? Assuming you want to build something moderately integrated (not a standalone serverless function), would it look like this?




Can you build, test, provision, operate and maintain such a system?

In the real world

I discussed an example of this narrative here. Referencing “the real world” when trying to make a point about some tech or pattern should put you on alert. This argument is not only condescending but, more often than not, fallacious. It’s often used to present an alternative as superior to others without providing any reason.

And real world for who? Even when you compare companies of similar sizes that operate in a similar space, you observe profound differences. Take the case of Basecamp and Discourse. Both run successful businesses that offer products that people love. Even when they both use Rails, their technological foundation, coding patterns and development methods are completely different. And, attending to results, it works wonderfully well for each! What’s the real world here?


I think the bottom line is that you should be skeptical of compelling narratives in this industry. When making a choice, if you don’t have access to someone with experience, your next best option is educating yourself in the "cons", and that’s pretty hard to do when most of what you can find is hype. I have been pretty bad at this in the past. If anything, I am keeping this little post as a gentle reminder for my future self.

jorgemanrubia.com

About Jorge Manrubia

A programmer who writes about software development and many other topics. I work at 37signals.

jorgemanrubia.com