Serverless Providers and Effective Architectures

10% of serverless is amazing. The other 90% is a dangerous dark hole of cloud-lockin, horrible testing, poor DX and complex setup. This is why you have some greybeards swearing off serverless and huge advocates (like myself) trying to push it anywhere it'll fit.

A couple notes for each of these parties. First, for the serverless advocates:

  • Serverless application architectures are not simpler

  • Serverless eliminates/simplifies devops, so the deployment/devops becomes simpler

  • You have to adopt a serverless architecture for serverless to work, this is not compatible with many best-practice recommendations for common frameworks e.g. Rails

  • No cloud provider's best practices are actually best practice. It's in their interest to lock you in, so they'll try to bake themselves into your development/test workflows or require cloud connectivitiy for development.

  • Multiple languages in the same project is not a feature

Alright now for the anti-serverless crowd

  • You have almost certainly been burned trying to follow cloud provider's best practices, ignore the cloud provider trying to lock you in and you'll have a much better time.
  • Running local versions is a requirement for effective serverless DX, and any decent serverless architecture can be run just as easily as a docker container.
  • There is a serverless architecture that will make everyone happy for most use cases. It's often non-obvious because it's at the intersection of stateless-server best practices and your cloud provider's best practices, but never entirely either.

Effective Serverless Architectures

Alright now that we've calmed down and recognized that serverless is not a messiah of programming and application architecture we can get to work building simple, easy-to-maintain, testable applications.

Here's the gist of what your serverless architecture must do:

  • Everything must be able to run locally, the same as a traditional stateful server (you need to be able to run your system)
  • Every endpoint should have tests that run against a locally-run serverless instance
  • Handle routing in a simple, easy-to-understand way, e.g. using file paths as endpoints or a central JSON configuration
  • Be absolutely normal. It should look like an npm package, a pip module etc. Nobody should need to look at a diagram to understand how it works
  • Have as little required boilerplate as possible in each endpoint
  • Monolithic code organization, a single repo per application with many endpoints.

Your cloud provider should handle...

  • Scaling endpoints automatically
  • Deploying and versioning automatically
  • Simple rollbacks

Serverless Horror Stories

I've seen people write code in a cloud provider's cloud ide and wait 2 minutes between tests. Sometimes an endpoint is connected to so many cloud services it can really only be tested in production. Sometimes there is not repo with all the endpoints, but rather many repos each containing different components of the system.

Developer experience is critical to launching quickly, you should fight to maintain fast feedback loops and testing that allows you to move quickly without worrying about the whole system breaking.

Good Serverless Providers

Every serverless provider must be retrofit to be an effective architecture.

Every serverless provider is trying to get you to irreversibly bake them in. You do not have to bake them in. Follow best practices except where it violates the "must run locally" doctrine and you'll probably be okay.

There are two serverless providers that I like right now:

  • Vercel - Built on AWS Lambda with an emphasis on developer experience. Excellent automatic deployment and versioning. Extremely good pricing. I received a massive traffic hit after refactoring collegeai.com to Vercel and it scaled Day One without any serious issues. You may need to forego their development system (vc dev) to get an effective containerized/locally-run application, but it's not difficult.
  • Cloudflare Workers - Wrangler (the command line development tool for workers) appreciates the importance of local development, and cloudflare workers are ridiculously cheap. I caution, however, that they don't have great support for NodeJS modules, so they're not yet a serious choice except where scaling cheaply is absolutely critical.

I give caution for the following providers:

  • AWS Lambda (directly) - AWS Lambda is too complicated to use for application developers, I've never seen an architecture that felt normal, obvious and ran locally with lambda.
  • Fastly - If it requires a sales call to get started you can bet the DX is going to be trash.

I don't have enough experience or heard enough about these to recommend yet:

  • Netlify - Netlify seems to have the right approach, but I don't understand their pricing for serverless on the Pro plan where people would normally start.

The space is changing quickly and I'm sure I'll have to update the content here as we see new entrants and new architectures.

Serverless is 90% Bad, but 10% Amazing

There's truth in the hype, but be defensive. Serverless has made my applications trivial to scale and maintain. Serverless applications I wrote 7 years ago are still running with little/no maintainence at almost no cost. I believe that Serverless can empower individuals to maintain large applications that would otherwise take a team and a consistent revenue stream.

Alright have fun out there.