Microservices: Architecture to Support Agile

Microservices: Architecture for Agile

Software DevelopmentEberhard WolffFellow, innoQ

@ewolff

http://microservices-buch.de/ http://microservices-book.com/

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

FREE!!!!

Microservice Definition

Server Server

Microservices: Definition

> Small

> Independent deployment units

> Separate VM / process

> Any technology

> Any infrastructure

MicroService

MicroService

Components Collaborate

MicroService

MicroService

Link

Data Replication

REST

Messaging

Microservices

> Component Model

> Component…

> Individual deployment unit

> GUI+Logic?

Layered

iOS Android Web

Order Search Catalog

BillingCustomer

Backend Backend Backend

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

Order Search CatalogBilling

Web Web Web Web

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

Order

Catalog

Search

Billing

Customer

HTML /HTTP

Online Shop

Elasticsearch

Spring BatchOracle

Spring MVCMongoDB

Order

Catalog

Search

Billing

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?

Conway‘s Law

Architecture

copies

communication structures

of the organization

Conway‘s Law: ImpactArchitecture

and

communication structures

in the organization

are the same thing.

Conway’s Law as a Limit

> Organization drives architecture

> I.e. GUI, logic & database team

> Three technical artifacts

E CommerceShop

Change Order

Process!

UI

Backend

DB

time

DBTeam Sprint

BackendTeam Sprint

UITeam Sprint

3 sprints

Deployment Monolith

Deployment Monolith

Stories

Technical Coordination

Coordinating Releases

Order SearchBilling

Team for each business feature

Let architecture drive the organization

Order Billing Search

Deployment Monolith + Conway’s Law

Deployment Monolith

Stories

Technical Coordination

Coordinating Releases

StoriesStories

Order Billing Search

Microservices +Conway’s Law

> Let architecture drive the organization

> Team for each Microservice

> Team responsible for business features

> Ideal: Independent features

Order SearchBilling

Order Billing Search

Team can deploy without integrationChanges can be deployed independently & quickly

Strong & enforced modularization

Technology stack per MicroserviceOne or many Microservices per Team

Synergy Microservices / Conway’s Law

Microservices

Microservice

Stories

TechnicalCoordination

Microservice

Stories

TechnicalCoordination

Microservice

Stories

TechnicalCoordination

Order Billing Search

Release Release 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

ECommerceSystem

3rd partysystems

Database

Continuous Delivery:Build Pipeline

ECommerceSystem

CommitStage

AutomatedAcceptance

Testing

AutomatedCapacityTesting

ManualExplorative

TestingRelease

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

ECommerceSystem

3rd partysystems

Database

Microservices

3rd partysystems

Database

Order

Catalog

Billing

Search

Order

Billing

Customer

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Commit!Stage!

Automated!Acceptance!Testing!

Automated!Capacity!Testing!

Manual!Explorative!Testing!

Release!

Build Pipeline forMicroservices

> 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

Quick DeploymentsTime

Size & Risk

Manual Deployment

Pipeline

Continuous Delivery Pipeline

MonolithMicroservices

Potentially shippable increment?

SHIP!!!

Agile Manifesto:Customer

Collaboration

Customer Collaboration &

Architecture?

Microservices & Departments

StoriesStories Stories

Customer Billing OrderProcess

ProductOwner

ProductOwner

ProductOwner

Department Department Department

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 can’t be rewritten / replaced

Deployment Monolith

> Cyclic dependency

> …because the IDE suggested some class

> Might not even be noticed

Module

Class

Module

Class

Class Class

Microservices

> Need to use the API

> Different team

> More effort - will think about it

> Rot less likely

Microservice

Class

Microservice

Class

Class Class

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

> Small

> Easy to change

> Architectural problems in Microservice unlikely

> Can be replaced

Microservice

Class

Class

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 won’t 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

Strong Modularization

Scaled Agile Architecture

Sustainable development speed Replaceable Services

Continuous Delivery

Choose best technology for job!

Handle Legacy more efficient

Independent Scaling

Robustness

Thank You!

@ewolff

https://github.com/ewolff/microservice

https://leanpub.com/microservices-primer

http://microservices-buch.de/

http://scs-architecture.org