On Boring Stacks
A good friend sent me Jason Kester’s article Happiness is a Boring Stack a few weeks ago. The friend knows me well and knew the words of the piece would resonate strongly. The piece is worth a read. Its essential point is that while Hacker News, Medium, or certain of your colleagues may give you the impression that you have woefully mis-stepped if you aren’t building your application atop the latest and greatest JavaScript framework and containerization solution, from a perspective of pragmatism and quality of life this is often not at all the case:
For my own stuff, there’s no way I’d use any of that crap. Good old C#, SQL Server and a proper boring stack and tool set that I know won’t just up and fall over on a Saturday morning and leave me debugging NPM dependencies all weekend instead of bouldering in the forest with the kids. This stuff is my proper income stream, and the most important thing is that it works. If that means I have to write a “for” loop and declare variables and risk 19 year old kids snooting down at my code, so be it.
I can’t tell you how nice it is to have software in production on a boring stack. It gives you freedom to do other things.
I can (and often do) go entire months without touching the codebase of my main rent-paying products. It means I can, among other things, pick up a full-time development gig to sock away some extra runway, take off and go backpacking around the world, or better still, build yet another rent-paying product without having to spend a significant amount of time keeping the old stuff alive.
A boring stack frees up mindspace, elevating you further up Maslow’s Hierarchy of Needs and putting you in a better position to take in and execute on actual business requests and requirements.
To speak less abstractly, here’s a boring stack that I’ve personally scaled to 25k daily users on a single host:
- Ruby on Rails atop Phusion Passenger
- PostgreSQL
- Redis for caching
- Que job queue, in-process
- Cron/Whenever for any recurring tasks
Stacks like this are beautifully robust. If a storm in your data center’s region causes a power cut and a reboot, Upstart will just dutifully re-initialize all of these services when the host is back up.
Boring stacks like this are also surprisingly scalable. I have horizontally scaled out the above stack before in a very natural way on Amazon Web Services: the application server and job queue tier to EC2, Redis to ElastiCache, and Postgres to RDS.
Stacks like this are quite unpopular in the startup world at the present moment. I think there are a lot of reasons and different companies and teams have different ones. Specialization is a reason that I have seen firsthand. When a team is large and contains a sufficient number of specialists, these specialists are often drawn to the idea of building standalone kingdoms and shutting out consideration of concerns that fall outside of core competencies. These concerns don’t go away though, and a substantial communication and integration overhead is introduced by electing to follow this path. That cost should really be weighed against the benefits.
Another is exuberance around new distributed infrastructure solutions. People are learning hot new containerization and orchestration tools and pursuing distributed solutions by default. At a certain very large scale (either organizational or user base) this makes sense, but one should weigh the decision and its costs against the less painful, less delicate scalability and freer mindspace that can be achieved with a more stripped down and unexciting architecture atop better hardware.
I think that is what the discussion comes down to and why it is one that resonates with me. I experience the most gratification when I am working on products and features, not tooling and infrastructure ancillary to the product. A boring stack frees up my mind to better do that.
No Comments