TEILE UND HERRSCHE: KLEINE SYSTEME FÜR GROSSE ARCHITEKTUREN

Transkript

1 schwerpukt m e h r z u m t h e m a : die autore TEILE UND HERRSCHE: KLEINE SYSTEME FÜR GROSSE ARCHITEKTUREN Ei System = ei Team, weige Richtliie ud viel Freiheit, Eigeveratwortug statt Goverace, schlake Itegratio über de Web-Stadard REST, das Teile eies große Problems i viele kleie Probleme sowie permaete Veräderug, statt Agst vor dem große Release. I diesem Erfahrugsbericht lese Sie, wie wir mit kleie, lose gekoppelte Systeme eie leichtgewichtige Architektur für otto.de geschaffe habe. Stepha Kraus (stepha.kraus@otto.de) hat über zeh Jahre Erfahrug i der Etwicklug ud dem Betrieb vo große Web-Aweduge ud E-Commerce-Sites. Er ist Teamleiter Software - etwicklug im Bereich E-Commerce bei OTTO i Hamburg. Afag 2011 hat sich OTTO zum komplette Neubau seier E-Commerce-Platt form otto.de etschiede mit weitreichede Ziele i Bezug auf das zu uterstützede Datevolume, die Dy amik der Date sowie die Persoalisierug ud Idividuali - sierug des Shops. Basiered auf de Erfahruge mit dem bestehede Shop- System, sollte die eue Software icht mehr auf Stadard software, soder auf eier Eigeetwicklug ud eier komplett eue Systemarchitektur beruhe. Parallel dazu sollte auch der Etwicklugsprozess auf ei agiles Vor gehe umgestellt werde. Das Ziel: Techologie als Kerkompetez bei OTTO etabliere, um am wachsede E- Com merce-markt schell agiere zu köe. Auf der Suche ach eier geeigete Archi tektur für die eue E-Commerce- Platt form habe wir somit icht ur die fuktioale ud icht-fuktioale Afor deruge bewertet, soder auch die orgaisatorische. Wie köe wir Ge - schwidigkeit im Etwicklugsprozess umsetze, ohe große techische Schuld aufzubaue? Wie stelle wir sicher, dass die Software wachse ka, ohe dass wir die Kotrolle verliere? Wie köe Team - strukture wachse, ohe die Abstim - mugs aufwäde zu erhöhe? Die Atworte auf diese prozessuale ud orgaisatorische Frage habe wir i der agile Softwareetwicklug ach Scrum ud de Prizipie vo Cotiuous Delivery gefude. Die Suche ach der dazu passede Architektur stad allerdigs i keiem Lehrbuch. Wie sieht also eie Software aus, die i alle relevate Dimesioe skaliert? Gemeit ist hier Skalierug im techische Sie, d. h. zur Erfüllug der Last- ud Performace-Aforderuge a otto.de, dem Sortimetsvolume ud steigede Kudezahle, vor allem aber auch Ska - lierug im orgaisatorische Sie, d. h. wie Mesche ud Teams orgaisiert werde köe, damit sie effektiv ud effiziet zusamme arbeite. Wir etwickel a eier Software, die städiger Veräderug uterworfe ist ud die städig wächst. Vo mehrere 100 zu mehrere Zeile Quellcode, sid wir ach eieihalb Jahre Etwick lug mittlerweile scho bei mehrere Zeile Quellcode agelagt. Age fage mit eiem Kerteam vo weige Et - wickler, sid wir izwische ei ca köpfiges, iterdiszipliäres Team. Gleich - zeitig steigt der Druck, immer mehr Afor deruge umzusetze. Wartbarkeit ud Äderugsfähigkeit der Plattform sid somit für die Zukuft etscheided. Gewichtsklasse Mit eier leichtgewichtige Architektur wolle wir otto.de für die Zukuft rüste. Doch wie kozipiert ma ei komplexes Softwaresystem, das auch mittel- ud lagfristig eie Chace hat, leichtgewichtig zu bleibe? Ud was ist eigetlich eie leichtgewichtige Architektur? Bei der Defiitio eier leichtgewichtige Architektur soll us die Vorstellug helfe, was wir uter eier schwergewichtige Architektur verstehe: Groß Moolithisch Weig modularisiert Eg gekoppelte Teilsysteme Eisatz vo Applikatiosserver Message Queues Guido Steiacker (guido.steiacker@otto.de) etwickelte bei OTTO im Rahme eies Prototype die Grudlage für die eue Shop-Architektur ud ist mittlerweile als Seior-Software-Architekt im Bereich E-Commerce für die Etwicklug des Recommedatio-Systems veratwortlich. Oliver Weger (oliver.weger@otto.de) ist Abteilugsleiter für Architektur ud Qualitäts - sicherug im ecommerce-bereich vo OTTO. Seit zwei Jahre leitet er als techischer Produkt - maager die Neuausrichtug der otto.de Plattform. I horizotale Schichte geschittee Systeme Detaillierte Architekturvorgabe Goverace mit etsprechede Frei - gabe- ud Geehmigugsprozesse Seltee, große Releases Uter eier leichtgewichtige Architektur verstehe wir folglich das Gegeteil: Kleie Systeme Modular aufgebaut ud lose gekoppelt 8 9

