on Feb 6, 2022

Prefab Vision

The Vision

Don’t Rebuild The Wheel

Once Upon a Time at HubSpot

So once upon a time I worked at HubSpot. And it was good. There were lots of good bits, but in particular the way we shipped software was just… friggin great. The goal was to make a squad of 4 people able to ship features at the speed of light. The central insight was that this would only work if our teams were able to focus entirely on the business problem and not on plumbing or bullshit.

Amazingly, it worked. I was on a team of 4-5 folks and we were able to ship something that hit like 80% of the features of HootSuite and their 100-engineer team. This wasn’t isolated either. In every direction 5 person HubSpot squads were shipping things that would take 25+ engineers at another org.

HubSpot achieved this because there was a strong “way to do things” and even if it wasn’t perfect, it hit the nail on the head making me productive. Configuration was standardized and realtime and the live nature of it meant I could use that in unimaginably powerful ways. Changing log levels at a method level on the fly was mind blowing. If I needed the current user it was magically available in my code. Authorization was a trivially simple annotation away. Feature flags were easy to use and omnipresent. Little things like infinitely flexible rate limits were at my fingertips. I spent no time recreating the wheel arguing about JWTs or what the staging data refresh procedure would be. Local development was lean and mean and my devs didn’t spend 5% of their time waiting for Docker because we leaned into hybrid development and pointed things at staging. But my devs also didn’t spend 5% of their time trying to bend local dev to their will to point a react page at a remote service because the batteries were included everywhere. My service.yml explained everything I needed to make my app deploy and I got so many metrics and alerts out of the box I could ship with confidence.

Eventually I moved on from HubSpot and back to the real world. I missed all of it immediately.

The Real World Season 34: ezCater

The real world was a fractured space. Happily ezCater was a simple RubyOnRails stack, so it had avoided some of the worst patterns, but we were not setup for long term scaling success & team growth. In some places there were excellent tools like DataDog that I could leverage to replace large swaths of my HubSpot tools. But overall it was a landscape of 50 semi-alive open source projects, or point solutions & expensive enterprise sales conversations with the likes of AuthO, LaunchDarkly, EnvKey & Doppler.

Some point solutions were fine, but many were overkill. I could rebuild the feature flag service wheel and get an 80% good solution in less time than it took to work through the pricing ramifications with an enterprise sales rep.

Missing from all of these was the most important bit. What was the happy path here? How was I supposed to do local development, staging & prod, at scale in a microservice environment? The HubSpot solution worked so well because it was an integrated experience. It solved for front-end devs that didn’t want to run anything locally and it solved for back-end eng that needed to run HBase locally. Access control was a simple @UserAuth annotation away not a headscratching question of competing approaches. Over and over we had to recreate the wheel, losing time and slowing us down.

The good news was that, stripped to its bare essentials and with kubernetes as an ally, it was possible to have nice things without an absolute ton of effort. We built a fine little service.yaml and deployer. But each piece was code I didn’t want to have core competency in, so each effort was trying to get 80% of the benefit with 20% of the work and nothing could be truly polished.

It’s been six years since then and the ecosystem really hasn’t gotten much better. Each little tool improves, tilt beats docker-compose, datadog is excellent and expansive, launchdarkly and envkey are quality tools. But they don’t tell a cohesive whole.

So what do I think should exist?

I want there to be an ecosystem of all of these tools that plays together perfectly. I want a defined happy path that I would be a fool to stray from. I want it opinionated. I don’t want to have to talk to any salespeople about it. I want the bits that could be open source to be open source. I want the SaaS services that grease the wheels to be so darn cost transparent that I’m comfortable putting it on my personal card to start. I want all of it to be so rock solid that it’s more reliable than I could feasibly do on my own.

In the world of software there is RubyOnRails and then there is everything else. There is a reason that it’s the longest tenured framework I know of. Rails is what happens when a framework is opinionated and laser focussed on making developers productive, wherever that takes it. It has opinions on everthing from templating language to database migrations, javascript compression to secret storage. Every piece comes with batteries included.

What I want is a RubyOnRails for developing with microservices. Strong opinions on how my deployments work, unified and amazing live configuration, out of the box authentication, and a constellation of those little microservice backed libraries like FeatureFlags, RateLimits, Experimentation, EventTracking that I don’t need to write myself.

I want it to be dead simple to get going, but not some restrictive walled garden. It needs to be obscenely cost-effective & fair at all scales so it’s not a trap. When I type “rails new” I get a robust amazing framework that is perfect for a monolith. When I add this library I should be launched firmly into a happy path to a batteries included microservice world.

So that’s what I want. I’ll leave it there for now, but I’d love to hear any thoughts you may have on my thoughts.