Alex Thissen (Xpirit) - Een verschuiving in architectuur: op weg naar microservices

Post on 08-Jan-2017

1.329 views 1 download

Transcript of Alex Thissen (Xpirit) - Een verschuiving in architectuur: op weg naar microservices

Microservices – a shift in modern application

architectureMicroservices with Microsoft

Alex Thissen

Agenda• Struggle of modern applications and architectures• Introducing Microservices architecture• Moving away from monoliths• Change in architecture• Complexity for simplicity• Characteristics of a Microservices architecture• Designing and hosting Microservices

Where is MSA in hype cycle?

Current forcesWhat’s next in modern application architectures?

Valued business drivers

Better• Resilient• Technology choice

Cheaper• Test effort• Cost of

maintaining

Faster• Change• Deployment• Execution

About monoliths

SOA and Continuous delivery

Trends in software development

Platform as a Service

Autonomous teams

Continous Delivery

Agile Organization

Reactive Manifesto

Modern application architecture requirements• Mobile first• Low bandwidth resilient• Resilient to failure• Highly scalable• 24x7x365• High frequency of feature delivery

Scalable

Agile

Available (24x7)

Efficient

Microservices Architecture (MSA)Latest trends in architecture

Objectives: Scalability, Agility, Availability, Efficiency

The many definitions of microservices- Small and focused on doing one thing well- Autonomous

“Loosely coupled service oriented architecture with bounded contexts”Adrian Cockcroft (Netflix)

“SOA done right”Anonymous

“… services are independently deployable and scalable, each service also provides a firm module boundary, even allowing for different services to be written in different programming languages.”Martin Fowler (Thoughtworks)

Size matters (not)• It’s not about lines of code used• Small enough to• Be handled by a single team• Not feel “big”

Services as a network of independent parts

Microservices architecture

Every service is independent• Can have its own technology stack• Maintains its own state• Is delivered independent of other parts of the system• Everything is highly automated• Each Microservice has its own team• Both delivery and operations are their responsibility (DevOps)

Relation between number of services and complexity

Effect of complexity on system qualities

Chosen strategyObtain simplicity by adding complexity

Benefits

Heter

oge

ne

ou

s tec

hno

lo

gy lan

dsca

pe

Microservices Architecture characteristics• Organized around business capabilities• Products not Projects • Decentralized data management• Decentralized governance • Componentization via Services • Design for Failure• Infrastructure automation• Evolutionary Design

Source: http://martinfowler.com/articles/microservices.html

• Organized by logical cohesion• Teams own layers spanning domains• Unified technology choice

From horizontal to verticalChange your approach to vertical partitions

• Modeled after organization’s domains • Owned by team• Top to bottom• Isolated from each other as much as possible

Achieving your goalsApply Microservices’ principles and practices:• Low coupling and high cohesion• Asynchronous over synchronous• Choreography over orchestration

Low coupling

Components are completely insensitive to changes and errors in other components.

No Couplin

g

Error and changes seldom propagate errors and changes to dependent components

Low Couplin

g

Errors and changes in one component almost always propagate to other components

High Couplin

g

Measurement of dependency between two componentsExpressed as sensitivity towards propagation of changes and errors

High cohesionDegree to which parts of a module belong together

Levels:Coincidental cohesion (worst)•

random

Logical cohesion• same

in nature

Temporal cohesion•

executed at a particular time

Procedural cohesion• part of

fixed execution sequence

Informational cohesion•

operating on the same data

Sequential cohesion• Output

of one is used as input by another

Functional cohesion (best)•

contributing to a single task

Hands-onDesign your own Microservices

How to find autonomous systems?• Grouping all synergistic business functions together into

one system • aka Autonomous Business Capability (ABC)

“Two business functions A, B are synergistic if and only if, from the business perspective, A is not useful without B and B is not useful without A.”

• Functions without synergy go into different systems

Example – Home Finance System

Deposit Funds

SetupPaymentReminder

CreateNewBudget

CancelPaymentReminder

WithdrawFunds

WriteCheck

AddExpense

ListExpense

Source: Roger Session’s – Simple Architecture for Complex Enterprises

Deposit Funds

SetupPaymentReminder

CreateNewBudget

WithdrawFundsCancelPaymentReminder

WriteCheck

AddExpense

ListExpense

Source: Roger Session’s – Simple Architecture for Complex Enterprises

Applying synergistic partitioning to Home Finance System

Frontend integration

Freedom of choice

