• Lighter weight deployments

  • Can mix usage different programming languages


  • Many repositories

    • Complex

  • Poor knowledge sharing

  • Orchestration

    • Understanding orchestration across multiple services/repositories is difficult, especially when thing are inconsistent

  • Exchanging ownership

    • Imagine all members of a team leaves, who manages ownership?

  • Each team needs to know devops (to a certain extent)


  • Service Discovery

  • Event Bus

    • Pub/Sub

Good for:

  • Services that can't exist in a FaaS environment

  • Migrating a serivce to a different programming language

    • Migrating bits and pieces

When should you use microservices?

  • A functionality or component that is bottlenecked

    • Would be easier to scale if it was separate

  • Reusable functionality across different services

    • Can exist as a library; or micro service

  • Isolate small piece of code for:

    • Improved quality

    • Predictable/different release cycles

    • Security

  • When you want to create a black box

  • Reduce transparency

  • If it can exist as it’s own product

  • Things which can’t exist in a FaaS

When should you not use a microservice?

  • When you have a small team

Questions to ask:

  • When should you bundle a microservice?

  • When should you unbundle a microservice?

  • When should you break down a monolothic app into a microservice?

  • When does a microservice become a monolithic app?

  • If your goal is to keep it as a Single Responsiblity Principle

    • Why not just use a FaaS architecture?


Last updated