Microservices Are Easy to Create and Manage

 |  Writings

I bumped into the claim somewhere on LinkedIn and that got me thinking why some people may think so while others consider this a huge overstatement. As I often see, such contradictions emerge because people judge microservices from very different implied contexts. In this article I make a draft attempt to make the context explicit and common to reconcile these contradictions.

Summary

Microservices are easy to create and manage when there are few of them (2-3-5), the core product functionality is stable within 6+ months (no inter-service contracts change), the workflows are a few (2-3) and simple, and load is small (e.g. 10-50 RPS). When one of these characteristics is disturbed the very high immanent complexity of microservices spills out and quickly becomes very hard to manage.

Nevertheless, the statement "microservices are easy to create and manage" is very attractive as a target state, and this writing aims at defining the ways to get close to that target. After all, making complex things simple and manageable is a part of our craft - software engineering.

Why Microservices Are So Complex

Reliable microservices require very complex implementation. Compared to correctly done modularized monoliths, the number of extra dependencies is like 20+. I list the core ones:

  • Inter-services contracts: (e.g. OpenAPI, AsyncAPI), 1 contract per each service inputs and outputs - creation and alignment with 2 other dependents (inputs and outputs), contract versioning, contract enforcement.
  • Messaging: the facility (e.g. RabbitMQ) - at least one separate unit to deploy, .
  • Deployment complexity: requires versioning match and Kubernetes for more than 2-3 services.
  • Operations - debugging and operational observability: structured JSON logging for business flow, error logging for system exceptions, monitoring for service health (Prometheus, Grafana and all that stuff).

Microservices Dependencies Reference

Here are 4 large operational groups of dependencies for further analysis.

Boundary Integrity

  • strict contracts: simultaneous cross-service contract evolution, backward compatibility, contract versioning pressure.
  • minimal shared state: data duplication, duplicated data consistency.
  • stable ownership boundaries: clear service responsibility and dependency isolation.

Purpose: Prevent uncontrolled coupling and assumption leakage between services. Core question: "What is allowed to cross service boundaries?"

Workflow Determinism

  • deterministic workflows: complexity controlled with explicit state machines and behavioral patterns (strategy etc).
  • idempotent operations: retries, duplicate suppression and replay safety (preserved state, correlation IDs).
  • async/event workflows: application event/domain facts contract enforcement and evolution management.
  • error handling: clean separation between domain errors and application errors.

Purpose: Ensure distributed processes behave predictably despite retries, delays, duplicates, and failures. Core question: "Will the system converge to the same valid state under real-world distributed conditions?"

Debugging and Operational Observability

Purpose: Make distributed behavior explainable and diagnosable. Core question: "Can we reconstruct what happened and why?".

This area gradually expands into:

  • logs: (structures JSON, application, exception logs).
  • correlation IDs.
  • distributed traces.
  • operational and business metrics.
  • workflow/data lineage.
  • auditability.

Delivery

Purpose: Reduce operational complexity by deployment standardization and automation across services. Core question: "Can every service be operated the same way?”

This includes:

  • standardized deployment model.
  • runtime conventions.
  • CI/CD.
  • infrastructure topology.
  • service templates.
  • operational procedures.
  • resilience standards.

Suggestion

Reducing complexity in these four groups by standardizing and automating gradually and systematically paves the way to the "microservices are easy to create and manage" target state however hardly achievable for complex and rapidly evolving systems.

Basic Reading: Sam Newman, "Monolith To Microservices", "Building Microservices".