Social ProductReport

Graph DocumentBlob

Bounded contexts

Which Service owns this page?

None!

Composition is key!

Example: otto.de

Example Microservices architecture - otto.de

• 11 verticals• Autonomous

teams around a component

• Independently deployable

• Own data storage

Source: http://ottodev.files.wordpress.com/2013/11/teile-und-herrsche-kleine-systeme-fc3bcr-groc39fe-architekturen.pdf

Example Microservices architecture - otto.de• Each with own UI (on website)• Well defined interfaces• No shared code or state• REST interfaces for each vertical• Pull based data replication• Front end integration

(JavaScript/Edge Side Includes)

How to implement inter-system dependencies?

Event Driven Architecture• Systems keep their own state• Events are used to notify changes• Systems use events to replicate data• Each service will have its own database

• Downsides:• Latency in data changes• No central control of business logic• Challenge to reconcile in case of disaster

Why are event driven architectures relevant?• Increased use of asynchronous notifications• Mobile push based notifications, Twitter, Whatsapp, et cetera

• Increased application of asynchronous languages and frameworks• Javascript, node.js, AJAX, C# async and await, Signal R

• Increased need for fast, robust and scalable systems• Reactive Manifesto

• Increased need for systems agility• Faster, more frequent changes

Cross-service coupling• Smart endpoints, dumb pipes• No intelligent middleware• Technologies to look at:• Queues (Azure, MSMQ, WebSphereMQ , ...)• Service Bus (NServiceBus, Azure ServiceBus, Azure

EventHub, ...)• Language neutral data serialization

(Google Protocol buffers, Apache Thrift, AMQP)

Designed for failure• Services can and will fail:

prepare!• Do not rely on another

service’s availability• Introduce features in your app

to deal with it• Test under stress and

with failing services

Circuit Breaker Pattern Handle faults that may take a variable amount of time to rectify when connecting to a

• remote service or resource. • This pattern can improve

the stability and resiliency of an application.

Circuit Breaker Pattern • Fails immediately after

a number of (slow) failures• Careful rampup after

cool-down period• Works together with

Retry Pattern

Retry Pattern Enable an application to handle temporary failures when connecting to a service or network resource by transparently retrying the operation in the expectation that the failure is transient. This pattern can improve the stability of the application.

Command and Query Responsibility Segregation• Traditional CRUD • Mismatch between read and write representations• Contention of database

• Solution: Segregate operations for reading and writing

• CRUD approach:• Updates directly against

datastore• No recorded history

Solution: Handle operations on data by events which are recorded in append-only database

Event sourcing

Hosting Microservices

Services up and running

OS

Virtual machines

PaaS

Container runtimes

Hosting your services

Host

Application container

MicroService

MicroService

Host

MicroService

MicroService

MicroService

MicroService

Host

MicroService

Host

MicroService

Host

MicroService

Host

MicroService

Hosting in application container

High density hosting

One service per host

AppA

Virtual Machines and Containers

Hypervisor (Type 2)

Host OS

Server

GuestOS

Bins/Libs

AppA’

GuestOS

Bins/Libs

AppB

GuestOS

Bins/Libs

App A’

Host OS

Server

Bins/Libs

App ABins/Libs

App B

App B’

App B’

App B’VM

Container

Containers are isolated,but share OS kernel and, where appropriate, bins/libraries

GuestOS

GuestOS

…result is significantly faster deployment, much less overhead, easier migration, faster restart

Problems and solutions• Rolling upgrades• Availability guarantees• Scale out architecture• Resource governance• Density• Packaging and deployment• Policy enforcement• Granular versioning• Stateful workloads• Leader election

MesosKubernetesZookeeperRedisRavenMongoDBYarnFleetHadoopContainers

Hybrid

Public Cloud Hosted CloudsPrivate cloud

LifecycleMgmt

Independent Scaling

Independent Updates

Always OnAvailability

ResourceEfficient Stateful

Microservice-based applications

The Microservice premiumIs a Microservice architecture a good choice for the system you're working on?

Source: http://martinfowler.com/articles/microservices.html

It depends!

Summary• Microservices is the new hot thing• Still maturing, lot to be learned and

discovered• Might not be for everybody• Think of a strategy to implement

your Microservices• Migrate gradually• Evaluate specialized hosting

platforms and frameworks and technologies

http://www.xpirit.com

Leading IT specialists in Microsoft Application Lifecycle Management,

Cloud, Enterprise Mobility & Security style