No title

Web-scale IT https://www.flickr.com/photos/beraldoleal/8681750288

Even voorstellen… Edwin van Wijk – Sinds 1999 in de IT – Software Architect bij Info Support Passie voor software architectuur, het bouwen van schaalbare gedistribueerde systemen en cloud computing (Azure) 12 juni 2015

Software Development 2020 - Web-scale Architecture

2

Agenda 2

1

Web-scale Architectuur

Uitdagingen in IT

WrapUp

4 Microservices Isolation CQRS Eventual Consistency

12 juni 2015

3

Q&A


3

De uitdagingen van IT https://www.flickr.com/photos/snikologiannis/9365566544

IT Uitdagingen - Business Systemen zijn niet flexibel genoeg – Introduceren van nieuwe producten / processen is complex en duurt lang – Wijzigingen raken vaak meerdere (alle) systemen

“De winkel” moet open blijven – Een dag uit de lucht voor een upgrade kan niet meer 12 juni 2015


5

IT Uitdagingen - Technisch Systemen gebaseerd op SOA – Loosely coupled opgezet maar toch afhankelijkheden tussen services @ runtime – Organisatie breed datamodel is moeilijk te bereiken en vergt veel onderhoud

CRUD (data georiënteerd) vs. Taak georiënteerd werken – Datamodel geoptimaliseerd voor updates – Veel mapping code 12 juni 2015


6

Hoe moeten we veranderen?

https://www.flickr.com/photos/andrewbasterfield/5895030880/

Hoe moeten we veranderen? Web-scale Architecture Supports

12 juni 2015


8

Web-scale Architecture https://www.flickr.com/photos/beraldoleal/8681750288

Web-scale Architecture Wat is “Web-scale”? In a research note that was published yesterday, Gartner introduced the term “web-scale IT.” What is web-scale IT? It’s our effort to describe all of the things happening at large cloud services firms such as Google, Amazon, Rackspace, Netflix, Facebook, etc., that enables them to achieve extreme levels of service delivery as compared to many of their enterprise counterparts. In addition, while the term “scale” usually refers to size, we’re not suggesting that only large enterprises can benefit. Another scale “attribute” is speed and so we’re stating that even smaller firms (or departments within larger IT organizations) can still find benefit to a web-scale IT approach. Agility has no size correlation so even more modestly-sized organizations can achieve some of the capabilities of an Amazon, etc., provided that they are willing to question conventional wisdom where needed. Bron: http://blogs.gartner.com/cameron_haight/2013/05/16/enter-web-scale-it/ 12 juni 2015


10

Web-scale architecture WSA is een groot onderwerp! Omvat zeer veel architectuur- / design-patterns

In deze presentatie wordt slechts een selectie van deze patterns besproken Aan het eind nog een lijst met nuttige boeken om te lezen voor meer informatie 12 juni 2015


11

Disclaimer! Wat ik vandaag vertel is niet in alle situaties toepasbaar Web-scale architectuur is complexer dan traditionele architectuurstijlen – Complexer == duurder?? – Ervaring / skills van het team zijn belangrijk

100% web-scale is niet nodig om voordeel te behalen 12 juni 2015


12

Disclaimer!

KISS, gezond boeren verstand en vakmanschap blijven de beste tools Kies de beste oplossing en architectuur stijl gebaseerd op complexiteit en risico’s – Zie ook de “Monolith vs. Microservices” discussie (Martin Fowler)

Elke beslissing is een trade-off 12 juni 2015


13

Een web-scale architecture draagt bij aan de schaalbaarheid, goede performance en hoge beschikbaarheid van een systeem. Daarnaast bevordert het loose-coupling en stelt het teams in staat om continuous delivery in te zetten bij de ontwikkeling van het systeem.

Manier om functionele domeinen op te delen in autonome gebieden (bounded contexts) waarin 1 of meer domeinmodellen (aggregates) leven die slechts via 1 object kunnen worden benaderd (aggregate root). Per bounded context wordt een uniforme taal gebruikt om de entiteiten en het gedrag te beschrijven

“Not Only SQL”. Alternatieve dataopslag voor meer snelheid, schaalbaarheid of lager kosten. BASE ipv ACID. Er bestaan specifkeke NoSQL varianten voor verschillende toepassingen: Documenten, Graphs, Key-value pairs, WideColumns.

Een aanpak waarbij per situatie (context) een opslagmechanisme wordt gekozen dat het beste past binnen de context en de karakteristieken van de te persisteren data.

