• 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?
Copy link