Microservices:

Architecture for Agile

Software Development
Eberhard Wolff
Fellow, innoQ
@ewolff

http://microservices-buch.de/

http://microservices-book.com/

FREE!!!!
http://microservices-book.com/primer.html

Microservice
Definition

Microservices:
Definition
> Small
> Independent deployment units
> Separate VM / process
> Any technology
> Any infrastructure

Micro
Service

Micro
Service

Server

Server

Components Collaborate
Link
Micro
Service

REST

Micro
Service

Messaging
Data Replication

Microservices
> Component Model
> Component
> Individual deployment unit
> GUI+Logic?

Layered
iOS
Backend

Android
Backend

Web
Backend

Order

Search

Catalog

Customer

Billing

Layered
> Reusable Backend Services
> Mobile client / Web App as frontend
> Backend for frontend (BFF): Custom
backend services
> ...to implement frontend specific logic

Layered: Issues
> All BFF support the same processes
> BFF contain most relevant logic
> Change to a business process means
changing many services
> Lots of communication

Self-contained
Systems
Web

Web

Web

Web

Order

Billing

Search

Catalog

Self-contained
Systems (SCS)
> SCS: Autonomous web application
> Optional service API (e.g. for mobile clients)
> Includes data & logic
> Might contain several microservices
> No shared UI
> No shared business code
> E.g. Otto, Kaufhof ...

SCS: Benefits
> Business logic for one domain in one SCS
> Change usually local to one SCS
> Less communication between SCS
> I think this should be the goal
> http://scs-architecture.org

Online Shop

Customer

HTML /
HTTP

Order

Billing

Catalog
Search

Online Shop
Order
Billing
Spring Batch
Oracle

Catalog
Spring MVC
MongoDB
Elasticsearch
Search

Agility

Agile Manifesto
> Individuals and Interaction
> Over processes and tools

> Working Software

> Over comprehensive documentation

> Customer Collaboration

> Over contract negotation

> Responding to change

> Over following a plan

Agile Manifesto:
Individuals and
Interactions

Software Architecture
& Individuals

Software Architecture
& Individuals
Unrelated?

Does Your
Architecture Take
Individuals Into
Account?

Conways Law
Architecture
copies
communication structures
of the organization

Conways Law: Impact

Architecture
and
communication structures
in the organization
are the same thing.

Conways Law as a
Limit
> Organization drives architecture
> I.e. GUI, logic & database team
> Three technical artifacts

UI
Change
Order
Process!

Backend

DB

E Commerce
Shop

3 sprints
DB
Team Sprint
Backend
Team Sprint
UI
Team Sprint
time

Deployment Monolith
Stories

Deployment Monolith

Technical Coordination
Coordinating Releases

Order

Billing

Search

Order

Billing

Search

Let architecture drive the organization

Team for each business feature

Deployment Monolith
+ Conways Law
Stories

Stories

Stories

Order
Search
Billing
Deployment Monolith
Technical Coordination
Coordinating Releases

Microservices +
Conways Law
> Let architecture drive the organization
> Team for each Microservice
> Team responsible for business features
> Ideal: Independent features

Order

Billing

Search

Order

Billing

Search

Synergy Microservices / Conways Law

One or many Microservices per Team
Technology stack per Microservice
Team can deploy without integration
Changes can be deployed independently & quickly
Strong & enforced modularization

Microservices
Order

Billing

Search

Stories

Stories

Stories

Microservice

Microservice

Microservice

Technical
Coordination
Release

Technical
Coordination
Release

Technical
Coordination
Release

How to scale agile?

Define
architecture to
limit
communication
needs

One team can build and

deploy features
independently!

Team must be
responsible for a
sensible set of
functionality

Less Technical
Coordination

Agile Manifesto:
Working Software

Scrum
> PSI
> Potentially shippable increment
> Why?

Principles behind the

Agile Manifesto
Our highest priority is
to satisfy the customer
through early and
continuous delivery
of valuable software.

Potentially
Shippable
Increment
Continuous
Delivery

