Microservices Roadmap: One Tool Per Layer

Read the stack as layers, not as a completion badge. Foundation: containers + language runtime. Data: database-per-service + optional cache. Communication: sync APIs + optional broker. Edge: gateway/load balancer + TLS/auth. Operations: orchestrator + metrics/logs/traces. Cloud: managed versions of the above.

Minimal production slice for a first split: Docker (or equivalent) + one language + one primary database + one sync style (REST or gRPC) + Kubernetes (or a managed equivalent) + Prometheus metrics + basic structured logs. Add a broker when sync fan-out hurts. Add a gateway when clients should not know every service URL. Add distributed tracing when “which hop is slow?” is unanswerable.

You do not need every product named on a poster. You need one default per layer and a rule for when the default fails.

Containers package a service with its dependencies so laptop, CI, and cluster run the same artifact. Docker is the common default; Podman is a daemonless alternative; LXC appears for OS-level isolation niches. Language choice is per service: .NET, Go, Java, Node.js, Python — standardize on deploy and observability contracts, not on one language forever.

When to use containers: any service you deploy more than once. When not to: a single process on one VM with no plan to scale out — still learn images, but do not invent a platform. Failure modes: fat images with secrets baked in; “polyglot” as an excuse for zero shared logging/metrics conventions.

Volumes and persistence are a separate concern — see Docker Volumes Explained. Container vs orchestrator roles: Docker vs Kubernetes.

Database-per-service means each service owns its store. SQL (PostgreSQL, MySQL, and similar) fits transactional schemas and joins inside the boundary. NoSQL (document, wide-column, managed key-value) fits when the access pattern demands it — not because a slide said “NoSQL.” Caching (Redis as the usual default; Memcached for simple get/set; grids like Hazelcast in some Java shops) sits in front of hot reads.

When to add a cache: the same rows are read constantly and freshness rules are clear. When not to: before you measure — cache without invalidation is a new incident class. Failure modes: shared schemas across services; dual-writes without an outbox; cache as a second source of truth.

Selection help: How to Choose the Right Database, SQL vs NoSQL, Caching Strategies.

Services talk synchronously (HTTP/REST, gRPC) and asynchronously (queues and streams). Brokers decouple producers from consumers: Kafka for high-throughput log/stream workloads; RabbitMQ for flexible routing and task queues; cloud queues (e.g. SQS) when managed simplicity wins. API gateways (Kong, Envoy, cloud gateways, Ocelot in .NET shops) give clients one front door. Service discovery is often Kubernetes DNS; Consul/Eureka/ZooKeeper appear in non-K8s or legacy meshes. Enterprise API management platforms add partner portals and governance when that is the actual need.

When to add a broker: sync fan-out or temporal decoupling is required. When not to: two services with a simple request/response — a queue adds ops without buying autonomy. Failure modes: dual brokers “just in case”; gateways stuffed with domain logic; hard-coded service IPs.

Compare brokers in Kafka vs RabbitMQ vs SQS; async patterns in Event-Driven Architecture; placement of protocols in Microservices Communication; edge proxy detail in NGINX Gateway.

Load balancers / reverse proxies (NGINX, Traefik, cloud LBs) spread traffic, terminate TLS, and health-check backends. Security spans TLS everywhere you care about, JWT/OAuth at the edge for clients, and mTLS or mesh identity between services when the threat model needs mutual authentication.

When to use mTLS/mesh identity: many services, untrusted network segments, or compliance that demands service identity. When not to: two services on a private network with a clear gateway and workload tokens — start simpler, document the threat model. Failure modes: microservices exposed directly to the internet; JWT accepted without issuer/audience/exp checks; sticky sessions hiding bad instance health.

Deep dives: Load Balancing L4 vs L7, JWT Deep Dive, JWT vs Session vs OAuth, API Security Best Practices.

Orchestration schedules and heals containers: Kubernetes is the common default; managed Kubernetes (EKS/AKS/GKE) removes control-plane toil; Swarm is simpler but declining; Nomad fits mixed workloads; OpenShift adds enterprise Kubernetes opinions. Monitoring answers what is broken (Prometheus + Grafana for metrics; a log stack for search). Tracing answers why a request is slow (OpenTelemetry into Jaeger/Zipkin or a vendor backend).

When to add tracing: multi-hop latency you cannot explain from metrics alone. When not to: a single service with clear logs — still emit useful metrics. Failure modes: orchestrating before you can build/test/deploy one service cleanly; dashboards nobody watches; traces without sampling or correlation IDs.

Traffic into pods: Kubernetes Request Flow. Signals: Observability: Logs, Metrics, and Traces.

Cloud providers mostly sell managed versions of the same layers: managed Kubernetes, databases, queues, load balancers. AWS, Azure, and GCP differ in ecosystem fit (.NET/AD on Azure; breadth on AWS; data/K8s heritage on GCP), not in whether you still need ownership boundaries and observability.

When to use managed services: your team’s scarce skill is product, not running brokers. When not to multi-cloud: unless compliance or exit strategy truly requires it — dual everything doubles failure modes. Failure modes: collecting managed services without a minimal slice; treating cloud choice as architecture.

Learn concepts first; tools map across clouds. Expand gateways, tracing, and advanced caching only as complexity earns them.