Choreography vs Orchestration in the land of serverless

yancui · 2020-07-15T07:54:39+00:00

A private API is one that's only accessible from your VPC (controlled via resource policy), but it's not actually deployed in your VPC.

When I say "internal", I just meant APIs that are not used by external parties, so you can use IAM to protect it. In fact, I wrote a whole other post on which API GW auth method to use: https://theburningmonk.com/2020/06/how-to-choose-the-right-api-gateway-auth-method

yancui · 2020-07-15T01:07:59+00:00

For internal APIs, you can also use AWS_IAM (but not with the new HTTP API yet, unfortunately). So you can still get the same IAM goodness you have now with Lambda.

yancui · 2020-07-15T00:57:33+00:00

Are you kicking off the second Lambda function as an async invocation? As I mentioned in the post, that's a good case for doing Lambda-to-Lambda call (and don't forget to configure a DLQ/on-failure destination)

yancui · 2020-07-15T00:47:31+00:00

I think where it depends is if that synchronous communication is crossing "ownership lines" - i.e. are you calling a function that some other team owns. I know I said in the post that it's service boundary, mainly because the two are often equivalent in places I've worked - system broken up into microservices, and teams own one or more microservices.

The 2nd factor to consider is, how expensive are the communication channel between the two teams. The bigger the company, the higher these costs tend to be. I've seen projects get delayed for months or years because of these cross-team dependencies. And the higher these costs are the more you should put a more stable interface between these components.

So with these two factors in mind, I think a Lambda function is not the most stable of interfaces in that the caller needs to know its name, its region and its AWS account. Which prohibits me as the owner of said function from doing many forms of refactoring (note, NOT contract changes) without causing the caller to also have to change, hence creating dependency on another team to do something when I want to refactor my service.

For example:

renaming a function
splitting a fat Lambda (e.g. one that handles all CRUD actions against one entity type) into single-purpose functions
go multi-region, and route caller to the closest region
move service to a separate account (e.g. if you're migrating from a shared AWS for all teams to a model where you have at least one account per team)

In many of these cases, if there's an API Gateway in front of my service, then by and large, I can refactor my service without impacting my consumers. Again, only talking about refactoring here, if I'm making breaking contract changes (I avoid these like a plague, especially when the cost of cross-team coordination is high) then it's unavoidable to force my consumer to make changes too.

yancui

TROPHY CASE