In my startup, we began with a monolithic back-end where we could refine our product and prove market fit. At first, this was indeed fast to develop and simple.

In my startup, we began with a monolithic back-end where we could refine our product and prove market fit. At first, this was indeed fast to develop and simple. The company grew and the product saw heavier use. The original monolithic server became slow and problematic. Hosting cost became very high. Separate teams ran into conflicts while working on the server. So we have incrementally switched to an FaaS-centric architecture, similar to the one in the article. The new design makes it easier to get excellent stability, performance, cost and observability. Now that the development team is a little bigger, FaaS/microservice design makes it easier for the teams to work without blocking each other. I’m sure that same benefits could be achieved in a traditional monolithic server with careful design and control of the development process, but it seems easier and quicker to accomplish with FaaS. Indeed, a simple REST API sometimes requires dozens of handlers. One might worry that this is complicated because each handler is somehow running in a separate container... but that’s really the cloud provider’s problem. Execution is very finely segmented, while logical division of the code-base is generally free to follow natural domain divisions. It’s pure benefit to us: endpoints have excellent isolation. We have excellent control for behavior in overload scenarios. FaaS handlers tend to be simpler than each action in the former monolithic server. With simplicity, it’s easier for us to ensure handlers follow a common set of best practices. With simplicity, consistency, and fine-grained isolation it is easier to reason about the performance and capacity of the system. While there are scenarios where FaaS is prohibitively expensive, our use stays within its sweet spot and is significantly less expensive than running the previous monolithic server. A downside of FaaS is that it quickly became impossible to run the entire system on a developer laptop. We really need to run things on the cloud infrastructure for any kind of integration test. So far, it has been hard for us to provide developers or test infrastructure with independent Integration test sandboxes. Vendor lock-in is a problem: it will be hard for us to change cloud providers if ours becomes problematic.