Web-scale IT.

Transcriptie

1 Web-scale IT

2 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 Web-scale Architecture 2

3 Agenda 2 1 Web-scale Architectuur 3 Uitdagingen in IT Microservices Isolation CQRS Eventual - Consistency WrapUp 4 Q&A 3

4 De uitdagingen van IT

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

6 IT Uitdagingen - Technisch Systemen gebaseerd op SOA Loosely coupled opgezet maar toch afhankelijkheden tussen 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 6

7 Hoe moeten we veranderen?

8 Hoe moeten we veranderen? Web-scale Architecture Supports 8

9 Web-scale Architecture

10 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: 10

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

12 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

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

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. 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. 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 Domain Driven Design Micro Services CQRS 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. 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, Wide- Columns. NoSQL Web-scale Architecture Event Driven Architecture 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. 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. Polyglot persistence Actor Model Event Sourcing 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. 14

15 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. 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. 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 Domain Driven Design Micro Services CQRS 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. 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, Wide- Columns. NoSQL Web-scale Architecture Event Driven Architecture 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. 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. Polyglot persistence Actor Model Event Sourcing 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. 15

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

17 Web-scale Architecture MICROSERVICES 17

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

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

20 Microservices principes Modelled around business domain Highly observable Culture of automation (DDD) Hide implementation details Decentralize all things Isolate failure (freedom for the devops Teams) Deploy independently ( ) 20

21 Web-scale Architecture ISOLATION 21

22 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 tijdelijk uit de lucht zijn (vanwege een bug of onderhoud) zonder dat het hele systeem stopt 22

23 Web-scale Architecture ISOLATION LOOSE COUPLING 23

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

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

26 Isolation - Loose coupling Gebruik Consumer Driven Contracts Share response = GetProduct(); response.body.contains( id ).Contains( weight ); C1 Svc getproductresult : { product : { id : string, name : string, price : decimal, weight : decimal } } response = GetProduct(); response.body.contains( id ).Contains( name ).Contains( price ); C2 Test Test C1 Test C2 Resultaat Share 26

27 Isolation - Loose coupling Gebruik Consumer Driven Contracts Share response = GetProduct(); response.body.contains( id ).Contains( weight ); response = GetProduct(); response.body.contains( id ).Contains( name ).Contains( price ); C1 C2 Svc getproductresult : { product : { id : string, name : string, price : decimal, weight : decimal, origin : string } } Test Test C1 Test C2 Resultaat Share 27

28 Web-scale Architecture ISOLATION DESIGN FOR FAILURE 28

29 Isolation - Design for failure The 8 falacies of distributed computing L. Peter Deutsch The network is reliable Latency is zero Bandwidth is infinite The network is secure Topology doesn t change There is one administrator Transport cost is zero The network is homogeneous 29

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

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

32 Isolation - Design for failure Bulkhead pattern Threadpool Threadpool Threadpool Threadpool 32

33 Isolation - Design for failure Circuit-breaker pattern 33

34 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) 34

35 Web-scale Architecture CQRS 35

36 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) 36

37 Evolutie van SOA naar CQRS / EDA DB Traditionele Architectuur Command Logic Query UI 37

38 Evolutie van SOA naar CQRS / EDA DB CQS Logic Command Query UI 38

39 Evolutie van SOA naar CQRS / EDA DB CQRS Write Model Read Model Command Query UI 39

40 Evolutie van SOA naar CQRS / EDA DB Replicatie DB CQRS Write Model Read Model Command Query UI 40

41 Evolutie van SOA naar CQRS / EDA DB Denormalizer DB CQRS Write Model Read Model Command Query UI 41

42 Events Evolutie van SOA naar CQRS / EDA Queue / Broker Eventual Consistency! DB Denormalizer DB CQRS Write Model Read Model Command Query UI 42

43 Web-scale Architecture EVENTUAL CONSISTENCY 43

44 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 / ) 44

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

46 Eventual Consistency - CP CP zorgt ervoor dat data altijd consistent is N1 yx y Network ok N2 yx Y o k Client 46

47 Eventual Consistency - CP CP zorgt ervoor dat data altijd consistent is Y N1 xy e r o r y Network Time-out N2 x Client Beschikbaarheid (A) is hier dus niet gegarandeerd. 47

48 Eventual Consistency - AP AP zorgt ervoor dat services altijd beschikbaar zijn N1 yx y Network ok N2 yx Y o k Client 48

49 Eventual Consistency - AP AP zorgt ervoor dat services altijd beschikbaar zijn N1 yx y Network Time-out N2 x Y o k Client Consistency (C) is hier dus niet gegarandeerd. Queueing kan er echter voor zorgen dat de update uiteindelijk wel wordt verwerkt Eventual Consistency. 49

50 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) 50

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

52 Wrapping it Up

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

54 Leesvoer Domain Driven Design: Tackling software complexity in the heart of software Eric Evans - ISBN: Release It! - Design and Deploy Production-Ready Software Michael T. Nygard - ISBN: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation Jez Humble & David Farley - ISBN: Exploring CQRS and Event Sourcing: A journey into high scalability, availability and maintainability Dominic Betts - ISBN: Building Microservices: Designing fine-grained systems Sam Newman - ISBN:

55