# Transcript: The Promise vs. Reality of Microservices
**Speaker:** Tom Akehurst
This talk explores the **gap between the ideal of microservices**—decoupled, autonomous teams—and the messy reality of **interconnected dependencies**, and proposes **API mocking and simulation** as practical solutions.
---
## Introduction: Why Microservices Promise Independence
- **Goal:** Enable teams to build and ship value **independently**, without heavy cross-team dependencies.
- **Reality:** Despite microservices architecture, dependencies and coupling persist.
- **Impact:** Developers spend time fixing broken environments, chasing missing data, and waiting for dependent API changes — slowing delivery cycles and reducing job satisfaction.
**Key Proposal:**
Use **API mocking/simulation** to break dependency chains, speed iteration, and reduce frustration — with supporting techniques for optimal integration.
---
## Decoupling Strategies
> **Note:** Some “decoupling” strategies are actually coping mechanisms.
### Common Approaches
1. **Process & Gatekeeping**
- Few shared environments, tightly controlled.
- Strict constraints on deployments, data, and access.
- Originates from legacy environment management styles.
- Drawback: Slows progress and encourages “gaming the system” rather than improving quality.
2. **Many Environments per Team**
- Each team gets its own production-like environment.
- Freedom to deploy & modify without affecting others.
- Drawbacks: High operational cost, complexity, and cognitive load.
3. **Smart Environments + Remocal**
- **Ephemeral environments** spun up/destroyed quickly.
- Combine **local services** with shared **remote components**.
- Works best in modern, low-legacy stacks.
- Less effective in heavily integrated, legacy ecosystems.
---
### Tool Spotlight: WireMock
An **open-source API mocking tool** designed for realistic simulations of dependent services, enabling decoupled workflows.
---
## Mocking, Simulation & Virtualization
**Definition:**
Network-level mocking — simulate API calls over the network, not just in-code object mocks.
**Benefits:**
- Self-contained test environments.
- Reduced cost compared to full-stack environments.
- Works for legacy & third-party APIs.
- Lower cognitive load — focus on API contracts instead of internal system details.
**Challenges:**
- Mocks must be realistic to avoid surprises in production.
- Maintenance burden — need strategies to keep simulations aligned with actual APIs.
---
## Core Concepts
1. **Observation**
- Captured client<->API interactions (e.g., HTTP request/response pairs).
2. **Simulation**
- Reproduce API behavior offline (tools like WireMock).
3. **Contracts**
- Syntax descriptions of API: operations, data structures, constraints.
- No behavioral details.
**Key Workflows:**
- Generate simulations from observations or contracts.
- Validate observations against contracts.
- Diff contract versions to find breaking changes.
---
## Example Workflow: Detecting API Changes
1. Use **curl** to send traffic to Payments API.
2. **WireMock** captures simulation.
3. **Optic** captures contract & generates OpenAPI spec.
4. Later, rerun traffic capture — detect spec changes (e.g., type change from `number` to `string`).
5. Use **Prism** to validate simulation against updated spec.
6. **Optic diff** highlights breaking changes.
**Tip:** Automate this in your CI pipeline for constant validation.
---
## Observability for APIs
Approaches:
- **In-code instrumentation**
- **Integration test instrumentation**
- **Proxying** (forward/reverse proxies)
- **MITM proxying** (challenging with HTTPS)
- **Packet capture** (limited for encrypted data)
- **eBPF tools** (observe below encryption layer)
- **Service mesh event capture**
Purpose:
Collect real traffic patterns and use them to inform simulation realism and contract validation.
---
## AI in API Workflows
- Large Language Models (LLMs) excel at generating open formats like OpenAPI.
- Use AI to enrich baseline mocks with realistic variations.
- Combine with contract testing as guardrails to ensure accuracy.
- AI can help infer stateful behavior and complex API patterns.
---
## Future Trends
- **OpenAPI Overlays & Arazzo** for richer, multi-step workflow descriptions.
- Increasing integration between observability tools (eBPF, service mesh) and simulation workflows.
- MCP and AI tool convergence enabling orchestration across multiple systems with synchronized changes.
---
## Summation
- Use mocking/simulation for most testing — reserve integrated testing for true integration risks.
- Combine **observability**, **generation**, and **contract testing** to reduce labor, increase reliability.
- AI + contract testing boosts productivity while keeping outputs trustworthy.
---
## Q&A Highlights
**Q:** How to avoid same-response mocks?
**A:** Make real-world observations first — understand API behavior — then automate variability (possibly with LLMs).
**Q:** Ensuring contract<->contract tests coherence?
**A:** Contract validation should be part of functional test setup — failures reveal mismatches as a side effect.
**Q:** LLMs driving frontend-only testing?
**A:** Beware explosion of low-value tests. Focus on boundaries, use mocks effectively, and keep end-to-end testing deliberate.
**Q:** Mocking stateful behavior without duplicating API?
**A:** Record observations, detect patterns, model states — AI can help infer nuanced behavior.
---
**References:**
- [AiToEarn官网](https://aitoearn.ai/) – Open-source AI content monetization platform.
- [WireMock](http://wiremock.org/) – Open-source API mocking tool.
- [Optic](https://optic.dev/) – API contract capture and diffing tool.
- [Prism](https://stoplight.io/open-source/prism) – OpenAPI contract validation proxy.