2 schwerpukt Abb. 1: Systemschitt ahad vo Fachdomäe. Weige Frameworks ud Abhä gig - keite Leicht testbar Nutzug vo Ope-Source-Kompoe - te Schelle Release-Zykle Mit de geate Rahmebediguge im Hiterkopf ud der Vorstellug eier leichtgewichtige Architektur gehe wir i die kokrete Umsetzug: Auf welche Architekturprizipie ud Leitliie ba - siert das eue otto.de, warum habe wir us für diese Architektur etschiede ud was sid die Erfahruge? Coway s Law Auch bei eier Neuetwicklug etstehe häufig moolithische Architekture mit eier eizige Code-Basis ud weige Artefakte. Die Modularisierug erfolgt eher ierhalb eier Awedug. Nur selte wird ei eimal etstadees System i eigestädige Teilsysteme zerlegt. Iteressaterweise etstehe diese grobgraulare Strukture vor allem da, we ur ei oder zwei Teams a der Etwicklug beteiligt sid, währed mehrere uabhägige Teams dazu eige, separate Aweduge zu etwickel. Diese Neigug vo Orgaisatiosstrukture, sich i der Softwarearchitektur abzubilde, wird auch als Coway s Law (vgl. [Co68]) bezeichet. Neuetwickluge starte häufig mit eiem oder weige Teams ud führe Coway zufolge leicht zu besagter grob-graularer Struktur. Währed es afags och vollkomme agemesse ist, mit eiem eizele System ud eier Code-Basis zu starte, ädert sich das im Laufe der Zeit. Das System wächst sehr schell, sodass es für eizele Etwickler immer schwieriger wird, eie Überblick über das gesamte System zu behalte. Häufig wächst parallel dazu auch das Team. Mit dem wachsede System äder sich auch die Ziele der Architektur: Geht es am Afag um eie eifache ud schelle Etwicklug, werde bei zuehmeder Größe des Systems Modularität ud lose Kopplug wichtiger. Achtet ma jedoch icht sehr frühzeitig darauf, etsteht geau das, was ma vermeide wollte: eie große, schwer wartbare, moolithische Archi - tektur. Wir habe daher frühzeitig das Gesamt - system i kleiere Teilsysteme ge schitte, OBJEKTspektrum ist eie Fachpublikatio des Verlags: SIGS DATACOM GmbH Lidlaustraße 2c Troisdorf Tel.: / Fax: / ifo@sigs-datacom.de die jeweils vo eiem Team etwickelt werde. De techische Schitt dieser Teilsysteme habe wir ahad userer spezifische Fachdomäe vorgeomme. Vertikale Im eifachste Fall lässt sich ei Olie- Shop wie otto.de beispielsweise i zwei Aweduge zerlege: de Shop ud eie Backoffice-Awedug, über die der Shop gesteuert wird. Folgt ma der ihärete Logik eies Olie-Shops (Produkt suche, auswähle, bewerte, bestelle usw.), lasse sich jedoch och weitere Kadidate für uabhägige Teilsysteme idetifiziere (siehe Abbildug 1). Diese Teilsysteme ee wir Vertikale. Sie sid durch folgede Eigeschafte gekezeichet: Separat deploybare Eiheit Eigees Froted Eigee Datehaltug Klar defiierte Zustädigkeit für Date ud Features Eigee Code-Basis, d. h. kei geteilter Code zwische de Vertikale Kei geteilter Zustad zwische de Vertikale Kommuikatio über defiierte REST- Schittstelle (REpresetatioal State Trasfer) Aus diese Eigeschafte lässt sich implizit schließe, warum wir us für de Begriff Vertikale etschiede habe: Im Gege - satz zu eier horizotale Architektur, i der ei Gesamtsystem ach techologische Aspekte, wie z. B. Datehaltug, Awedugslogik ud Präsetatio, ge - schitte ist, ist eie vertikale Archi tektur ach fachliche Aspekte geschitte ud beihaltet sämtliche horizotale Schichte. Eie Vertikale lässt sich dabei vo adere Vertikale weitgehed etkoppel (Loose Couplig) ud ist für eie begrezte, klar defiierte Mege vo Aufgabe zustädig (High Cohesio). Beides sid Begriffe, die aus der objektorietierte 5 / 2 013

