True, if you squint then an application will look like this too. That doesn’t mean this paradigm is not different in other important ways.
For example, in an application you can use things like types and functions to make explicit the coupling between different parts. You can iterate and verify changes on the time scale of a few seconds (instead of waiting for a lambda deployment). You can use all the tools for exploring source code we’ve developed as an industry over the decades. And you can atomically change the entire application simply by deploying it.
Of course serverless has its use cases. But evolving a system like this article shows, without most of the tools and guarantees we enjoy when dealing with code, seems like an exercise in pain.
in our serverless application(s) we still use types, and yes, that requires runtime verification at more boundaries, and therefore technically more compute cycles. we share those types across all our Lambdas. Yes, technically each Lambda must be deployed separately; in our case any changes to message-passing types would require equivalent "overhead" as a no-downtime database migration - then again, the best practice here is the same as with databases - always try to make your types backwards-compatible, only adding new fields, etc.
there's certainly _a_ cost; I just haven't seen it be as high as people seem to imagine.
For example, in an application you can use things like types and functions to make explicit the coupling between different parts. You can iterate and verify changes on the time scale of a few seconds (instead of waiting for a lambda deployment). You can use all the tools for exploring source code we’ve developed as an industry over the decades. And you can atomically change the entire application simply by deploying it.
Of course serverless has its use cases. But evolving a system like this article shows, without most of the tools and guarantees we enjoy when dealing with code, seems like an exercise in pain.