Microservices Lessons Learned Susanne Kaiser Independent Tech - PowerPoint PPT Presentation

Microservices Lessons Learned Susanne Kaiser Independent Tech Consultant @suksr @suksr

Software Delivery Performance Profitability, Productivity & Market Share @suksr

@suksr

@suksr

Challenges Of Microservices @suksr

Background Independent Tech Consultant @suksr Co-Organizer @microXchg, Berlin Susanne Kaiser … who? CTO at Just Software @JustSocialApps Program committee Program committee & Program committee ServerlessDays, Hamburg MicroCPH, Copenhagen track host @ServerlessHAM QCon, New York @MicroCPH @qconnewyork @suksr

Background Motivation for Microservices Autonomous Work at different parts Deploy independently Scale independently Develop independently teams independently At different speed @suksr

Organizational Circumstances Challenges Of Microservices @suksr

Organizational Circumstances Team Structure Skillset Journey Size @suksr

Organizational Circumstances Legacy Maintenance Runtime Team effort environment Structure Skillset Journey Size @suksr

Organizational Circumstances Legacy Maintenance Runtime Team effort environment Structure Skillset Journey Strategy Size New Features Timeline / Milestones @suksr

Manageable Steps Organizational Circumstances Challenges Of Microservices @suksr

Identify Bounded Contexts Loose coupling between services High cohesion within a service @suksr

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 @suksr

Examples for Bounded Contexts Bounded Contexts JUST DRIVE JUST CONNECT JUST LIST JUST PEOPLE JUST NEWS JUST WIKI @suksr

Decomposition Strategy Co-Existing Service From Scratch JUST DRIVE @suksr

Decomposition Strategy Co-Existing Service From Scratch JUST PEOPLE JUST DRIVE @suksr

Decomposition Strategy Co-Existing Service From Scratch REST API JUST DRIVE Application-Service Domain-Model Monolith DB Adapter owns document state @suksr

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 @suksr

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 @suksr

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. @suksr

Start Small Easy to Extract @suksr

Decompose in Steps Monolith Monolith Monolith Monolith Monolith Monolith Incremental Decomposition Bottom-Up Incremental Decomposition Top-Down � - or - � @suksr

Manageable Steps Organizational Cross-Cutting Concerns Circumstances Challenges Of Microservices @suksr

Cross-Cutting Concerns Authorization JUST DRIVE JUST WIKI Inter-service dependency Fine-grained authorization @suksr

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 @suksr

Cross-Cutting Concerns Handle Them Early Feeding the monolith Re-implementing authz w/ every new service Handle Cross-Cutting Concerns Early @suksr

Manageable Steps Organizational Cross-Cutting Concerns Circumstances Challenges Of Microservices Distributed Monolith @suksr

Cross-Cutting Concerns Avoid A Distributed Monolith Authz Service Does a change to one microservice require changes to or deployments of other microservices? @suksr

Cross-Cutting Concerns Avoid A Distributed Monolith conform Authz Service conform One stable conform common contract @suksr

Manageable Steps Organizational Cross-Cutting Concerns Circumstances Challenges Of Microservices Distributed Monolith Service-Interaction, Shared Data & Event-Patterns @suksr

Service Interaction Request-Driven / Event-Driven command query command Message Broker Message Broker Events query Events subscribe publish subscribe publish Request-Driven Hybrid Event-Driven @suksr

How To Manage Shared Data? Hybrid Model Remote query directly to source REST API Message Broker Events for notification @suksr

How To Manage Shared Data? Event Driven State Transfer ProfileUpdatedEvent Message Broker Local copy of profile data Events for data duplication @suksr

How To Manage Shared Data? Source Of Truth Multiple sources of truth Single source of truth Internal source of truth Events as first-class citizens Dual Writes Events as primary data source External source of truth Risk of Inconsistencies Event Log “Traditional” Event-Driven System @suksr

Event Log Persisted Immutable Append-Only Profile Page Doc Page Profile Created Created Uploaded Archived Deactivated Ordered Sequence of Events Event = A fact that has happened in the past @suksr

Event Sourcing Profile Profile Profile State changes modeled as series of events Created Updated Deactivated Events are persisted & appended to the event log Subscriber Services can subscribe to the event log Current state is reconstructed by replaying events Profile State @suksr

Event Sourcing Your Profile Firstname Lastname Event Log Update Client @suksr

Event Sourcing How to derive materialized views? Your Profile Firstname Lastname Event Log Update Client @suksr

Event-Sourcing Materialized Views Query EventHandler Your Profile Read Store Firstname Lastname Update @suksr

Event-Sourcing Materialized Views Query EventHandler Your Profile Read Store Firstname Lastname Update How to update state? @suksr

Event-Sourcing State Changes w/ Commands & Events Query EventHandler Your Profile Read Store Firstname Lastname Update Command Event @suksr

Event-Sourcing State Changes w/ Commands & Events Query EventHandler Your Profile Read Store Firstname Lastname Update Command Event save event Read events of replay events to check invariants generate event profile build internal on internal state & update internal state state @suksr

Event-Sourcing Request data CQRS (read model) Query EventHandler Your Profile Read Store Firstname Lastname Seperate Models Update Command Event Change state (write model) @suksr

Event-Sourcing Request data CQRS (read model) Commands & Queries Query EventHandler Can be scaled independently Your Profile Read Store Can be deployed separately Firstname Read model can be optimized Lastname Seperate Models to make queries fast & efficient Update Might involve more work Command Event due to transforming events to a read model Change state Might have a higher learning (write model) curve @suksr

Event-Sourcing Validation Query EventHandler Registration Read Store Username Password Register Command Event How to preserve business constraints among domain models, e.g. unique usernames? @suksr

Event-Sourcing Validation Query EventHandler Registration Read Store Username Username Password Query Allocated Usernames Register Command Event How to preserve business constraints among domain models, e.g. unique usernames? @suksr

Event-Sourcing Validation: New Read Store & Client-side Query Execution Query EventHandler Registration Read Store Username Username Password Query Allocated Usernames Register Eventual Consistency Malicious Client? Command Event How to preserve business constraints among domain models, e.g. unique usernames? @suksr

Event-Sourcing Validation: New Read Store & Client-side Query Execution Query EventHandler Registration Read Store Username Username Password Query Allocated Usernames Register Eventual Consistency Malicious Client? Command Event Accounts w/ duplicated usernames How to preserve business constraints among domain models, e.g. unique usernames? @suksr

Event-Sourcing Validation: New Read Store & Client-side Query Execution + Saga Pattern Query EventHandler Registration Read Store Username Username Password Query Allocated Usernames Register Eventual Consistency Malicious Client? Command Event Accounts w/ Saga Pattern Compensating Event duplicated usernames corrected by How to preserve business constraints among domain models, e.g. unique usernames? @suksr