What?

Microservice Architecture

an implementation of Service Oriented Architecture which arranges an application as a collection of loosely coupled services

What is a service?

A discrete unit of functionality that can be accessed remotely and acted on independently

Properties of a service

1. It logically represents a business activity with a specific outcome
2. It is self-contained
3. It is a black box for its consumers
4. It may consist of underlying services

Why?

• Natural adoption of Domain Driven Development
• Reuse at a macro level
• Efficient Scalability
• Fault tolerance
• Polygot development and persistence
• Decentralized continuous delivery

How?

Identify business boundaries

Where to split?

• Split at business functionality
• Split at "extra" functionality
• General modularity and isolation principles

Containerize early

Decide a primary tech stack

Orchestrate as needed

Gotchas

Gotchas

• Exponential Operational Complexity
• Distributed data is no play thing
• Polygot development is a double edged sword
• Reliable inter-service communication is hard

Anti-patterns

• Shared Database
• Overly-talkative services
• Un-encapsulated services
• Distributed monolith
• Microservices as a goal
• Focusing on technology

Buzzwords

Docker

• Provides containerization
• Useful with and without orchestration
• You should probably use it

Kubernetes

• Provides container orchestration
• Don't jump into it too early. You'll hurt yourself in confusion

gRPC

• Google's RPC implementation
• Heavily uses HTTP/2
• Bi-directional streaming communication
• Most useful for inter-service communication
• Clear contracts b/w services

Tips

Tips

• Create a boilerplate early on (and maintain it as # of microservices grow)
• Add monitoring early
• Add log aggregation earlier
• Use mono-repos

Opinions

Opinions

• Services turn your O(n) complexity into O(n^a)
• Start off with a monolith
• JWTs rarely make sense outside of microservices architecture