3 schwerpukt Abb. 2: Beispiel für eie Web-Shop-Seite mit de jeweils ausgelieferte Seitefragmete

4 schwerpukt Etwicklug bekat sid, aber bei der Defiitio vo System - greze häufig aus de Auge verlore werde. Makro- ud Mikro-Architektur Das Prizip Divide & Coquer ket vermutlich jeder Softwareetwickler: Teile ei großes Problem i viele kleie Probleme, die du beherrsche kast. Mit de Vertikale wede wir dieses Prizip auf die gesamte Architektur a. Im Ergebis erhalte wir kleie, lose ge koppelte Systeme, die weitgehed uabhägig voeiader lauffähig sid. Durch die überschaubare Größe der Vertikale köe wir auf komplexe Frameworks vollstädig verzichte. Jeder Etwickler im Team versteht sei System ud eue Etwickler köe sich schell eiarbeite ud produktiv werde. Die Autoomie der Vertikale erhöht auch die Testbarkeit ud gestattet eie kotiuierliche Livestellug vo Features (fast) ohe übergreifede Release-Prozesse. Diese Vorteile etstehe selbstreded icht allei dadurch, dass ei großes System i mehrere kleie zerteilt wird. Hierfür werde übergreifede Architektur- ud Etwick lugs richtliie beötigt, damit alle Teile zueiader passe. Wir uterscheide dabei zwische Makro- ud Mikro-Architektur. Die Keridee dahiter: Mit weige (bei us isgesamt vier) Richtliie zur Makro-Archi - tektur wird das Zusammespiel des Gesamt systems festgelegt. Die Mikro-Architektur defiiert de iere Aufbau eier Vertikale ud wird vo jedem Team selbst festgelegt. Die Makro-Architektur ist i userem Fall sehr stark fachlich getriebe. Sie beschreibt auf techischer Ebee, wie mehrere autoome fachliche Systeme (Verti kale) miteiader iteragiere. Auf dieser Ebee muss bzw. darf icht bekat sei, wie die itere Architektur eies fachliche Systems aussieht oder wie sie implemetiert wurde. Usere Regel zur Makro-Archi tektur laute: Vertikaler Systemschitt: Das Gesamt system besteht aus eizele Teil systeme, die wir Vertikale ee (siehe obe). Klare Veratwortlichkeit für Date ud Dateversorgugsprozesse: Es gibt jeweils ur ei System, das ei Date objekt führed hält. Adere Systeme greife über die REST-Schittstelle auf diese Date zu ud halte sie bei Bedarf redudat, um sychroe Zugriffe auf die führede Vertikale zu vermeide. REST-Architektur: Die Kommuika tio zwische der Vertikale erfolgt über REST-Schittstelle. Auch Auf rufe aus eiem Browser sid als Aufrufe eies REST-Services zu verstehe, die eie HTML-Repräsetatio eier Res source aforder. Shared Nothig als Architektur prizip: Die Vertikale halte keie gemeisame Zustad ud teile sich utereiader auch keie Date i gemeisame Datebake. Die Mikro-Architektur beschreibt, wie eie Vertikale iter aufgebaut ist. Auf dieser Ebee ist beispielsweise relevat, welche Programmiersprache ud Bibliotheke verwedet werde ud welches Date baksystem eigesetzt wird. Auf der Mikro-Ebee reagiert das System flexibel auf techische Wadel ud veräderte Busiessaforderuge. I der Mikro-Architektur hat jedes Team maximale Freiheitsgrade. Der Techologie-Stack (z. B. Sprig MVC, Play oder Jersey) ka vo jedem Team selbst gewählt werde. I de Teams liegt auch die Betriebs veratwortug (Livestellug, Wartug, Fehlerbehebug) für die jeweilige Vertikale, wodurch der Areiz erhöht wird, auf eie etsprechede Testbarkeit, Testabdeckug ud Code-Qualität zu achte. Wie aus de eizele Vertikale ud de Regeluge der Makro- ud Mikro-Architektur eie Awedug etsteht, wolle wir im Folgede ahad eiiger kokreter techischer Lösuge vorstelle. Page Assembly Betrachte wir eie typische Seite aus eiem Shopsystem, fide wir Elemete wie zum Beispiel eie Suche, de Ware korb, eie Navigatio, Produktifor ma tioe oder Produktempfehluge. Eie solche Seite setzt sich aus eizele Frag mete zusamme, die vo uterschiedliche Vertikale ausgeliefert ud da zu eier Seite zusammegesetzt werde (Page Assembly): Das Search+Navigatio-System ist für die Navigatiosstruk - tur ud die Suche veratwortlich. Der Mii-Warekorb wird vom Order-System ausgeliefert. Produktiformatioe komme aus dem Product-System. Empfehluge zu dem Produkt komme aus dem Recom - medatio-system. Jede Seite des Systems liegt i der Zu städigkeit eier Vertikale ud wird vo dieser aggregiert ud ausgeliefert. Die zustädige Vertikale liefert jeweils de Seiterahme iklusive des wesetliche Ihalts, ud bidet de Ihalt aderer Ver ti kale i die Seite ei (siehe Abbildug 2). Nehme wir als Beispiel die Eibidug des Mii-Warekorbs (i Abbildug 2 obe rechts) i die verschiedee Seite. Die Eibidug der Ihalte ka dabei cliet- oder serverseitig erfolge. Uobtrusive JavaScript Der Ihalt des Warekorbes (Azahl der Artikel ud aktueller Wert) wird vom Order-System über eie REST-Ressource zur Verfügug gestellt. Bei der clietseitige Itegratio verwede wir uobtrusive JavaScript. Das die Seite auslieferde System fügt a der passede Stelle eie HTML-Lik mit eiem class-attribut ud eier href auf die Warekorb-Ressource i die Seite ei. Über JavaScript werde die Date vo diesem Lik gelade ud im Browser i die Seite eigebude (siehe Listig 1). Das Skript zum Auflöse des Liks ud zum Itegriere der Date i die Seite wird i diesem Fall vo dem Order-System veratwortet. Das System, das die Seite ausliefert, ist damit bis auf eie Vereibarug über die Itegratio des Warekorbs vom Warekorb-System etkoppelt. Dieses Paradigma ist auch als Resource-Orieted Cliet Architecture (ROCA) bekat (vgl. [ROC]). <a href= /miibasket/42 class= basket >Warekorb</a> + $( a.basket ).ready(fuctio() { loadaddisplay(this.href); }); Listig 1: Beispiel für de Eisatz vo Uobtrusive JavaScript. 5 / 2 013

