self-contained systems: a different approach to microservices

Self-contained Systems: A Different

Approach to Microservices

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

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

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

FREE!!!!

Microservice Definition

Server Server

Microservices: Definition

> Independent deployment units

> Any technology

> Any infrastructure

> UI + Logic

MicroService

MicroService

Components Collaborate

MicroService

MicroService

Link

Data Replication

REST

Messaging

Distributed System

Distributed SystemWhy??

Why Microservices?

Strong Modularization

Scaling Agile

Sustainable development Replaceable ServicesContinuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Small teams develop and deploy independently

Add services – not code

Small Services

Failure limited to single Microservice

Why Microservices?Scaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

Single DeveloperScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

Replace MonolithScaling Agile

Sustainable development

Continuous Delivery

Free choice of technology

Handle Legacy efficient

Independent Scaling

Robustness

Organization

DeploymentUnits

Technology

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

> E.g. Netflix

Layered: Benefits

> Good way to build an API

> E.g. for mobile

> Might be easier to migrate into

> …if existing architecture is similar

Layered: Issues> BFF might contain the same logic –

same processes

> Processes are the most relevant logic

> Changing a business process cause changes in many services – BFF, Frontend, backend

> Lots of communication between teams and components

Self-contained Systems

Checkout Search BrowsingInvoicing

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, Kühne + Nagel ...

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

Self-Contained System (SCS)

Deploymentmonolith

Graphics by Roman Stranghöhner, innoQhttp://scs-architecture.org

Various Domains

User interfaceBusiness logicPersistence

… a lot of modules, components, frameworks and libraries

With all these layers in one place, a monolith tends to grow.

Cut Deploymentmonolith along domains …

… wrap domain in separate web application …

Self-contained System (SCS) –individuallydeployable

Decentralized unit communicating with other systems via RESTful HTTP or lightweight messaging.

SCS can be individually developed for different platforms.

An SCS contains its own user interface, specific business logic and separate data storage

Web user interface composed according to ROCA principles.

http://roca-style.org

optional API e.g. formobile

Logic only shared over a well defined interface.

Business logic can consist of microservices

Every SCS brings its own data storagewith ist own(potentiallyredundant) data

Redundancies:tolerable as long as sovereignty of databy owning system is not undermined.

Enables polyglot persistence

Neo4JCouchDB

Oracle

Technical decisions can be made independently from other systems(programming language, frameworks, tooling, platform)

Domain scope enables development, operation and maintenance of SCS by a single team.Team 1

Team 2 Team 3

Self-contained Systemsshould be integrated in the web interface

Hyperlinks to navigate between systems.

System 1 System 2

System 1 System 2

Redirection

> Use of callback URIs

> As seen e.g. in OAuth flows

Server-side integration

> Centralized aggregation

> Bottleneck (runtime/development time)

Browser

UI 1

UI 2

FrontendServer

Backend 1

Backend 2

https://github.com/ewolff/SCS-ESI

Client-side integration

> Proprietary integration

> Client requirements (e.g. CORS, JS)

> Upcoming: HMTL Imports

Browser

UI 1

UI 2

Backend 1

Backend 2

Client-side Integration: Code

$("a.embeddable").each(function(i, link) {

$("<div />").load(link.href, function(data, status, xhr) {

$(link).replaceWith(this);

});

});

> Replace <a href= " " class= "embeddable"> with content of document in a <div> (jQuery)

https://github.com/ewolff/SCS-jQuery

Synchronous remote calls inside the business logic should be avoided.

Asynchronous Remote calls reduce dependencies and prevent error cascades.

Data model’s consistency guarantees are relaxed.

An integrated system of systemslike this has many

benefits.

Resilience is improved through loosely

coupled, replaceable systems.

SCSs can be individually

scaled to serve varying demands.

No risky big bang to migrate an outdated, monolithic system into

a system of systems.

Version 1Version 2

Migration in small, manageable steps which minimize risk of failure and lead to

an evolutionary modernizationof big and complex systems.

1 *MicroserviceSCS

Conclusion

> SCS: autonomouos web application

> Might consist of Microservices

> Focus on UI Integration

> Almost completet independence

> Coarse-grained architecture approach

Conclusion

> Self-contained systems are Microservices …

> that are not “micro”…

> and don’t have to be “services”

> Many are doing it already!

> http://scs-architecture.org

> Creative commons

> Source on Github

> Slidedeck