Mono repo vs one per service

Click for: original source

An article by Yan Cui about his take on using code repository when working with microservices and serverless. With AWS Lambda, we can deploy and scale individual functions. However, we engineers still like to think in terms of services and maintain a mapping between business capabilities and service boundaries.

The service boundaries allow the teams to be autonomous and empowers them to choose their own technology stacks. Where AWS Lambda is a good fit, a service would be made up of one or more Lambda functions as well as event sources such as API Gateway. The fact that the functions that make up a service are scaled independently is merely an implementation detail, albeit one that can work very well to our advantage.

Before we delve into it, I should clarify that within a monorepo you can still deploy services independently. Functions are still organized into services, and each service would reside within a subfolder in the repository.

The article explains:

  • What is a monorepo
  • How one repository per service works
  • Which approach should you choose?

The monorepo approach offers small teams a great opportunity to gain early momentum. But you need to keep in mind that the cost of this approach would skyrocket as the organization grows beyond a certain point. Nice read!

[Read More]

Tags devops microservices programming agile aws software-architecture teams