Serverless app platforms and feature ceilings

What is the best way to build a serverless app today?

This is a question I regularly re-evaluate. Of course, the answer is always context-dependent, but my default starting point in the vast majority of cases is with AWS.

Building serverless apps on AWS is reliable, powerful and generally cost-effective. It offers services for all the core infrastructure you need to build a modern app: REST APIs, GraphQL APIs, CDN, data stores, eventing, queues, orchestration, etc.

But with the power of AWS comes a lot of Developer Experience related pains. The documentation sprawl is one that’s commonly cited, but here are few others that I experience frequently:

• Setting up CI/CD requires a load of config, and everyone seems to do it differently
• Multi-account is best practice in terms of security and environment isolation but it’s also a major overhead to manage
• IAM is bloody hard to get right
• CloudFormation, while powerful, is verbose, often doesn’t have desirable defaults and takes time to learn

There are several companies in the “serverless app platform” space aiming to take advantage of these DX deficiencies of AWS, including Netlify, Vercel and Begin. I recently had an impressive alpha demo of Serverless Cloud from Jeremy Daly and his team at Serverless Inc and it looks like it will be a strong competitor soon joining this space. I love this from its docs:

The cloud is immensely powerful, but also complex and filled with lots of moving parts. Developers are now wearing more hats than ever before, not only building and designing software, but becoming cloud architects that need to understand countless cloud services, scalable data engines, fault tolerance, and so much more. The goal of Serverless Cloud is to reduce this complexity by automatically applying best practices to common use cases, removing the need for all the boilerplate and configuration, and allowing developers to do what they do best: build software.

I’ve used Netlify for both my personal website and a recent client project, and it’s been a really nice experience. And re-assuringly, the fact that it’s built on top of AWS infrastructure means its mostly inherits their reliability.

But a question that I’ve been pondering is: what if I hit a feature ceiling with these platforms? Working on greenfield projects, it’s hard to foresee what your architectural needs will be in a year’s time. What starts as a standard web app with a REST API and database can evolve into a more distributed and async system as user feature requests arrive.

As an example, let’s say I’m working on a project that runs on one of these app platforms. I need to implement a new use case that requires a feature that I can’t do inside the platform such as multi-step task orchestration (AWS Step Functions does this).

Now this is theoretical as I haven’t yet hit this issue in a real project, but I can think of a few ways I might approach it (assuming Netlify is the platform I’m using here):

• Workaround it — Keep everything in Netlify and shoehorn a suboptimal implementation into Netlify Functions
• Full ejection — Migrate everything over to AWS, replacing existing Netlify Functions with raw Lambdas
• Hybrid approach — Keep existing functionality in Netlify and implement new feature in AWS. Have them communicate via queue/eventbus

Each of these options has several pros and cons to think through, although the hybrid option seems the most appealing.

In the past, with server instance-backed platforms like Heroku, stories were common of products outgrowing the platform and having to eject and move to EC2 once they hit a certain scale. But with the serverless model, expectations are changing here. Your architecture shouldn’t need to have major changes as it grows.

I’m really rooting for these serverless app platforms. As a developer, they’re undoubtedly more fun to use than AWS. In fact, I’d argue that choosing them over direct AWS is more in keeping with the first commandment of the Serverless Manifesto:

Build only what differentiates you, outsource what doesn’t.

While CI/CD is really important, spending hours of engineering time building and maintaining a multi-AWS account pipeline is not differentiating.

But I want these platforms to be more than just: “use us for our great DX to get your product up and running fast and you can always move back to AWS when you hit scale”.

These platforms will never be feature-equivalent with AWS, but if they can provide a good answer to the feature-ceiling question and still keep you around as a customer when you hit a certain level of scale, they will be winning.