Architectuur pattern gebaseerd op kleine, gespecialiseerde en autonome services die communiceren op basis van events. Dit pattern stelt agile teams in staat autonoom te ontwikkelen met een hoge releasefrequentie.

Micro Services Domain Driven Design

CQRS

Web-scale Architecture

NoSQL

Design pattern waarbij de schrijfkant en leeskant van een model wordt gescheiden. Voor beide wordt de meest effectieve implementatie gekozen. Duplicatie van gegevens is in dit pattern eerder regel dan uitzondering.

Event Driven Architecture

Event Sourcing

Polyglot persistence Actor Model

Architectuur pattern waarbij de nadruk ligt op asynchrone communicatie ipv synchrone communicatie (vaak ondersteund door middle-ware als een broker of esb). Dit uit zich in een beter schaalbare opzet waarbij duplicatie van gegevens minder als een probleem wordt gezien.

Design pattern voor het opslaan van de state van een component. In plaats van het opslaan van de laatste state worden alle events opgeslagen die tot die state leiden.

Design pattern dat parallelle bewerkingen verdeelt over verschillende autonome actoren die berichten ontvangen, een beslissing nemen en weer berichten verzenden.

12 juni 2015


14

Een web-scale architecture draagt bij aan de schaalbaarheid, goede performance en hoge beschikbaarheid van een systeem. Daarnaast bevordert het loose-coupling en stelt het teams in staat om continuous delivery in te zetten bij de ontwikkeling van het systeem.

Manier om functionele domeinen op te delen in autonome gebieden (bounded contexts) waarin 1 of meer domeinmodellen (aggregates) leven die slechts via 1 object kunnen worden benaderd (aggregate root). Per bounded context wordt een uniforme taal gebruikt om de entiteiten en het gedrag te beschrijven

“Not Only SQL”. Alternatieve dataopslag voor meer snelheid, schaalbaarheid of lager kosten. BASE ipv ACID. Er bestaan specifkeke NoSQL varianten voor verschillende toepassingen: Documenten, Graphs, Key-value pairs, WideColumns.

Een aanpak waarbij per situatie (context) een opslagmechanisme wordt gekozen dat het beste past binnen de context en de karakteristieken van de te persisteren data.

Architectuur pattern gebaseerd op kleine, gespecialiseerde en autonome services die communiceren op basis van events. Dit pattern stelt agile teams in staat autonoom te ontwikkelen met een hoge releasefrequentie.

Micro Services Domain Driven Design

CQRS


NoSQL

Design pattern waarbij de schrijfkant en leeskant van een model wordt gescheiden. Voor beide wordt de meest effectieve implementatie gekozen. Duplicatie van gegevens is in dit pattern eerder regel dan uitzondering.

Event Driven Architecture

Event Sourcing

Polyglot persistence Actor Model

Architectuur pattern waarbij de nadruk ligt op asynchrone communicatie ipv synchrone communicatie (vaak ondersteund door middle-ware als een broker of esb). Dit uit zich in een beter schaalbare opzet waarbij duplicatie van gegevens minder als een probleem wordt gezien.

Design pattern voor het opslaan van de state van een component. In plaats van het opslaan van de laatste state worden alle events opgeslagen die tot die state leiden.

Design pattern dat parallelle bewerkingen verdeelt over verschillende autonome actoren die berichten ontvangen, een beslissing nemen en weer berichten verzenden.

12 juni 2015


15

Is dat allemaal nieuw? Nee! – – – – –

Actor Model : 1973 [Carl Hewitt] CQS : 1988 [Boek van Bertrand Meyer] EDA : Eind jaren ‘90 [Roy Schulte van Gartner] DDD : 2003 [Boek van Eric Evans] CQRS : 2009 [Blog post van Greg Young]

We zien wel steeds meer van dit soort patterns gebruikt worden binnen organisaties 12 juni 2015


16


MICROSERVICES 12 juni 2015


17

Microservices “Kleine” autonome services die samenwerken – Ontworpen op basis van business domeinen en business capabilities

Communiceren op basis van “lichte” protocollen – REST / JSON – Zo veel mogelijk asynchroon – Eventueel middels commands en events (CQRS)

Veel SOA principes gelden nog steeds 12 juni 2015


18

Microservices Omdat Microservices volledig autonoom zijn kunnen per service bepaalde keuzes worden gemaakt: – 3-tier | CQRS | Monoliet | … – C# | Java | Scala | NodeJS | … – SQL Server | File System | MongoDB | Cassandra | …

Dit bevordert flexibiliteit en maakt dat per probleem domein de best passende oplossing kan worden gekozen 12 juni 2015


