Bootstrapping Microservices, Second Edition (MEAP) With Docker, Kubernetes, GitHub Actions, and Terraform

Microservice Granularitydesign lever

The degree to which an application's functionality is decomposed into small, independently deployable processes, each owning a single bounded context and a single area of responsibility. Higher granularity means more, smaller services; lower granularity approaches a monolith.

Inter-Service Loose Couplingdesign lever

The extent to which microservices minimize direct dependencies on one another's internal implementations, preferring well-defined API contracts and indirect messaging over shared databases or tightly synchronized call chains. Loose coupling is a core design principle enabling independent deployability.

Single Responsibility Adherencedesign lever

The degree to which each microservice is designed and maintained to cover only one conceptual area of business domain responsibility, avoiding feature creep that would expand scope and increase coupling with other services.

Containerization Adoption (Docker)design lever

The extent to which the team packages every microservice as an immutable Docker image with a Dockerfile, publishes images to a private container registry, and runs all services in containers consistently across development, testing, and production environments.

Infrastructure-as-Code Adoption (Terraform)design lever

The degree to which cloud infrastructure (container registries, Kubernetes clusters, networking, role assignments) is defined in version-controlled declarative code (Terraform HCL) rather than created manually through UIs or ad-hoc CLI commands, enabling repeatable and automated provisioning.

Continuous Deployment Pipeline Maturitydesign lever

The sophistication and reliability of automated pipelines (e.g., GitHub Actions workflows) that detect code changes, build and test service images, publish them to a registry, and deploy them to production Kubernetes without manual intervention. Higher maturity means fewer manual steps and faster, more reliable delivery.

Automated Test Coverage and Layeringdesign lever

The breadth and depth of automated tests applied to the microservices application across the three tiers of the testing pyramid: unit tests (isolated function-level testing with mocks), integration tests (whole-microservice HTTP-level testing against real dependencies), and end-to-end tests (full-application browser-level testing via Playwright and Docker Compose).

Local Development Environment Qualitydesign lever

The degree to which the local development setup (Docker Compose, live reload with nodemon, separate dev/prod Dockerfiles, shared volumes) enables fast iterative coding cycles with minimal rebuild latency, environment parity with production, and easy project switching across a multi-microservice application.

Indirect (Asynchronous) Messaging Usagedesign lever

The extent to which the application uses message queues and exchanges (RabbitMQ) rather than synchronous HTTP calls for inter-service communication, allowing senders and receivers to be decoupled in time, identity, and failure modes.

Database-Per-Service Disciplinedesign lever

The practice of assigning each microservice its own isolated database (or database namespace), preventing any service from accessing another service's data store directly and thus encapsulating data management behind each service's API boundary.

Deployment Confidencepsychological state

The psychological state in which development team members feel safe and comfortable pushing code changes to production frequently, because automated pipelines, automated tests, and reversible deployment strategies reduce the perceived and actual risk of any individual deployment causing an outage.

Perceived Complexity Manageabilitypsychological state

The degree to which developers and teams feel that the complexity of the overall system is understandable and manageable, even as the application grows, because each individual service remains small, focused, and independently comprehensible without requiring global system knowledge.

Developer Productivitybehavioral pattern

The rate and quality of output by individual developers or development teams, encompassing how quickly new features can be implemented, bugs fixed, and experiments run within the microservices architecture, as shaped by tooling quality, iteration speed, and cognitive load.

Deployment Frequencyoutcome metric

How often the team successfully deploys code changes to production, reflecting the combined effect of pipeline automation maturity, test coverage, deployment confidence, and the granularity and independence of microservices. Higher frequency is associated with faster customer feedback and lower per-deployment risk.

System Reliability and Fault Toleranceoutcome metric

The degree to which the production microservices application continues to operate correctly under load, partial failures, and individual service crashes, enabled by Kubernetes deployment controllers that restart failed pods, independent service fault isolation, and RabbitMQ message durability that prevents data loss during transient failures.

Application Scalabilityoutcome metric

The capacity of the application to accommodate growth in customer demand (horizontal scaling of individual services via additional pod replicas) and growth in development team size (independent team ownership of separate services), without requiring coordinated changes across the entire codebase or monolithic redeployment.

Codebase Evolvability and Disposabilityoutcome metric

The ease with which individual services can be rewritten, replaced, or restructured without cascading changes across the application, enabled by hard process boundaries, well-defined API contracts, loose coupling, and the design principle that each service should be small enough to be disposable and rewritable within days or weeks.

Team Size and Prior Experiencecontextual condition

A contextual moderating condition capturing whether the development team is a solo developer, a small startup team, or a large engineering organization, and the prior experience level with distributed systems, Docker, Kubernetes, and cloud infrastructure, which significantly moderates the cost-benefit trade-off of adopting microservices.

Application Growth Trajectorycontextual condition

A contextual condition representing whether the application is expected to remain small and stable (making a monolith appropriate) or will continuously evolve, grow in feature scope, and scale to a larger customer base and development team (making microservices the more economical long-run choice).