Wardley Maps for Your Microservices Journey
summary
Wardley Maps show which microservice parts to build, buy or outsource by plotting user-facing components, data stores, message brokers and orchestration on an evolution axis; concrete suggestions include using Kubernetes + Istio to offload discovery, load‑balancing, retries and tracing, or moving to AWS Lambda + DynamoDB and API Gateway to push backup/scale/ops to the cloud. The claim: mapping prevents small teams from rebuilding commodities (404+ parts analogy), shortens delivery, and reveals exactly which integrations and configs remain to be implemented.
AI-written summary · about
chapters (9)
- 0:00The toaster project
- 1:37Microservices challenges
- 6:08Shifting focus to core domain
- 8:34Introduction to Wardley maps
- 13:34Mapping a conference app
- 17:04Mapping service complexities
- 22:42Evolving the technology stack
- 29:44Service mesh benefits
- 33:23Adopting serverless technology
related talks
50mPreparing For a Future Microservices Journey Using Wardley Maps -
50mX Marks the Spot: Navigating Possible Futures with Wardley Maps
55mStrategic Thinking in Software Architecture using Wardley Mapping
44mArchitecture for Flow - Wardley Mapping, DDD, and Team Topologies
58mFrom here to there and back again
45mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies
01h 01mCapability Mapping
43mArchitecture for Flow with Wardley Mapping, DDD, and Team Topologies