Order of deployment of microservices and dependencies

Serverless Framework
#1

I would like to have an API gateway per microservice and I wish to have the lamda-authorizer shared across all the API gateways.

I was reading here https://www.serverless.com/framework/docs/providers/aws/events/apigateway/#sharing-authorizer and it seems possible but I am not sure

  1. how to ensure that lambda authorizer gets deployed first so that we have the arn to use in all of the APIGateways.
  2. Also, If MicroserviceA calls MicroserviceB, How do we ensure that MicroserviceB is deployed first?
  3. Similarly, where/how should the “shared-services” in the project be structured/placed so that inter-service communication is easy.
#2

I’m not an expert, but I’m facing the same problems and below are my possible solutions.

  1. I identified that there are some common resources, used by different microservices (domain name, authorizer, …). I have a stack for these resources, deployed using serverless stack toolkit (SST): GitHub - serverless-stack/serverless-stack: Serverless Stack Toolkit allows you to deploy CDK and Serverless Framework apps together.
    This stack is first deployed, and then the microservices.

  2. I think that it is an anti-pattern to call a microservice synchronously from an other microservice. To avoid this I used two patterns. For asynchronous calls between microservices, I use SNS topics (created using SST) on which some events are published with their payloads, and other microservices subscribe to the interesting events. For example, it is useful when a data is deleted and other microservices have relations to this data (I notified them that the data has been deleted). For synchronous calls between microservices, I use an “orchestrator”. Some complex API methods require to communicate with several microservices. Then, the “orchestrator” is responsible to these complex calls and it orchestrates the communication between the microservices.

  3. I’m not sure to understand correctly the question. We use a mono-repo approach for the service layer in order to permit reusability of code that is not service specific, but it is forbidden to communicate directly between services. The other advantage is that the orchestrator do not have to call deployed lambda, it use directly the code of the service, and it avoid too many cold starts.

I hope it helps you, and I’m interesting to any suggestion about improving this management.

#3

@Patchoulin Thank you for your response.

  1. Why SST for the common resource. We can have nested stacks in the serverless framework for example (or even individual stacks that we can decide to deploy before microservices). Does that not do the same thing? Curious if I am missing out on something here.

I am considering using lerna instead and adding the downstream services as dev-dependencies

.
2. Could you share an example of the orchestrator, please? For example, we are just starting off and we have 3 microservices to register a tenant. Now one of these services calls two other services. I imagine this to be happening a lot for synchronous communication. I would love to have a better idea of your orchestrator that would facilitate this without making it an anti-pattern.