agileandmicroservices-160304175555.pdf

8/20/2019 agileandmicroservices-160304175555.pdf

1/75

Microservices:

Architecture for AgileSoftware Development

Eberhard Wolff Fellow, innoQ

@ewolff


2/75


3/75

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


4/75

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

FREE!!!!


5/75

MicroserviceDefinition


6/75

Server Server

Microservices:

Definition> Small

> Independent deployment units

> Separate VM / process

> Any technology

> Any infrastructure

Micro

Service

Micro

Service


7/75

Components Collaborate

Micro

Service

Micro

Service

Link

Data Replication

REST

Messaging


8/75

Microservices

> Component Model

> Component…

> Individual deployment unit

> GUI+Logic?


9/75

Layered

iOS Android Web

Order Search Catalog

BillingCustomer

Backend Backend Backend


10/75

Layered

> Reusable Backend Services

> Mobile client / Web App as frontend

> Backend for frontend (BFF): Custom

backend services

> ...to implement frontend specific logic


11/75

Layered: Issues

> All BFF support the same processes

> BFF contain most relevant logic

> Change to a business process meanschanging many services

> Lots of communication


12/75

Self-contained

Systems

Order Search CatalogBilling

Web Web Web Web


13/75

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


14/75

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

O li Sh


15/75

Online Shop

Order

Catalog

Search

Billing

Customer

HTML /HTTP


16/75

Online Shop

Elasticsearch

Spring Batch

Oracle

Spring MVC

MongoDB

Order

Catalog

Search

Billing


17/75

Agility


18/75

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


19/75

Agile Manifesto:

Individuals andInteractions


20/75

Software Architecture

& Individuals


21/75

Software Architecture

& IndividualsUnrelated?


22/75

Does Your

Architecture TakeIndividuals Into

Account?


23/75

Conway‘s Law

Architecture

copies

communication structures

of the organization


24/75

Conway‘s Law: Impact

Architecture

andcommunication structures

in the organizationare the same thing.

C ’ L


25/75

Conway’s Law as a

Limit> Organization drives architecture

> I.e. GUI, logic & database team

> Three technical artifacts


26/75

E Commerce

Shop

ChangeOrder

Process!

UI

Backend

DB


27/75

time

DBTeam Sprint

BackendTeam Sprint

UITeam Sprint

3 sprints


28/75

Deployment Monolith

Deployment Monolith

Stories

Technical Coordination

Coordinating Releases


29/75

Order SearchBilling

Team for each business feature

Let architecture drive the organization

Order Billing Search

D l t M lith


30/75

Deployment Monolith

+ Conway’s Law

Deployment Monolith

Stories

Technical Coordination

Coordinating Releases

StoriesStories


Mi i


31/75

Microservices +

Conway’s Law> Let architecture drive the organization

> Team for each Microservice

> Team responsible for business features

> Ideal: Independent features


32/75

Order SearchBilling


Team can deploy without integration

Changes can be deployed independently & quickly

Strong & enforced modularization

Technology stack per Microservice

One or many Microservices per Team

Synergy Microservices / Conway’s Law


33/75

Microservices

Microservice

Stories

Technical

Coordination

Microservice

Stories

Technical

Coordination

Microservice

Stories

Technical

Coordination


Release Release Release


34/75

How to scale agile?


35/75

Definearchitecture to

limit

communicationneeds


36/75

One team can build and

deploy featuresindependently!


37/75

Team must be

responsible for asensible set of

functionality


38/75

Less TechnicalCoordination


39/75

Agile Manifesto:Working Software


40/75

Scrum

> PSI

> Potentially shippable increment

> Why?

Principles behind the


41/75

Principles behind the

Agile ManifestoOur highest priority is

to satisfy the customer

through early and

ontinuous delivery

of valuable software.

ll


42/75

Potentially

ShippableIncrement

Continuous

Delivery


43/75

Monolith

ECommerce

System

3rd party

systems

Database

Continuous Delivery:


44/75

Continuous Delivery:Build Pipeline

ECommerceSystem

CommitStage

AutomatedAcceptanceTesting

AutomatedCapacityTesting

ManualExplorativeTesting

Release

Build Pipeline:


45/75

Build Pipeline:

Complex Infrastructure

> Huge database

> 3rd party integration

Build Pipeline:


46/75

Build Pipeline:

Slow Feedback> Slow feedback

> Test everything for each commit

> Huge deployment unit

> Deployment slow

Monolith:


47/75

Monolith:

Deployment> Huge deployment

> Risky

> Hard to mitigate risk

> Blue / Green: Create a separate

environment> Canary: Deploy to one server first


48/75

Microservices

ECommerce

System

3rd party

systems

Database


49/75

Microservices

3rd party

systems

Database

Order

Catalog

Billing

Search


50/75

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 for


51/75

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:


52/75

Microservice:

Deployment> Small deployment

> Less risky

> Other Microservices resilient to failingmicroservice

> Easy to create new environments> E.g. for Blue / Green or Canary

Q i k D l


53/75

Quick DeploymentsTime

Size & Risk

Manual

DeploymentPipeline

ContinuousDeliveryPipeline

MonolithMicroservices


54/75

Potentially shippableincrement?


55/75

SHIP!!!


56/75

Agile Manifesto:

CustomerCollaboration


57/75

Customer

Collaboration &Architecture?

Microservices &


58/75

Microservices &

Departments

StoriesStories Stories

Customer Billing Order

Process

Product

Owner

Product

Owner

Product

Owner

Department Department Department

Microservices &


59/75

Microservices &

Departments> Ideal: One team per department

> Ideal: Change local to one team /Microservice

> Otherwise: Coordination needed


60/75

Customer should ownMicroservice


61/75

Agile Manifesto:Responding to change


62/75

Monoliths

> Architecture rot

> …not maintainable any more

> …and can’t be rewritten / replaced


63/75

Deployment Monolith

> Cyclic dependency

> …because the IDE suggested some class

> Might not even be noticed

Module

Class

Module

Class

Class Class


64/75

Microservices

> Need to use the API

> Different team

> More effort - will think about it

> Rot less likely

Microservice

Class

Microservice

Class

Class Class


65/75

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


66/75

Microservices

> Small

> Easy to change

> Architectural problems in Microservice unlikely

> Can be replaced

Microservice

Class

Class

Microservices


67/75

Microservices– Easy to Recycle


68/75

Conclusion

Conclusion:


69/75

Conclusion:Microservices & Agility

> Individuals over tools

> Architecture drives organization

> Scale by architecture not process

> Working software

> Actually ship software

> Continuous Delivery

Conclusion:


70/75


> Customer collaboration

> Customer should own services

> i.e. organization beyond the project =

architecture

Conclusion:


71/75


> Responding to change

> Individual Microservices small

> Easy to change> …and replace

> Unwanted dependencies won’t sneak in

> But: Global refactoring hard, too


72/75

Meta-Conclusion

How To Think About


73/75

How To Think AboutArchitecture

> Process has an impact on architecture

> Software architecture & organization are thesame

> Build recyclable software!

Microservice > Agile


74/75

Microservice > AgileAchitecture

Strong Modularization

Scaled Agile Architecture

Sustainable development

speed Replaceable Services

Continuous Delivery

Choose best technology

for job!

Handle Legacy more efficient

Independent Scaling

Robustness

Th k Y !


75/75

Thank You!

@ewolff

https://github.com/ewolff/microservicehttps://leanpub.com/microservices-primer

http://microservices-buch.de/

http://scs-architecture.org

agileandmicroservices-160304175555.pdf

Documents

Transcript of agileandmicroservices-160304175555.pdf