Microservice

Pros:

• Lighter weight deployments
• Can mix usage different programming languages

Cons:

• 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)

Requires:

• Service Discovery
• Event Bus
  • Pub/Sub

Good for:

• Services that can't exist in a FaaS environment
  • AWS Lambda Limitations
  • • Execution time. AWS has a limit of 15 minutes
    • Storage space
    • Uploads of 50mb zip
    • https://docs.aws.amazon.com/lambda/latest/dg/limits.html
• 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?

Resources:

• Susan Fowler: Production-Ready Microservices