Monolith
ECommerce
System

Database

3rd party
systems

Continuous Delivery:
Build Pipeline

ECommerce
System
Commit
Stage

Manual
Automated Automated
Acceptance Capacity Explorative
Testing
Testing
Testing

Release

Build Pipeline:
Complex Infrastructure
> Huge database
> 3rd party integration

Build Pipeline:
Slow Feedback
> Slow feedback
> Test everything for each commit
> Huge deployment unit
> Deployment slow

Monolith:
Deployment
> Huge deployment
> Risky
> Hard to mitigate risk
> Blue / Green: Create a separate
environment
> Canary: Deploy to one server first

Microservices
ECommerce
System

Database

3rd party
systems

Microservices
Order
Billing
Search
Catalog
Database

3rd party
systems

Order

Commit!
Stage!

Automated! Automated! Manual!

Acceptance! Capacity! Explorative!
Testing!
Testing!
Testing!

Release!

Billing

Commit!
Stage!

Automated! Automated! Manual!

Acceptance! Capacity! Explorative!
Testing!
Testing!
Testing!

Release!

Customer

Commit!
Stage!

Automated! Automated! Manual!

Acceptance! Capacity! Explorative!
Testing!
Testing!
Testing!

Release!

Build Pipeline for

Microservices
> Independent deployment

> Build pipeline per Microservice

> Small
> Easier to set up
> Less features (3rd party systems)
> Faster Feedback: Less tests

Microservice:
Deployment
> Small deployment
> Less risky
> Other Microservices resilient to failing
microservice
> Easy to create new environments
> E.g. for Blue / Green or Canary

Time

Quick Deployments

Manual
Deployment
Pipeline

Continuous
Delivery
Pipeline

Microservices
Size & Risk

Monolith

Potentially shippable
increment?

SHIP!!!

Agile Manifesto:
Customer
Collaboration

Customer
Collaboration &
Architecture?

Microservices &
Departments
Customer

Billing

Order
Process

Department

Department

Department

Product
Owner
Stories

Product
Owner
Stories

Product
Owner
Stories

Microservices &
Departments
> Ideal: One team per department
> Ideal: Change local to one team /
Microservice
> Otherwise: Coordination needed

Customer should own

Microservice

Agile Manifesto:
Responding to change

Monoliths
> Architecture rot
> not maintainable any more
> and cant be rewritten / replaced

Deployment Monolith
Class

Class

Class

Class

Module

Module

> Cyclic dependency

> because the IDE suggested some class
> Might not even be noticed

Microservices
Class

Class

Class

Class

Microservice

Microservice

> Need to use the API

> Different team
> More effort - will think about it
> Rot less likely

Global Refactorings?
> Move code from service to service
> Might be a port to a different language
> Separate in a new service
> Harder than in a Deployment Monolith

Microservices
Class
Class
Microservice

> Small
> Easy to change
> Architectural problems in Microservice unlikely
> Can be replaced

Microservices
Easy to Recycle

Conclusion

Conclusion:
Microservices & Agility
> Individuals over tools

> Architecture drives organization

> Scale by architecture not process
> Working software
> Actually ship software
> Continuous Delivery

Conclusion:
Microservices & Agility
> Customer collaboration
> Customer should own services
> i.e. organization beyond the project =
architecture

Conclusion:
Microservices & Agility
> Responding to change

> Individual Microservices small

> Easy to change
> and replace
> Unwanted dependencies wont sneak in
> But: Global refactoring hard, too

Meta-Conclusion

How To Think About

Architecture
> Process has an impact on architecture
> Software architecture & organization are the
same
> Build recyclable software!

Microservice > Agile

Achitecture
Scaled Agile Architecture
Handle Legacy more efficient
Sustainable development
speed
Robustness
Continuous Delivery
Independent Scaling
Choose best technology
for job!

Strong Modularization
Replaceable Services

Thank You!
@ewolff
https://github.com/ewolff/microservice
https://leanpub.com/microservices-primer
http://microservices-buch.de/
http://scs-architecture.org