Skip to main content

Micro-Services

· 2 min read

A simple explanation of micro-services. Also discusses some pro/cons of the micro-services.

Monolith​

What’s a Monolith?​

A complex application with a broad scope and typically large codebase.
Generally monoliths also read/write to an external DB.

Cons​

  • Tightly coupled application code.
    • A change in one particular part of the system might affect another part of the system.
  • Harder to reason about because the codebase is large.
  • Due to its broad scope, multiple teams update the same codebase.
  • Harder to scale.
  • Harder to refactor.
  • Support/Operations have a harder time maintaining a monolith because many things can go wrong.

What's a Microservice?​

A simple application with a limited scope.
Microservices can be both stateless or stateful (write to an external DB).

Pros​

  • Easy to reason about because of its limited scope and limited codebase.
  • Easier to scale.
  • Easier to refactor.
  • Support/Operations become easier.

Moving a Monolith to a Micro-Service architecture​

Advantages​

  • Changes can be applied at a faster pace.
  • Scaling
    • Can now be done at different levels for different services.
    • Can now be done at the regional level.
  • It’s now possible for the team implementing/owning the micro-service to choose the best tech stack for the job. The tech stack can be different for different micro-services.
    • Different tech stacks weren’t possible in a monolith because everything is the same code base.
  • An individual micro-service can now be leveraged by a completely different application.
    • This wasn’t possible previously because the business logic for the micro-service was “embedded” in the monolith.
  • Different Tiers can be implemented for every micro-service.
    • Tier 0, Tier 1, Tier 2 etc…
  • Possibility of cheaper infrastructure costs due to different requirements like:
    • Databases
    • Caching
    • Compliance
    • Logging
    • Data retention

Common Pitfalls​

  • Badly designed/documented interfaces.
  • The interfaces of the micro-services can’t be changed easily because you can “break” “upstream” and “downstream” functionality.
    • Communications need to be sent out to the teams maintaining the “upstream” and “downstream” services to ensure smooth releases.
  • Creation of “mini” monoliths.
  • Creation of a “distributed” monolith.
  • An “explosion” of micro-services
    • Operations are harder.
    • Integration testing is harder.
    • Maintenance is harder.