Monolith vs. Microservices

• Opposite of Microservices
• Monolith:
  1. No “internal” services
  2. A single code base (repo)
• Actually it’s a spectrum
• Actually even a monolith is three tier
• Monoliths are not bad and Microservices are not good

Pros and Cons

• Monolith
  1. Fewer API/Interfaces to design, test and deploy
  2. One codebase is more efficient
  3. Devops is far simpler
  4. No extra network communications overhead
  5. But: Overly-tight coupling
  6. But: A bigger, single architecture is harder to understand
• Microservices
  1. Forces more modularity and better organization
  2. Allows service reuse, and additional scaling options
  3. Really isolated testing is possible
  4. But: Extra work for cross cutting concerns (e.g. logging, authentication, monitoring etc.)
  5. But: Far more complicated operations and devops

Microservices

• This article lays out an approach to Break a monolith into Microservices
• STEP 1: Start thinking about building Devops
  1. Environment variables
  2. Services mapped to hosts
  3. Automation
• STEP 2: First attack simple self-contained functionality
  1. Either needs no database or has a table that no other part of the system uses
  2. It should be easy to isolate with interface of a single class or a few methods
  3. Preferably “functional”, think amazon Lambda etc
  4. Next create a think sinatra (or other) layer to accept requests as urls and paths and return results as http results.
  5. Demonstrate that it works by running automated deployment, installation, configuration, and service start, stop and restart operations
• STEP 3: Next decouple a service which doesn’t share data
  1. Again a service that needs no database or has a table that it fully controls
  2. The goal again is to make the interface in the form of a class and/or a set of methods
  3. Might need <%= link_to_topic :refactoring %> in order to remove or reduce dependencies
  4. Then, continue as above