19

Microservices principes Modelled around business domain Culture of automation

(DDD)

Highly observable Hide implementation details

Decentralize all things (freedom for the devops Teams)

Isolate failure

Deploy independently

(

12 juni 2015

)


20


ISOLATION 12 juni 2015


21

Isolation Zorg dat elke service autonoom kan functioneren en autonoom kan worden ontwikkeld Dit geeft flexibiliteit en stabiliteit – Services kunnen los van elkaar worden ontwikkeld (feature teams) – Services kunnen @runtime tijdelijk uit de lucht zijn (vanwege een bug of onderhoud) zonder dat het hele systeem stopt 12 juni 2015


22


ISOLATION – LOOSE COUPLING 12 juni 2015


23

Isolation - Loose coupling Gebruik waar mogelijk asynchrone communicatie – Is niet moeilijker dan synchroon, alleen anders – Gebruik events (eventueel met queueing / broker)

Zorg voor locatie transparantie – Inclusief monitoring (heartbeat) – Gebruik tooling: Consul / ZooKeeper 12 juni 2015


24

Isolation - Loose coupling Bouw waar mogelijk state-less services – Stop cache in UI of in de DB – Maakt uitschalen van services veel envoudiger

Scherm internals van services af Pas “Postel’s law” (“robustness principle”) toe – Wees strikt in wat je verstuurt en flexibel in wat je ontvangt 12 juni 2015


25

Isolation - Loose coupling Gebruik Consumer Driven Contracts Share response = GetProduct(); response.Body .Contains(“id”) .Contains(“weight”);

C1 Svc

response = GetProduct(); response.Body .Contains(“id”) .Contains(“name”) .Contains(“price”);

C2

“getProductResult”: { “product”: { “id”: string, “name”: string, “price”: decimal, “weight”: decimal } } Test

Resultaat

Test C1 Test C2

Share

12 juni 2015


26

Isolation - Loose coupling Gebruik Consumer Driven Contracts Share response = GetProduct(); response.Body .Contains(“id”) .Contains(“weight”);

C1 Svc

response = GetProduct(); response.Body .Contains(“id”) .Contains(“name”) .Contains(“price”);

C2

“getProductResult”: { “product”: { “id”: string, “name”: string, “price”: decimal, “weight”: decimal, “origin”: string } } Test

Resultaat

Test C1 Test C2

Share

12 juni 2015


27


ISOLATION – DESIGN FOR FAILURE 12 juni 2015


28

Isolation - Design for failure “The 8 falacies of distributed computing” L. Peter Deutsch

• The network is reliable

• Topology doesn’t change

• Latency is zero

• There is one administrator

• Bandwidth is infinite

• Transport cost is zero

• The network is secure

• The network is homogeneous https://blogs.oracle.com/jag/resource/Fallacies.html

12 juni 2015


29

Isolation - Design for failure Met andere woorden: “design for failure” – Er zullen fouten optreden, zorg dat je in de lucht blijft en dat je snel kunt herstellen Availability =

MTTF MTTF + MTTR

Weinig invloed (denk aan de “8 falacies”)

Veel invloed (wij schrijven de code) MTTF: Mean Time To Failure MTTR: Mean Time To Recovery

12 juni 2015


30

Isolation - Design for failure Introduceer fout-domeinen – Bulkhead pattern (scheepsterm) – Zorg dat als er iets stukgaat, niet het hele systeem stopt

Fail fast – Circuit-breaker pattern – Zorgt ervoor dat een time-out niet alles ophoudt 12 juni 2015


31

Isolation - Design for failure Bulkhead pattern

Threadpool

12 juni 2015

Threadpool


Threadpool

Threadpool

32

Isolation - Design for failure Circuit-breaker pattern

http://martinfowler.com/bliki/CircuitBreaker.html

12 juni 2015


33

Isolation - Design for failure Hystrix – Biedt o.a. ondersteuning voor de verschillende fault tolerance patterns (bulkhead, circuit breaker, …) – Oorspronkelijk ontwikkeld door NetFlix, nu OSS – Dashboard module voor monitoring beschikbaar – Java library (.NET port is in ontwikkeling) https://github.com/Netflix/Hystrix

12 juni 2015


34


CQRS 12 juni 2015


35

CQRS Command Query Responsibility Seggregation Pattern waarbij het lezen en schrijven van data in een systeem strikt wordt gescheiden – Biedt los schalen van lezen en schrijven (betere performance en beschikbaarheid) – Bevordert loose-coupling – Bevordert Taak georiënteerd werken (commands) 12 juni 2015


