A Microservices Journey Susanne Kaiser @suksr CTO at Just Software @JustSocialApps
Each Journey is Different “People try to copy Netflix, but they can only copy what they see. They copy the results, not the process.” Adrian Cockcroft, AWS VP Cloud Architect, former Netflix Chief Cloud Architect
Each Journey is Different Affecting Circumstances Team Structure Skillset Journey Size
Each Journey is Different Affecting Circumstances Legacy Maintenance Runtime Team effort environment Structure Skillset Journey Size
Each Journey is Different Affecting Circumstances Legacy Maintenance Runtime Team effort environment Structure Skillset Journey Strategy Size New Features Timeline / Milestones
Background JUST SOCIAL JUST DRIVE JUST CONNECT JUST LIST JUST WIKI JUST PEOPLE JUST NEWS
At the Beginning A Monolith in Every Aspect One team One technology stack Single Unit One collaboration product
Background After an Evolving Time
Background After an Evolving Time Productivity suffered
Background After an Evolving Time Productivity suffered Usability/UX suffered
Background After an Evolving Time Productivity suffered New features released slowly Usability/UX suffered
Background Separate Collaboration Apps JUST DRIVE JUST CONNECT JUST LIST JUST WIKI JUST SOCIAL JUST PEOPLE JUST NEWS
Background Separate, Autonomous Teams Well-defined responsibilites
Background In The Long Run Organisation Software Product
Background Our Motivation for Microservices Autonomous Work at different parts Deploy independently Scale independently Develop independently teams independently At different speed
Decomposition Strategy Identify Bounded Contexts Loose coupling between services High cohesion within a service
Decomposition Strategy Identify Bounded Contexts Loose coupling between services High cohesion within a service Bounded Context Well-defined Related behaviour business function Semantic boundary around domain model
Decomposition Strategy Identify Bounded Contexts Bounded Contexts JUST DRIVE JUST CONNECT JUST LIST JUST PEOPLE JUST NEWS JUST WIKI
Decomposition Strategy Co-Existing Service From Scratch JUST DRIVE
Decomposition Strategy Co-Existing Service From Scratch JUST PEOPLE JUST DRIVE
Decomposition Strategy Co-Existing Service From Scratch REST API JUST DRIVE Application-Service Domain-Model Monolith DB Adapter owns document state
Decomposition Strategy Co-Existing Service From Scratch REST API Application-Service Domain-Model Monolith DB Adapter owns profile document owns document created by state state author
Decomposition Strategy Co-Existing Service From Scratch REST API Application-Service Domain-Model Message Broker Adapter Monolith subscribe publish DB Adapter Message Broker owns profile state Events owns document state local copy of author
Decomposition Strategy Co-Existing Service From Scratch New UI REST API Good approach in general, New Business Logic Application-Service but we did too many steps at once Domain-Model Domain-Event Message Broker Adapter => Not optimal to start with DB Adapter New Data Structure vs.
Decomposition Strategy Incremental Top Down REST API REST Client REST API Monolith Extracting Web App
Decomposition Strategy Incremental Top Down REST API Monolith uses extracted business logic Application-Service REST Client Domain-Model Monolith DB Adapter Extracting Business Logic
Decomposition Strategy Incremental Top Down REST API Application-Service Domain-Model Message Broker Adapter subscribe Monolith publish DB Adapter Message Broker Events Splitting Data Storage
Decomposition Strategy Which One First? Changing Frequently Greatest benefit vs. after extraction Easy to Extract Different Resource Consumption Early experiences w/ Microservices
Cross-Cutting Concerns Authorization JUST DRIVE JUST WIKI Inter-service dependency Fine-grained authorization
Cross-Cutting Concerns Authorization I have a new service that needs authorization. Where is the authz service I could use? Not there, yet. Sorry! Ok, then I am putting my code Ok, then I am implementing authz to the place where authz handling in my local service. exists … to the monolith. Re-implementing authz w/ every Feeding the monolith new service
Cross-Cutting Concerns Handle Them Early Feeding the monolith Re-implementing authz w/ every new service Handle Cross-Cutting Concerns Early
Cross-Cutting Concerns Avoid A Distributed Monolith Authz Service
Cross-Cutting Concerns Avoid A Distributed Monolith translate Authz Service translate One stable translate common contract
Service Interaction Event-Driven / Request-Driven command query command Message Broker Message Broker Events query Events subscribe publish subscribe publish Request-Driven Hybrid Event-Driven
How To Manage Shared Data? Hybrid Model Remote query directly to source REST API Message Broker Events for notification
How To Manage Shared Data? Event Driven State Transfer ProfileUpdatedEvent Message Broker Local copy of profile data Events for data duplication
How To Manage Shared Data? Source Of Truth Multiple sources of truth Single source of truth Internal source of truth Event Log Events as first-class citizens External source of truth “Traditional” Event-Driven System Event Store
Message Broker Event Log Event Stream Messaging System Storage System Streaming Platform
How To Manage Shared Data? Kafka Streams Unbounded, ordered sequence of data records Continuously Key-value pair updating
How To Manage Shared Data? Kafka Streams Running in the same process Service of Microservice Loaded on startup of Microservice Kafka Topic Lightweight embedded state store (disk-backed) Streams make data available wherever it’s needed
How To Manage Shared Data? Kafka Streams Kafka Stream-Table Duality Kafka Streams API join filter KStream KTable group by Changelog of state changes Snapshot of the latest value for each key aggregate (key1, value1), (key2, value2), (key 1, value 3) key1 value3 → key2 value2 → etc.
How To Manage Data? Materialized Views w/ Kafka Streams Document Service REST API Stream Materialized View as State Store Stream-Table-Join Kafka Table for enrichment
How To Manage Shared Data? Event Streams as a Shared Source of Truth Event streams as a Events for notification Events for data duplication shared source of truth Eliminating local copy => reduces Simple integration Simple integration Eliminating remote query => ● ● ● ● duplicating effort Remote query => increasing coupling Remote query => increasing coupling better decoupling ● ● Pushes data to where it’s needed Local copy => better autonomy ● ● Increases pluggability Duplicating effort to maintain ● ● Low barrier to entry for new local dataset ● service
Lessons Learned Start small Handle cross-cutting concerns early One manageable step at a time Be aware of affecting circumstances Avoid a distributed monolith Design event-driven & consider & event streams as shared source of truth Each journey is different :)
Susanne Kaiser @suksr CTO at Just Software @JustSocialApps
Recommend
More recommend