5 schwerpukt <esi:iclude src= oerror= cotiue /> Listig 2: Beispiel für eie ESI-Iclude. Edg Side Icludes Eie adere Variate ist die Eibidug des Fragmets über Edge Side Icludes (ESI) (vgl. [W3C01]) bzw. Server Side Icludes (vgl. [Apa13]): Dabei liefert eie Vertikale zuächst de Seiterahme aus ud fügt für de Warekorb ei ESI i die Seite ei (siehe Listig 2). Ei vorgeschalteter Varish-Server (vgl. [Var]) (oder ei WebServer bei Verwedug vo SSI) parsed die Seite ud fügt astelle der Icludes das HTML-Schipsel ei, das beim Auflöse der URL zurückgegebe wird. A de Browser wird da die vollstädige HTML-Seite eischließlich des Warekorb-Fragmets geliefert. Natürlich gibt es auch och verschiedee Variate eier serverseitige Itegratio, die auf Ad-hoc-Afrage à la SOAP oder RPC zwische Vertikale basiere: Diese Art der Itegratio hat jedoch viele Nachteile, iklusive eier ege Kopplug ud eigeschräkte Testbarkeit, weswege wir hier icht weiter darauf eigehe wolle. Asset Server Obwohl je ach Seite uterschiedliche Vertikale für de Aufbau zustädig sid, solle sich diese verschiedee Seite selbstverstädlich eiheitlich präsetiere. Damit die verschiedee Teilsysteme sich dieselbe Cascadig Style Sheets (CSS), Images ud JavaScript-Bibliotheke teile köe, habe wir us für die zetrale Auslieferug solcher geteilte Ressource über eie Asset Server etschiede. Hier ist auch die Miifizierug vo CSS ud JavaScript verortet. Die vo diesem Server verwaltete Assets bilde die eizige Code-Bestadteile, die zwische de verschiedee Systeme geteilt werde doch dazu später mehr. Aus techischer Sicht ist der Asset Server ichts aderes als ei Web-Server zur Auslieferug statischer Ihalte. I userem Fall verwede wir dafür NGiNX (vgl. [NGI]). Datehaltug ud Dateversorgug Da wir währed der Seiteauslieferug auf Ad-hoc-Afrage zwische de Awe - du ge verzichte wolle, stellt sich atürlich die Frage, wie die eizele Systeme mit Date versorgt werde köe. Immerhi hadelt es sich um eie Olie- Shop ud auf die eie oder adere Weise werde viele Kompoete beispielsweise etwas mit Produktdate zu tu habe. Wir habe us daher auf eiige weige Regel geeiigt: Defiierte Veratwortug für Date Für alle Date ist geau eie Vertikale führed veratwortlich. Nur der Master defiiert de aktuelle Stad. Beötigt eie Vertikale Date, für die eie adere führed ist, werde die beötigte Iforma - tioe redudat gespeichert. Jedes System hält sich die vo ihm beötigte Ifor - matioe i eier für das System optimale Struktur. Isbesodere teile sich die Systeme kei gemeisames Datebakschema (oder auch ur die Datebak), da das wieder de Abstimmugsbedarf zwische de Teams erhöhe würde. Ei Team wäre da icht mehr i der Lage, Äderuge durchzuführe, da ma icht ausschließe köte, ei aderes Team i seier Arbeit zu behider. Asychroe Dateversorgug Die Dateversorgug erfolgt asychro im Hitergrud über die REST-Schittstelle des jeweilige Masters. Sychroe Zugriffe auf Iformatioe, also Zugriffe währed eier Beutzerafrage, versuche wir zu vermeide, um die Vertikale weitestgehed voeiader zu etkoppel. Pull versus Push Dateäderuge werde icht aktiv verteilt (Push), soder zyklisch über Feeds kosumiert (Pull). Dabei vermeide wir Full-Importe ud bevorzuge Delta- Importe. Dass wir Dateäderuge vorzugsweise per Pull kosumiere, hat sich für eie stabile Dateversorgug als besoders vorteilhaft erwiese. Überlege wir eimal, was beispielsweise das Product-System tu müsste, um Äderuge der Produktdate per Push zu verteile: Für jede Äderug eies Produkts (z. B. Preis oder Verfügbarkeit) müsste das System die Äderug aktiv a alle Empfäger verteile. Die Empfäger müsste dem System also bekat sei. Damit die Zustellug garatiert werde ka (Dateäderuge dürfe ja icht verlore gehe), müsste i irgedeier Form ei Hadshake erfolge. Für Fehlersituatioe (Ausfall eies Empfägers, Fehlermelduge, Netz - werk prob leme usw.) muss der Seder i der Lage sei, icht zustellbare Nach - richte später ereut zu versede. Das empfagede System müsste jederzeit i der Lage sei, die Äderuge zu verarbeite. Das ist icht immer leicht zu realisiere: Laufe beispielsweise gerade Aggregatioe auf Produkt - date, sid parallele Äderuge auf dem Datebestad upraktisch. Verwedet ma stattdesse eie Pull- Mechaismus, ka das empfagede System selbst etscheide, wa es Dateäderuge verarbeite ka. I der vo us gewählte Variate, stelle die Vertikale Atom Pub (vgl. [Gre07]) Feeds mit de Dateäderuge zur Verfügug. Die Iteressete köe diese Feed gelegetlich abfrage ud die Evets ab dem Zeitpukt der letzte be - kate Aktualisierug abhole, aufbereite ud persistiere. Damit köe die Iteressete auch leicht mit Fehlersituatioe umgehe: Sollte währed der Aktualisierug ei Problem auftrete, ka das System ab der letzte erfolg - reiche Äderug wieder eu aufsetze. Auf Full-Importe ka ma trotzdem icht vollstädig verzichte. Wir verwede sie aber primär für die iitiale Befüllug ud für eie Abgleich zwische dem Stad zweier Systeme bei Bedarf. Evetually Cosistet Dass die eizele Vertikale auf diese Weise icht zu jedem Zeitpukt über kosistete Iformatioe verfüge, muss ma 12 13

