The Nine-Service Problem: Dependencies, Drift, and Resource Cost
The demo application, Trader Hicks, is a banking microservices system with nine workloads. Docker Compose can run all nine, but every image update triggers a full pull, and the full stack consumes substantial disk space and CPU. Kubernetes is the other option, but generating manifests for nine services produces 600 lines. A developer working on the front end may have no access to back-end services another team is still building. Without a shared spec, local and cluster configurations drift.
Score: One Workload Spec, Any Platform
Score is a workload specification format. A developer writes one file describing their service’s image, ports, and resource dependencies. They don’t name a target platform. Score CLI tools translate the same file to different targets: score-compose generates Docker Compose YAML; score-k8s generates Kubernetes manifests. Nine workloads produced 70 lines of Compose and 600 lines of Kubernetes from identical score files. Platform engineers define how abstract dependencies map to real infrastructure, without requiring changes from developers.
Microcks: API Mocks Derived From Contracts
Microcks reads API artifacts organizations already produce: OpenAPI specs, Postman collections, gRPC protobuf definitions, HTTP archive recordings. From those, it generates live mock endpoints with no manual configuration. The more artifacts you load, the more realistic the responses. Microcks adds OpenTelemetry tracing so developers can inspect what triggered a specific mock response. For stateful interactions, scripting and templating are available. Contract testing comes as a side effect: Microcks generates a test suite from the same artifacts and runs it against live implementations.
Score + Microcks: Four Containers, Full App
Platform engineering added a Microcks provisioner to Score. The developer kept their score file unchanged. Passing only the workloads they need to deploy, Score resolved the remaining dependencies and spun up a Microcks instance to serve their API contracts automatically. Nine microservices became four real containers plus five mocked ones. The Compose file shrank. Locally, the full Trader Hicks application responded on localhost. Disk usage dropped and developers stopped blocking on services other teams hadn’t finished.
Contract Testing Bridges Mock and Production
Intermediate environments (QA, staging) often run at 10% utilization but still need full provisioning. Mocking unused backend services cuts cost. The risk is drift: a mock might accept requests the live API would reject. Microcks addresses this by generating a contract test suite from the same artifacts used to build the mocks. Once a service is deployed, Microcks runs those tests against it. A GitHub Action or CLI call in CI catches breaking changes before they reach the next environment.
Notable Quotes
you just have to fake it until you make it or until you actually need it Laurent Broudoux · ▶ 12:33
so you’re just not blind these are not dummy mocks you have the ability to also inspect and observe everything Mathieu Benoit · ▶ 21:05
Key Takeaways
- Score abstracts workload deployment into one platform-agnostic spec that generates both Docker Compose and Kubernetes manifests.
- Microcks serves API mocks from existing contracts, letting developers work against dependencies that aren’t deployed yet.
- Combining Score and Microcks reduced a nine-service stack to four real containers by mocking five services automatically.
About the Speaker(s)
Mathieu Benoit is a Solutions Engineer at Docker and CNCF Ambassador. His background covers software engineering, IT consulting, solution architecture, and customer success, with a current focus on Cloud Native technologies, containers, Kubernetes, and platform engineering.
Laurent Broudoux is a Cloud Native architecture specialist and the co-founder and lead developer of Microcks.io, a CNCF sandbox project providing Kubernetes-native API mocking and testing. He draws on over 10 years of architecture experience.