4 ms·

I'd say this is what any distributed system looks like, it's not exclusive to AWS and serverless architecture. It's not even exclusive to distributed systems,

I'd say this is what any distributed system looks like, it's not exclusive to AWS and serverless architecture. It's not even exclusive to distributed systems, most computer systems look like this when you actually think about it. Consider what an application would look like if you mapped out each service and object, it would easily look as complex. This isn't a new concept, we've had the idea that everything in computing could be represented by little computers communicating with each other since the 60s, Alan Kay called it "object-oriented programming". The only difference is between the 60s and now, is that instead of mainframes we have platforms, so now we can actually have "little computers communicating with each other".

physicles 6y ago
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.
- ledauphin 6y ago
  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.

physicles 6y ago

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.

ledauphin 6y ago
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.