beyond microservices

Beyond MicroservicesEberhard Wolff

@ewolffhttp://ewolff.com

Fellow

http://continuous-delivery-buch.de/ http://continuous-delivery-book.com/

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

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

http://microservices-buch.de/ueberblick.html

FREE!!!!

What are Microservices?

Modules ProcessesIndependent Continuous

Delivery Pipeline

Standardized Operations

Resilience

Microservices

Why Microservices?

!

Technological Benefits

"

Decoupling

> Originally: Changing a module does not influence other modules.

> i.e. independent development

Microservice Decoupling

> Independent scaling

> Independent technical decisions

> Decoupled crashes

> Security: firewalls etc

Clean Architecture

Developer

REST REST

ECommerceSystem

Order

Catalog

BillingSearch

ECommerceSystem

Catalog

BillingSearch

ECommerceSystem

Order

Catalog

BillingSearch

Replace if messed up.

Replaceability

> Small components hard to mess up

> Each module can be replaced

> …small green field project

> ...different technology stack possible

Continuous Delivery

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!




Release!

Commit!Stage!




Release!

Build Pipeline forMicroservices

> Build pipeline per Microservice

> Smaller

> Easier to set up

> Less features (3rd party systems)

> Faster Feedback: Less tests

Decoupled Development

Decoupled Scalability

Decoupled Technical decisions

Decoupled Crashes

SecurityArchitecture

Firewalls

ReplaceabilityContinuous

Delivery


Organizational Benefits

"

Deployment Monolith

Stories

Technical Coordination

Coordinating Releases

Microservice

Stories

TechnicalCoordination

Stories


Stories


Order Billing Search

Release Release Release

Inverse Conway Maneuver

> Architecture drives organization

> Cross-functional team (database, logic, UI)

> Team responsible for Bounded Context(s)

Take one huge project and make it several

small projects…

Self-organization

> With so much independence…

> ...teams can decide for themselves.

> Self-organization


Independent Technologies

Independent Bounded Contexts

Self-organization


Microservices: Challenges

#

Consistency

Order

Invoice

Delivery

What aboutorder #42?

✅

✅

❌

Consistency

Order

Invoice

Delivery

Order #42is cancelled!

✅

✅

⁉Goods might be delivered

if order arrivesafter cancellation.

This is quite common without

microservices.

Customer Order Catalog

Domino Effect

Build resilient microservices!

Refactorings

> Move code to a new service: Easy

> Move code from service to service

> Might be a port to a different language

> Hard

Global Refactorings

> Really hard: Global restructuring

> i.e. moving everything to a different place.

> …but that is always hard…

> ...and the result of a major screwup.

> Do you want to optimize for this?

Many New Technologies

> Microservices framework

> Service discovery

> Routing / API Gateway

> Continuous Delivery pipeline

> Docker

> Docker scheduler (Kubernetes)

> ....

Challenges

Consistency Fail safeness

Large scale refactoring

New Technologies

Microservices are an all or nothing

approach.

Which benefits are important?

Which challenges acceptable?

Moving beyond Microservices:Rightsize the achitecture!

Alternative Approaches

Centralized DB

Billing OrderProcess CRM

OrderOrder Order

True Microservices

Shared Database

Order Schema

Billing OrderProcess CRM

Modules--

Processes++

Independent Continuous

Delivery Pipeline+


-

Resilience-

Shared Database: Microservices


--


+


+

Decoupled Crashes

+

Security-

Architecture Firewalls

-

Replaceability--

Continuous Delivery

-



-


+


--

Self-organization-


Challenges

Consistency++

Fail safeness-


-

New Technologies

-

-

Centralized Database is a bad idea.

Layered

Layered

iOS Android Web

Order Product Delivery

InvoiceCustomer

Layered: Issues

> Changing a business process cause many changes

> …in Frontend and many backend

> Lots of communication between teams and components

Modules

++

Processes

++


Delivery Pipeline

++


++

Resilience

+

Microservices


-


-


++

Decoupled Crashes+

Security+


+

Replaceability+

Continuous Delivery-



--


++


--

Self-organization

--


Challenges

Consistency

+

Performance

--

Fail safeness

--


--

New Technologies

--

Layered:More challenges,

less benefits,same effort

Bounded ContextMicrolith

SCS

Order

Shipping addressTracking #ItemsItem CategoriesPriority shippingCustoms #Account #

...Credit card #

Order #

My Domain Model is a mess!

Bounded Context

> Domain model is only valid for one context

> There is no universal data model!

> See all failed SOA attempts

Order

Shipping addressTracking #ItemsItem CategoriesPriority shippingCustoms #Account #

...Credit card #

Order #

Customs

Order

Recommen-dations

Order

Tracking

Order

ShippingaddressTracking #

ItemCategories

Priorityshipping

Customs #

Payment

Order

Account #Credit card #

Self-contained Systems

Search Invoice LogisticsCheckout

Web Web Web Web

See http://scs-architecture.org

Modules

++

Processes

++


Delivery Pipeline

++


++

Resilience

+

Microservices


++


++


++

Decoupled Crashes

++

Security

++


+

Replaceability

+

Continuous Delivery

++



++


++


++

Self-organization++


Challenges

Consistency

+Performance

++Fail safeness

++


+

New Technologies

+

Microservices as they should be.

Modules withMaven

Architecture ManagementOSGiWAR

Build order /Architecturemanagement

Build order /Architecturemanagement

Modules+

Processes--


Delivery Pipeline-


++

Resilience-

Microservices


+


--


--

Decoupled Crashes--

Security--


++

Replaceability+

Continuous Delivery+



+


--


++

Self-organization-


Challenges

Consistency-

Performance++

Fail safeness-


++

New Technologies

++

Clean architecturewith a lot less

technical challenges!

Conclusion

Conclusion

> Microservices are a set of architecture decision

> Architecture is about trade-offs

> Architecture is different for each project

> Go beyond microservices by picking the best decisions!

> …and gain most benefits

Usually bad tradeoffs

> Centralized database

> Layered model

Usually good tradeoffs

> SCS, Bounded Context, Microlith

> Strongly separated modules

beyond microservices

Software