6 schwerpukt i eiem derart verteilte System akzeptiere. Eie strikte Kosistez würde uweigerlich die Skalierbarkeit des Systems beeiträchtige ud auch wieder zu eier egere Kopplug der Vertikale führe. I userem Fall ist es jedoch ausreiched, we die verschiedee Iformatioe regelmäßig wieder eie kosistete Stad erreiche, also evetually cosistet sid. Um die Zeitfester, i dee Ikosisteze auftrete, gerig zu halte, versuche wir de Preis für die Bereit - stellug eies Feeds möglichst iedrig zu halte. Auf diese Weise köe die Feeds häufig abgerufe werde. Ist das icht möglich, bietet sich eie Kombiatio aus Push ud Pull a: Stehe eue Äderuge a, sedet der Master ei Evet a registrierte Empfäger, das ur als Aufforderug zum Pulle diet. Die Emp - fäger frage daraufhi, wie obe beschriebe, de Feed ab. Damit ei solches Evet auch mal verlore gehe darf, frage die Emp fäger trotzdem och gelegetlich de Feed a. Auf diese Weise lässt sich das Fester für abweichede Datestäde sehr kurz halte, ohe eie ege Kopplug zwische de Systeme eizugehe. Shared Code Eiem gute Etwickler ahezulege, seie Code zu modularisiere oder dem Prizip Divide & Coquer zu folge, ist die eie Sache. Ihm aber zu erkläre, dass die verschiedee Teilsysteme tatsächlich eigestädige Aweduge sid, die sich ichts teile ud die isbesodere keie gemeisame Code habe sollte, eie gaz adere. Sobald sich zwei Systeme Code teile, werde sich die zustädige Teams über Äderuge a diesem Code abstimme müsse. Sie werde sich darüber eiige müsse, welche Abhägigkeite zu 3rd- Party-Bibliotheke erlaubt sid, wa ma ei Update vorehme darf, welche Et - wicklugsrichtliie zu beachte sid, wie viel ud i welcher Form zu dokumetiere ud zu teste ist ud dergleiche mehr. Wir verfolge daher folgede Asatz: Es gibt prizipiell keie Shared Code, soder ur 3rd-Party-Bibliotheke. Sobald zwei oder mehr Systeme sich Quellcode teile wolle, extrahiere wir de Code i ei Ope-Source- Projekt, veröffetliche es auf Github (vgl. [Git]) ud i Mave Cetral ud betrachte es als ormale 3rd-Party- Bibliothek. Damit ist es die freie Etscheidug eies Teams, die Bibliothek zu verwede oder ebe icht. Wir erhalte die Uab - hägigkeit zwische de Teams ud eie lose Kopplug der Systeme. Literatur & Liks Shared Nothig Währed Shared Code die Skalierbarkeit der Teams beeiträchtigt, ist jede Form vo Shared State ei begrezeder Faktor für die Skalierbarkeit der Systeme: Das Prob - lem ist dabei icht, dass eie Iformatio i zwei Systeme gespeichert ist, soder dass der Zustad sich äder köte ud die Systeme sich da über diese Zustads - äderug sychroisiere müsse. Bei eiige weige Systeme ist das kei Problem. Viele Applikatiosserver halte beispielsweise HTTP-Sessios im Haupt - speicher ud verteile die Date da über das Netzwerk. Kleie Cluster lasse sich auf diese Weise eifach ud effiziet betreibe. I große Cluster fuktioiert diese Lösug jedoch icht mehr zuverlässig. Wir habe us daher für de Shared-Nothig- Asatz etschiede: Eie Vertikale hält keierlei Shared State: keie Sessio-Date ud auch keie lokale Caches. Stattdesse werde solche Date im Browser, i HTTP- Caches (Browser, Cotet Delivery Net - work (CDNs), Reverse Proxys), i verteilte Caches (z. B. Memcached Server) oder Datebake gehalte. Alle Systeme habe damit dieselbe Sicht auf Iformatioe ud bleibe agostisch, was die Existez aderer Systeme ageht. Auf diese Weise er - reicht ma zwar icht die maximale Sigle- Node-Performace, dafür aber eie ausgezeichete Skalierbarkeit. Damit ma diese Skalierbarkeit icht eie Ebee tiefer, etwa i der Datebak, wieder verliert, muss ma auch hier ach passede Lösuge suche. Das ist eier der Grüde dafür, warum wir us gege de Eisatz vo relatioale Datebake ud für die MogoDB etschiede ha - be: Ei klassisches Relatioales Date - bak system (RDBMS) lässt sich eifach icht horizotal skaliere. Fazit Idem wir Divide & Coquer icht ur ierhalb eier Awedug, soder als Prizip auf die gesamte Architektur ud Orgaisatio agewedet habe, habe wir es geschafft, ei wirklich komplexes Stück Software i Form vo viele kleie Systeme zu etwickel. Für die Heraus - forderuge der techische Itegratio habe wir auf Basis eier lose gekoppelte REST-Architektur gute Lösuge gefude. Der große Vorteil dieses Prizips zeigt sich jedoch i der schlake Orgaisa - tiosstruktur, i der iterdiszipliäre Teams hochmotiviert ud eigeveratwortlich Lösuge für ihre spezifische Afor - deruge etwickel. Währed der Projektlaufzeit kote wir achweise, dass diese Orgaisatio eierseits skaliert ud adererseits sehr gut steuerbar ist. Es zeigt sich, dass Coway recht hatte ud das ma Coways Gesetz auch gezielt eisetze ka, um leichtgewichtige Archi - tekture zu etwickel ud Orgaisatioe dara auszurichte. [Apa13] The Apache Software Foudatio, Itroductio to Server Side Icludes, 2013, siehe: [Co68] M.E. Coway, How Do Committees Ivet?, 1968, siehe: [Git] Otto.de auf Github, siehe: [Gre07] J. Gregorio, B. de hora (Hrsg.), The Atom Publishig Protocol, 2007, siehe: [NGI] NGINX, siehe: [ROC] ROCA Resource-orieted Cliet Architecture, [Var] Varish Software, Varish Cache, siehe: [W3C01] W3C, ESI Laguage Specificatio 1.0, W3C Note 04 August 2001, siehe: 5 / 2 013