36

Evolutie van SOA naar CQRS / EDA DB

Traditionele Architectuur

Logic Command

Query

UI

12 juni 2015


37


CQS

Logic Command

Query

UI

12 juni 2015


38


CQRS

Write Model

Read Model

Command

Query

UI

12 juni 2015


39


CQRS

Replicatie

Write Model

DB

Read Model

Command

Query

UI

12 juni 2015


40

Evolutie van SOA naar CQRS / EDA Denormalizer

DB

CQRS

Write Model

DB

Read Model

Command

Query

UI

12 juni 2015


41

Evolutie van SOA naar CQRS / EDA Eventual Consistency!

Queue / Broker

Events

CQRS

Denormalizer

DB

Write Model

DB

Read Model

Command

Query

UI

12 juni 2015


42


EVENTUAL CONSISTENCY 12 juni 2015


43

Eventual Consistency Bij gedistribueerde systemen geldt het CAP principe – Consistency • Alle nodes in het systeem zien dezelfde data op hetzelfde moment

– Availability • Een node zal altijd binnen afzienbare tijd een nuttig antwoord retourneren (geen error of time-out)

– Partition Tolerance • Het systeem blijft functioneren bij het uitvallen van de connectie naar een bepaald onderdeel van het systeem (netwerk failure / crash / …) 12 juni 2015


44

Eventual Consistency CAP theorema – Volgens het theorema kan een gedistribueerd computersysteem altijd aan twee van deze voorwaarden voldoen maar niet (of zeer moeizaam) aan alle drie

Aangezien netwerken niet betrouwbaar zijn en we “partition tolerant” moeten zijn, moeten we kiezen tussen CP en AP 12 juni 2015


45

Eventual Consistency - CP CP zorgt ervoor dat data altijd consistent is N1

y

N2

Network yx

Y

ok

yx

o k

Client

12 juni 2015


46

Eventual Consistency - CP CP zorgt ervoor dat data altijd consistent is N1

y

N2

Network xy

Y

Client

12 juni 2015

Time-out

x

e r r o r Beschikbaarheid (A) is hier dus niet gegarandeerd.


47

Eventual Consistency - AP AP zorgt ervoor dat services altijd beschikbaar zijn N1

y

N2

Network yx

Y

ok

yx

o k

Client

12 juni 2015


48

Eventual Consistency - AP AP zorgt ervoor dat services altijd beschikbaar zijn N1

y

N2

Network yx

Y

Client

12 juni 2015

Time-out

x

o k Consistency (C) is hier dus niet gegarandeerd. Queueing kan er echter voor zorgen dat de update “uiteindelijk” wel wordt verwerkt  Eventual Consistency.


49

Eventual Consistency EC wordt vaak lastig geaccepteerd – “En hoe zit het dan met “ACID” en 2PC?”

In de “echte” wereld is bijna alles EC – Denk bij het automatiseren van processen goed na of volledige consistentie echt nodig is of dat EC voldoende is – Gebruikers snappen EC vaak beter dan we denken – EC scheelt een hoop moeite (en dus geld) 12 juni 2015


50

Eventual Consistency - BASE ACID  BASE

“Eventually consistent services are often classified as providing BASE (Basically Available, Soft state, Eventual consistency) semantics, in contrast to traditional ACID (Atomicity, Consistency, Isolation, Durability) guarantees.” - wikipedia

Basically Available – altijd een antwoord (kan wel een foutmelding zijn) Soft state – zolang er input is kan de state inconsistent zijn Eventually consistent – zodra de input stopt za het systeem consistent worden

12 juni 2015


51

Wrapping it Up https://www.flickr.com/photos/wordridden/1080528765/

Take-aways Implementeer Continuous Delivery Bouw loosely-coupled systemen Gebruik async communicatie waar mogelijk Isoleer services en “build for failure” Hanteer eventual consistency waar mogelijk Kies een passende oplossing per probleem domein 12 juni 2015


53

Leesvoer

•

Domain Driven Design: Tackling software complexity in the heart of software Eric Evans - ISBN: 978-0321125217

•

Release It! - Design and Deploy Production-Ready Software Michael T. Nygard - ISBN: 978-0978739218

•

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble & David Farley - ISBN: 978-0321601919

•

Exploring CQRS and Event Sourcing: A journey into high scalability, availability and maintainability Dominic Betts - ISBN: 978-1621140160

•

Building Microservices: Designing fine-grained systems Sam Newman - ISBN: 978-1491950357

12 juni 2015


54

No title

Recommend Documents