Johann-Peter Hartmann, profile picture
Hochgeladen vonJohann-Peter Hartmann
PDF, PPTX1,046 aufrufe

RoofTop Brains & BBQ: Ein Gästbuch für China

Das Dokument behandelt die Entwicklung eines Gästebuchs auf Basis von Node.js für China und beleuchtet die Herausforderungen und Vorteile der Skalierung von Webanwendungen mit Microservices. Es wird diskutiert, wie Microservices eine bessere Handhabung von Softwarearchitektur und -komplexität ermöglichen, insbesondere wenn es um hohe Zugriffszahlen und schnelle Reaktionszeiten geht. Zudem wird erklärt, warum der Fokus auf funktionalen Code anstelle von übermäßiger Boilerplate-Logik bei der Programmierumgebung wichtig ist, um die Effizienz zu steigern.

Präsentation einbetten

Als PDF, PPTX herunterladen
1 / 104
2 / 104
3 / 104
4 / 104
5 / 104
6 / 104
7 / 104
8 / 104
9 / 104
10 / 104
11 / 104
12 / 104
13 / 104
14 / 104
15 / 104
16 / 104
17 / 104
18 / 104
19 / 104
20 / 104
21 / 104
22 / 104
23 / 104
24 / 104
25 / 104
26 / 104
27 / 104
28 / 104
29 / 104
30 / 104
31 / 104
32 / 104
33 / 104
34 / 104
35 / 104
36 / 104
37 / 104
38 / 104
39 / 104
40 / 104
41 / 104
42 / 104
43 / 104
44 / 104
45 / 104
46 / 104
47 / 104
48 / 104
49 / 104
50 / 104
51 / 104
52 / 104
53 / 104
54 / 104
55 / 104
56 / 104
57 / 104
58 / 104
59 / 104
60 / 104
61 / 104
62 / 104
63 / 104
64 / 104
65 / 104
66 / 104
67 / 104
68 / 104
69 / 104
70 / 104
71 / 104
72 / 104
73 / 104
74 / 104
75 / 104
76 / 104
77 / 104
78 / 104
79 / 104
80 / 104
81 / 104
82 / 104
83 / 104
84 / 104
85 / 104
86 / 104
87 / 104
88 / 104
89 / 104
90 / 104
91 / 104
92 / 104
93 / 104
94 / 104
95 / 104
96 / 104
97 / 104
98 / 104
99 / 104
100 / 104
101 / 104
102 / 104
103 / 104
104 / 104
Ein Gästebuch mit Node.js. Für China. Ja, ganz China Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.
„Skalieren von WebApps ist ein gelöstes Problem.“ Ich, klugscheissend Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.
Wer nutzt Node.js produktiv? Erst mal ein paar Abfragen. Ich bin selbst eher Generalist als Spezialist, deshalb freue ich mich immer, wenn ein paar Spezialisten dabei sind. Die dann die speziellen Fragen beantworten können, die ich nicht beantworten kann :-)
Wer nutzt Docker produktiv? Wer hier nutzt Docker produktiv?
Wer nutzt MicroServices produktiv? Und wer nutzt MicroServices?
Wer nutzt MicroServices auf Basis von Docker & Node.js? Und wer nutzt MicroServices auf der Basis von Docker, in Node.js? Wer in Go? Rust? Haskell? Clojure?
Wir machen das auch. Aber warum?
ä Weil es gerade auf der Mitte des Hypecycles angekommen ist, und es jetzt einfach jeder machen muss? Oder gibt es auch gute Gründe?
Software Architecture is not about looking cool in front of your friends. Schliesslich ist Softwarearchitektur kein Gefährt, auf dem man seine eigene Coolness produzieren will. Aber es gibt tatsächlich ein paar gute Gründe, warum man MicroServices machen will.
ä Neue Projekte machen Spass. Dinge neu beginnen, mit guten Tools, das ist einfach. Man ist sehr produktiv.
ä Boilerplate Useful Code Und klar, die entstehende Software sieht ja auch super aus. Sie ist klein, wir haben weitgehend nützlichen Code, der wirkliche Dinge tut, nur wenig Boilerplate, und wir verstehen, was da passiert.
Und am Ende habe ich eine Software, die gut funktioniert und genau das tut, was sie machen soll. Unsere Nutzer lieben das, endlich mal was, was wenig Aufwand gekostet hat und gut funktioniert.
Und deshalb wollen sie noch mehr davon, und verlangen nach mehr Funktion, und die bauen wir dann auch ein.
Und am Ende sieht unsere kleine Software so aus.
ä WTF?! Boilerplate Useful Code Die klassische Spaghetti-Lösung hat zwar immer noch Boiler-Plate-Code und funktionalen Code, aber ebenfalls auch viel Code, der nur noch da ist, weil sich niemand traut ihn zu löschen. Code, bei dem Dinge mehrfach vorkommen, wenn auch zum Teil leicht verändert. Bei dem der Technical Debt hoch ist.
Und wir alle kennen das Gefühl, wenn man mit aller Energie nur noch einen Big Ball of Mud langsam bewegt? Und es macht weder richtig Spass, noch kommt man gut voran? Und immer wieder, wenn man in Mist fasst denkt man „ok, das sollte man jetzt prinzipiell sauber machen“ - tut es aber nicht, weil keine Zeit dazu da ist?
Könnte ich in Zukunft bitte - weniger Redundanz - weniger Komplexität - mehr Vorhersehbarkeit - mehr Verlässlichkeit bekommen? in der Situation fragt man sich, ob man nicht bitte in Zukunft weniger Redundanz, weniger Komplexität, mehr Vorhersehbarkeit und mehr Verlässlichkeit bekommen kann …
Und klar kann man. Eigentlich wussten wir ja schon wie das geht, und deshalb hat die Gang of Four das 1994 aufgeschrieben. Eigentlich hätten wir es also schon immer wissen können, und hätten es also auch von Anfang an vermeiden können :-)
Brauche ich bei kleinen Projekten nicht, deshalb vergessen wir es bei jeder neuen Sprache erst mal :-) Und warum vergessen wir es jedes mal wieder? Weil wir es bei kleinen Lösungen nicht brauchen. Das Problem entsteht erst mit Wachstum der Software, die nicht mehr in unser Hirn passt.
Die Design Patterns erzeugen Vorhersehbarkeit, klare Verantwortung und eine klare Zuordnung von Tätigkeiten zu Code.
Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Das ist so eine typische Verteilung von Verantwortung - eine layer-basierte Architektur. So sehen bis heute viele grössere Webapplikationen aus. Wer hat schon einmal an so einer Applikation mit diversen Layers gearbeitet? Genau, ich auch.
Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Und auch in den Layers hat alles seinen Platz. Inzwischen haben wir sogar im JavaScript ein MVC-Design, das gleiche im Frontend-Layer, das gleiche dann noch mal im Rest-Service Layer dahinter, unter dem dann final ein Business Object layer liegt.
Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest / REST Unit-Tests Und weil wir jetzt ja mit Qualität arbeiten gibt es auch noch diverse Testumgebungen, die das ganze stabilisieren. Meist wird die Business-Logik lokal mit Unit Tests stabilisiert, das Backend-Layer mit REST-Integrationstest und das Frontend mit Akzeptanztests.
„Bitte zweiten Vornamen einführen.“ Wer - wie ich - solche Architekturen schon mehrfach gebaut hat, ist nach einer Weile genervt von Ihnen. Spätestens, wenn der Pointy Haired Boss um die Ecke kommt und fragt, ob er bitte den zweiten Vornamen ins Formular haben kann.
Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest / REST Unit-Tests Und dann muss man tatsächlich die Acceptance Tests, den View, den Controller, das Model, den Controller, das Model, den REST-Test, den Unit-Test, das Business- Object und das ORM anfassen, und die Datenbank ändern.
1 Concern so separated, dass wir 12 mal Code anfassen müssen. Wir haben tatsächlich die Software vorhersehbar gemacht, aber dabei aus einem Concern eine Sache gemacht, die in 12 mal Code anfassen resultiert.
Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Everyf*ckingfunctionality Das ist auch kein Wunder - denn die Business-Aspekte treten jeweils in jeder Schicht einmal auf.
Solche Architekturen werden von den MicroService-Jungs gerne Lasagne-Architekturen genannt. Sie bestehen aus vielen Schichten,und wenn ich was will, muss ich durch alle durch :-) .
Ein Gästebuch mit Node.js. Für China. Ja, ganz China Ok, aber eigentlich sind wir ja für China hier. Und China wartet jetzt, auf Slide 28, immer noch auf sein Gästebuch.
Gucken wir doch mal, was wir da so brauchen. Ganz China klingt ja schon mal enterprisig. Schauen wir uns das mal im Detail an.
1.400.000.000 Personen China, das sind zur Zeit etwa 1.4 Milliarden Menschen. Etwa jeder siebte Mensch ist Chinese.
55% 721.434.547 Personen mit Internet Teil meiner Überlegung war, dass vermutlich sehr wenige von denen das Internet nutzen. Das stimmte aber nicht - mehr als die Hälfte nutzt das Internet. Das sind zwar noch immer weniger als die 80% der Einwohner hier, trotzdem mehr als 10 mal so viele Internetnutzer.
1 Besuch pro Woche Ansicht, Blättern, Eintrag, Ansicht Gehen wir mal davon aus, dass man so ein Gästebuch überschaubar nutzt. Man besucht es einmal pro Woche, also 52 mal im Jahr.
1 Besuch pro Woche 3 GET, 1 POST Startseite Blättern Eintragen Angucken Und der durchschnittliche Besuch sind 4 Anfragen, die an dynamischen Content gehen. Startseite, einmal blättern, einmal eintragen, angucken, und wieder weg.
2.885.738.188 Req / Woche 412.248.313 Req / Tag 4.771 Req / Sekunde Das sind dann pro Woche ja nur knappe 3 Milliarden Requests. Am Tag sind das 412 Millionen Requests, weil die Gästebücher nicht saisonal sind - bei e-Commerce hätte man da mehr drauflegen müssen. Macht pro Sekunde 4771 Requests.
5.000 Req/Sekunde Average 10.000 Req/Sekunde Peak = 2500 POST &7500 GET Also gehen wir mal von einem Average von 5000 Requests aus, die wir für die Peakzeiten bequem auf 10.000 Requests pro Sekunde hochskalieren müssen. Pro Sekunde sind das 2500 Posts und 7500 Gets,umgerechnet. Das ist wichtig für das Caching - es muss 2500 mal pro Sekunde aktualisiert werden. 2500 mal pro Sekunde, das ist das Der Ton ist das Dis ganz rechts auf der Klaviertastatur, also Taste 79 von 88.
POST: 100.000 LPUSH/s GET: 50.000 LRANGE/s Benötigt: 2.500 POST 7.500 GET 10.000 Req/s Ok, gucken wir mal, ob das machbar ist. Erster Kandidat: Redis. Redis haben wir schon bei ein paar dicken Applikationen im Einsatz, das kann das gut. und ich habe es noch mal extra auf einem normalen, etwas dickeren Amazon-Server (c3.large) gemessen, da komme ich bequem im Redisbenchmark auf 100.000 LPUSH, mit dem ich Daten in eine Liste eintrage, und auf 50.000 LRANGE-Leserequests, bei denen ich die letzten 10 Einträge abhole. Das ist doch cool.
>100.000 Req/s Benötigt: 10.000 Req/s 10.000 Req/s Und, kann das auch der Webserver? Je nach Amazon-Klasse kann ein nginx-Node unterschiedliche Requests, praktisch sind es aber fast immer 6-stellige Zahlen. Also: kein Problem.
>50.000 Req/s Benötigt: 10.000 Req/s 10.000 Req/s Und node.js selbst? Wenn er eine CPU für sich alleine bekommt, dann kann er auf den 4 Cores bequem 50.000 Requests in der Sekunde abfackeln. Die Rahmenbedingungen sind also gegeben.
Das ist doch machbar. Aller Erfahrung nach sollte das also gehen.
Und zwar auf einem einzigen Rechner. Und zwar auf einem einzigen Rechner. 2 CPUs mit jeweils 4 Kernen, sollte gehen.
Klar geht das. Mit einem HelloWorld. Der Nachteil an der Überlegung: das geht, klar. Mit einem hello-World-Script. Wenn meine Software darüber hinaus geht sieht es anders aus.
Was im Request passiert Kernel Serverprocess Compiler/Interpreter Applikation Aber schauen wir uns das mal im Detail an. Wenn der Request auf dem Webserver landet, dann ist das erst mal ein Interrupt auf Hardware-Eben, der dann den Kernel veranlasst, eines seiner Module danach zu befragen, was damit geschehen sollte. Das liest die Daten aus und gibt sie an den Servierprozess weiter, und der wirft den Compiler/Interpreter an. Und erst da beginnt die Applikation.
Was im Request passiert 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befüllen 13.Template rendern 14.Response erstellen Und da beginnt erst die richtige Arbeit. Der Request muss vom Framework geparsed werden. Dann wird der Router angeworfen, um herauszufinden, welcher Controller sich darum kümmert. Dann wird dieser angeworfen, und muss erst mal gucken, welche Daten da von ihm von draussen kamen. Und dann denkt er über diese Daten nach, und findet heraus, was auf dieser Basis er von der Datenbank holen soll. Also einen Datenbankrequest gebaut, den über Kernel zur DB, dort bearbeitet, wieder zurück, Ergebnis demarshallen, Aufbereiten, damit rechnen, das Template initialisieren, befüllen und rendern, und dann dem Webserver zur Ausgabe geben.
Was im Request passiert Applikation: 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befallen 13.Template rendern 14.Response erstellen Nimmt man die ganzen Indirektionen und Abstraktionen raus, dann gibt es eigentlich nur 3 Dinge wirklich zu tun - Request verstehen, Wert berechnen und wieder zurückgeben. Die Datenbank könnte ich ja auch selbst im Ram halten.
Was im Request passiert Real Code Boilerplate Language Prozess Kernel Die wahre Ressourcennutzung in meinem Request liegt also nicht im Funktionalen Code, sondern in der ganzen Boilerplate drumherum. Etwas ist zwangsläufig, weil wir einen Kernel mit Prozessen etc haben, vieles ist aber die Boilerplate unserer Programmierumgebungen.
Fun Fact 1: 
 Bei PHP-Symfony- Applikationen liegt der funktionale Anteil 
 unter 0.1 %. Ich kenne das selbst sehr gut aus Consulting-Projekten im PHP-Bereich: der tatsächlich relevante Code ist nur ein Bruchstück dessen, womit die CPU ihre Zeit verbringt. In diesem Kontext - bei Symfony, das ist quasi Spring für PHP, liegt es praktisch immer unter 0.1%.
0 750 1500 2250 3000 Request / Sekunde Node.js nativ Node.js Express-Routing Node.js Express + Jade-Template Fun Fact 2: Dito Node.js Bei Node.js ist es aber auch nicht wirklich besser. In meiner lokalen Testumgebung auf einem i7-Core, ohne Virtualisierung konnte die gleiche Gästebuchapplikation mit nativem Code etwa 2500 Request, mit express als Framework etwa 1500 Requests - und mit Jade zur Ausgabe bei nur einem Template, aber einer Schleife nur noch 50. Hier wirken also 98% Boilerplate.
Fun Fact 3: 
 Das Gästebuch als Kernelmodul würde auf einem Raspberry PI China versorgen. Und noch ein Fun-Fact: wenn wir das ganze als Kernelmodul in C direkt auf dem ethernet-Driver programmieren würden, könnten wir China vermutlich mit einem Raspberry PI versorgen.
Wäre es dann zum Skalieren nicht viel sinnvoller auf den funktionalen Code zu fokussieren? Da stellt sich die Frage: wenn ich so viele Dinge mache, die eigentlich nur Boilerplate sind, damit der Code sich um sich selbst kümmern kann und der Entwickler auf der Ebene höherer Konstrukte arbeitet, wäre es nicht besser, bei skalierbaren Applikationen den Fokus auf den echt wirksamen Code zu setzen?
Und davon dann für jede Funktion eine kleine Applikation anbieten, die genau diese Sache schnell & skalierbar macht? Man könnte dann ja die ganze grosse Applikation in kleine Scheiben schneiden, die für den jeweiligen Aspekt im wesentlichen aus viel Funktion und wenig Boilerplate bestehen. Und diese Scheiben wären dann echt schnell und skalierbar.
Ravioli instead of Lasagna or Spaghetti
Ack, und das könnten wir dann „MicroServices“ nennen. Ja, könnte man machen, und das könnte man dann MicroServices nennen. Die Jungs, die damit angefangen haben - und damit meine ich vor allem Amazon und Konsortien - haben genau diese Aufgabe und diesen Plan gehabt. Wenn ich viele Millionen Server habe ist es wichtig, ob ich 0.1%,1% oder 80% der CPU für echte Funktion nutze. 100 mal mehr Server, dafür aber schönerer Code - das ist schwer zu verargumentieren.
„The services are small - fine-grained to perform a single function.“ Schauen wir uns doch mal die Quasioffizielle Definition von MicroServices in der Wikipedia an: the die Services sind kleingeschnitten, so dass sie nur eine einzige kleine Funktion erfüllen.
Each service is elastic, resilient, composable, minimal, and complete. Sie sind elastisch, minimal, vollständig und man kann sie verdrahten.
The culture and design principles should embrace failure and faults, similar to anti-fragile systems. Damit ich das brauchbar machen kann, brauche ich eine Kultur der Fehlertoleranz. Ich muss es überleben, wenn ein paar von denen zeitweilig weg sind.
The organization culture should embrace automation of deployment and testing. Und am Ende soll die Organisationskultur das ganze auch automatisieren können, damit ich schnell skalieren kann - und auch schnell entwickeln kann. Und während ich die Aspekte Agilität, Developereffizienz und Agilität normalerweise liebe, verzichte ich heute zugunsten der Zeit und der Skalierbarkeit darauf.
ä MicroServices „Applications that fit in your head. Eine ebenfalls schöne Definition ist : Applikationen, die in den Kopf passen.
ä MicroServices „Applications that fit in your head. Boilerplate Useful Code Boilerplate Useful Code Boilerplate Useful Code Also: ganz viele kleine Greenfields.
ä MicroServices Node.js Docker WTF Node.js & Docker?! Ok, MicroServices macht also Sinn - aber warum, um Himmels Willen, nodejs? Und warum bitteschön Docker? Kann
ä Es skaliert gut … … über Entwickler Die Antwort darauf ist einfach - beide Werkzeuge skalieren sehr gut über die Ressource, die in unserer Branche am wenigstens vorhanden ist - Developer.
ä „Applications that fit in their heads. Aber das sind doch alles Anfänger! Und klar gibt es dann immer das Argument, dass die Heerscharen der Docker- und Node-JS-Nutzer viele Juniors enthalten. Und klar ist die Antwort: Ja, natürlich, wenn das alles nur Seniors wären, dann wären das ja auch nicht viele Entwickler. Aber es gibt einen Vorteil: MicroServices sind genau darauf eingestellt. Einen Junior kann man deutlich besser mit einem MicroService als mit einem Monolithen betreuen. Die kleinere, einfacher zu verstehende Software.
ä „Applications that fit in their heads. Yep, MicroServices eignen sich gut für Anfänger. Das klingt jetzt total doof, ist aber trotzdem so- MicroServices eignen sich gut für Anfänger. Das ist quasi ein Abfallprodukt des Initialplans.
„Elastic“, „fine-grained“, „automated“ deployed, „failure“ & „fault“- tolerant? Und bei Docker sprechen auch viele andere Dinge für den Einsatz bei MicroService-Architektur
Und das haben auch viele andere gemerkt. Google sagt, es gäbe zur Zeit etwa eine halbe Million Treffer zu Docker und MicroServices, und praktisch seit 2014/15 kommen beide häufig nicht alleine zur Party. Die Trefferzahl zu JavaScript bzw. Nodejs MicroServices liegt auf dem gleichen Niveau.
Tools für eine MicroService- Orchestrierung mit Docker Wie sieht das also konkret aus, wenn ich Docker und MicroServices für die Orchestrierung von, sagen wir mal, einem hochskalierbaren Gästebuch einsetzen will. Ich werde zunächst die Mitspieler vorstellen, und dann kurz den Einsatz an einem echten Beispiel zeigen.
Outing 1: Ja, es gibt auch andere Tools, die das können. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.
Outing 2: Der aktuelle RC von Docker hat vieles Builtin. Und kaputt. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.
Tools: Docker - Container-CLI - Erstellen von Images - Veröffentlichen von Images - Remote-Interface zum Docker-Host - Daemon/ Docker-Host - Rest-Service als Interface auf Port - Starten, stoppen, laden von Images Beginnen wir mit Docker. Die, die es schon kennen, langweilt es vermutlich eher.
Tools: Docker Machine - Maschinen mit Docker-Host erzeugen - auf VirtualBox - Amazon Eck - Digital Ocean … - Verwaltung der Maschinen - Docker-CLI auf die Maschine wechseln - Listen , Stoppen etc Das nächste Tool der Wahl ist Docker-Maschine. Da kommen die kleinen DOCKER_HOSTS her, mit diversen Interfaces.
Tools: Docker Swarm - Docker über mehrere Server - Gemeinsamer Docker-Host - Swarm-Manager mit Fail-Safety - neue Server können Joinen - mit Event-Bus Etwas frischer ist der Docker Swarm, der gerade in der Version 1.0 rausgekommen ist - und vor 2 Wochen gab es dazu die Swarm Week mit vielen Blogartikeln. Ich mag swarm, weil er Dinge, die sonst kompliziert sind (Hallo, Kubernetes), auf einem recht überschaubarem Dilletantenniveau hält.
Tools: Swarm-Mode - Neu in Docker 1.12 - Scaling vorhanden - Service Discovery über DNS - Ingress Load Balancing - Rolling Updates! Now: BuiltIn Swarm-Mode Inzwischen - mit dem aktuellen Release-Candidate - ist der Swarm-Mode default-Bestandteil von Docker.
Tools: Docker Compose - Docker-Cluster anlegen - YAML-Konfiguration über docker- compose.yaml - Anlegen von Services/Containern - Anlegen von Netzwerken - Anlegen von gemeinsamen Devices - Skalieren von Services! Damit die diversen Docker-Service mit einander zurecht kommen gibt es Docker Compose. Docker Compose bekommt eine wirklich einfache Yaml-Datei, mit der man nicht nur die Services und Ihr Zusammenspiel orchestrieren kann, sondern auch gemeinsame Volumes und Netzwerke einrichten kann. Und so geil das Tool ist, ein paar Lücken gibt es noch - zB. klappt das verteilen von lokal gebauten Images noch nicht im Schwarm, da muss also die eigene Registry her, wenn man den bedienen will.
Tools: Consul - Key-Value-Storage zur Verwaltung - Fail-Safe - DNS-Support - Support von Docker Swarm - eigentlich „Konsensus-Tool“ Ebenfalls schon länger mit dabei: Consul als Key-Value-Store, der zur Verwaltung der Daten genutzt wird. Er ist Cluster-fähig, und eine der Backends, das vom Docker Swarm verwendet werden kann.
Tools: Interlock - Event-Plugin-System - Lauscht auf dem Event-Bus eines Swarm - Startet Plugins: - nginx - haproxy - ergänzt neue Container in nginx/ haproxy ein Und kommen wir zum letzten Tool der Orchestrierung: Interlock. Interlock nennt sich selbst ein Event-Plugin-System, das alle Events aus dem Docker-Schwarm mitbekommt - also zB neue Container, die joinen. Und wenn er erkennt, dass diese Container zu http geroutet werden sollen, dann aktualisiert er den dazugehörigen Proxy oder Webserver.
1. Eine Node-App zu einem Container 
 machen DockerFile-> ATOM Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerfile.
docker build -t johannhartmann/ noderedis . docker push johannhartmann/noderedis Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerfile.
2. Einen Schwarm erzeugen
Aber kommen wir mal zur konkreten Architektur: Draussen wohnt das Internet, hier drinnen wohnen wir - mit 4 Host-Nodes, einem Redis-Node, einem Manager und dem Interlock/Redis-Node als Manager.
Manager-Maschine:
 Consul starten docker run --restart=unless-stopped -d -p 8500:8500 -h consul progrium/ consul -server -bootstrap Jetzt habe ich also ganz viele Maschinen, und die sollen zu einem Schwarm werden. Und ich beginne mit Consul, dem Storage für den Schwarm.
Manager-Maschine: Swarm-Manager starten docker run --restart=unless-stopped -d -p 3375:2375 swarm manage consul://192.168.33.11:8500/ Damit der Schwarm auch tatsächlich einer werden kann starte ich einen Schwarm-Manager. Das können wie bereits gesagt mehrere sein, in diesem Beispiel nutze ich aber nur einen. Der Schwarm-Manager lauscht selbst, wie der Docker-Host sonst auch, auf Port 2375 bzw. 2376 bei tls. Weil ich den Port auf dem Host schon für den normalen Docker-Container nutze, muss ich hier auf Port 3375 ausweichen.
Manager-Maschine: Nodes registrieren docker -H=tcp://192.168.33.20:2375 run -d swarm join -- advertise=192.168.33.20:2375 consul://192.168.33.11:8500/ Ein Schwarm ohne weitere Rechner nutzt mir aber nichts. Deshalb registriere ich mal alle anderen Maschinen - beginnend mit den Workern. Die Registration sieht ähnlich dem swarm manage von eben aus, nur jetzt mit dem Kommando join. Er soll sich selbst für den Swarm als Docker-host bekannt machen, und zwar auf der IP 192.168.33.20. Und für die Datenverwaltung soll er auf den Consul-Service auf dem Manager-Node zurückgreifen.
Manager-Maschine: Redis, Interlock, Manager docker -H=tcp://192.168.33.250:2375 run -d swarm join -- advertise=192.168.33.250:2375 consul://192.168.33.11:8500/ … Die gleiche Registration passiert auch auf den anderen Maschinen.
Wenn sie gejoint haben kann ich mir die vollständige Liste der Container - also der Container, die auf den beteiligten Docker-Hosts laufen, wenn auch nicht im Swarm - wieder mit docker ps -a angucken.
Manager-Maschine: Overlay Network docker network create --driver overlay mynet Auch die Docker-Netzwerk-Fähigkeiten lassen sich in dem Swarm nutzen - Voraussetzung it allerdings, dass hier der Key-Value-Storage, hier im Beispiel Consul, existiert. Dann kann ich mit diesem Befehl das Overlay-Network anlegen.
Docker Compose: docker-compose.yml https://github.com/johannhartmann/chinaguestbook/blob/ master/docker-compose.yml Docker-Compose wird über die docker-compose.yml gesteuert. Diese Daten enthält alle relevanten Informationen über die Container selbst, den Netzwerke und die gemeinsame Volumes.
Lokal: Compose-Cloud starten docker-compose build - öhm, doch nicht. docker-compose up Normalerweise würde man jetzt die Pakete für den Docker-compose bauen. Aber: Docker-Compose kann lokal gebaute Pakete noch nicht an einen Schwarm verteilen. Also muss ich sie vorher selbst pushen. Wenn ich das getan habe kann ich meine Cloud aber durchstarten. Das mache ich mit „docker compose up“ - und in Folge werden alle Images auf alle hosts gepullt, und dann anhand der Constraints auf den Hosts gestartet.
Benchmark 1 Container Jetzt, wo meine Cloud - wenn auch nur mit einem Container - online ist, kann ich ja mal gucken, wieviel Durchsatz sie hat. Und tatsächlich - es sind nur 80 Requests/ Sekunde.
Lokal: Compose-Cloud skalieren docker-compose scale web=100 Also müssen wir das skalieren. Das machen wir mit einem sehr einfachen Befehl - docker-compose scale web=100 - und schwupps, wird die Zahl der laufenden Container auf 100 erhöht. Weil diese Applikation CPU-Bound ist, muss ich schlicht etwa so viele container bauen, wie ich Kerne habe - denn mehr als 100% CPU-Last möchte ich nicht auf den Maschinen haben.
Benchmark 100 Container Und tatsächlich - wenn ich 100 Container durchstarte auf den beiden grossen Hosts, dann bekomme ich genug Traffic für knapp ein halbes China. Sorry, dass ich hier nicht ganz China gedemoed habe - das war mir bei den m4.x10large-Images zu teuer :-) Aber es geht.
Strategie für Micro- Service Architekturen mit Node.js auf Docker 1. Node.js-Services klein schneiden und einzeln als Container paketieren Also, mal alles zusammengenommen: ich zerlege meine App in mehrere Services, die jeweils für sich autark laufen. Jeden dieser Services packe ich in einen Docker-Container.
2. Micro bedeutet auch die Chance, auf Boilerplate verzichten zu können, und das erzeugt Performance Strategie für Micro- Service Architekturen mit Node.js auf Docker Ich nutze die Chance, auf boilerplate und Libraries zu verzichten, wenn ich wirklich skalieren muss. Boilerplate & Frameworks haben einen Impact von Faktor 10 bis Faktor 1000. MicroServices erlauben mir, auch ohne Boilerplate Software zu überleben.
3. diese Services kann man über docker-compose/swarm einfach skalieren Strategie für Micro- Service Architekturen mit Node.js auf Docker Wenn ich die Services in einem Container habe, fällt mir das skalieren leicht.
4. und über Dienste wie interlock auch unmittelbar nach aussen freigeben. Strategie für Micro- Service Architekturen mit Node.js auf Docker Über Dienste wie interlock integriere ich neue Dienste oder zusätzliche Container implizit, ohne dass zusätzlicher Aufwand ensteht. Mit den aktuellen Docker-Tools ist die Schwelle zur Konfiguration und zur Nutzung deutlich geringer geworden, als dies vorher der Fall war. Ich habe den Komfort von PAAS, ohne mich an einen Anbieter binden zu müssen.
Ich brauche 4 m4.10xlarge Hosts für China mit Jade. China-Fazit:
Die Docker-Welt hat immer noch viele Bugs und wenig Doku.
Es wird trotzdem ein Commodity-Ding für alle.
Die aktuellen LargeScale- Tools werden Commodity.
Kleine Services, wenig Boilerplate.
ä Wenn man das so macht, dann hat die Arbeit wieder deutlich mehr Greenfield-Feeling.
Files: https://github.com/johannhartmann/chinaguestbook Slides: http://slideshare.net/johannhartmann Video: Slideshare embedded (Mal ehrlich: ich hätte es trotzdem mit PHP gemacht :-) Vielen Dank!

Weitere ähnliche Inhalte

PDF
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
PDF
Das Ende der Karriere
vonJohann-Peter Hartmann
 
PDF
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
PDF
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
PDF
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
PDF
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
PDF
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
PDF
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 
Die Architektur, die man kann
vonJohann-Peter Hartmann
 
Das Ende der Karriere
vonJohann-Peter Hartmann
 
Erfolgreiche rewrites
vonJohann-Peter Hartmann
 
Performancemessung, jetzt in echt
vonJohann-Peter Hartmann
 
Legacy php - Sanieren oder Ablösen?
vonJohann-Peter Hartmann
 
DevOps jenseits der Tools
vonJohann-Peter Hartmann
 
Einfangen eines technisch kaputten projektes
vonJohann-Peter Hartmann
 
Agile versus Management WJAX 2014
vonJohann-Peter Hartmann
 

Was ist angesagt?

PDF
Rewrites überleben
vonJohann-Peter Hartmann
 
PDF
Management brainfucks
vonJohann-Peter Hartmann
 
PPTX
Arbeitswelt2020 pecha kucha
vonUniversity St. Gallen
 
PDF
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
PDF
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
vonGerrit Beine
 
PDF
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
PDF
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 
PDF
Planlos mit Plan
vonFrank Düsterbeck
 
KEY
Portfolio Kanban
vonStefan ROOCK
 
PDF
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
PDF
GPM Vortrag: Modernes Management von Softwareprojekten
vonFrank Düsterbeck
 
PDF
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
PDF
Arbeitswelt2020PechaKucha
vonElsy Zollikofer
 
PDF
Software-Entwicklung Im Team
vonStephan Schmidt
 
PDF
NewWork in der Praxis
vonJohann-Peter Hartmann
 
PDF
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
PDF
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
PDF
Agile Führung - echt jetzt?
vonAgile Usergroup Unterfranken
 
PDF
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 
Rewrites überleben
vonJohann-Peter Hartmann
 
Management brainfucks
vonJohann-Peter Hartmann
 
Arbeitswelt2020 pecha kucha
vonUniversity St. Gallen
 
Von Kutschern, Managern und Systemadministratoren
vonJohann-Peter Hartmann
 
Agility Brainfucks - Von Menschen, Bildern und Steampunk-Management mit Notizen
vonGerrit Beine
 
Anforderungen haben immer Schuld
vonFrank Düsterbeck
 
Vom Entwickler zur Führungskraft
vonJohann-Peter Hartmann
 
Planlos mit Plan
vonFrank Düsterbeck
 
Portfolio Kanban
vonStefan ROOCK
 
Lügen, schlimme Lügen und IT-Verträge
vonJohann-Peter Hartmann
 
GPM Vortrag: Modernes Management von Softwareprojekten
vonFrank Düsterbeck
 
Scrum als agiles Vorgehensmodell für Programmierer
vonTobias Schlüter
 
Arbeitswelt2020PechaKucha
vonElsy Zollikofer
 
Software-Entwicklung Im Team
vonStephan Schmidt
 
NewWork in der Praxis
vonJohann-Peter Hartmann
 
Reparier Deine Unternehmenskultur!
vonJohann-Peter Hartmann
 
50 mal produktiver - oder warum ich gute Teams brauche und nicht gute Entwick...
vonMayflower GmbH
 
Agile Führung - echt jetzt?
vonAgile Usergroup Unterfranken
 
Warum die it nicht um new work herumkommt
vonJohann-Peter Hartmann
 

Andere mochten auch

PDF
JavaScript Security
vonJohann-Peter Hartmann
 
PDF
DevOps beyond the Tools
vonJohann-Peter Hartmann
 
PPTX
Javascript Security
vonjgrahamc
 
PDF
Java script security for java developers
vonJohann-Peter Hartmann
 
PDF
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
PDF
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
PDF
Leadership in der IT
vonJohann-Peter Hartmann
 
PDF
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 
JavaScript Security
vonJohann-Peter Hartmann
 
DevOps beyond the Tools
vonJohann-Peter Hartmann
 
Javascript Security
vonjgrahamc
 
Java script security for java developers
vonJohann-Peter Hartmann
 
How not to screw the operating system of your startup
vonJohann-Peter Hartmann
 
Wetware Bugs and Refactoring
vonJohann-Peter Hartmann
 
Leadership in der IT
vonJohann-Peter Hartmann
 
JavaScriptDays: vom 10 Tage Hack zur ersten Universalsprache?
vonJohann-Peter Hartmann
 

Ähnlich wie RoofTop Brains & BBQ: Ein Gästbuch für China

PPTX
REST: Versprechen, Wirklichkeit & Alternativen: GraphQL, GRPC, JSON RPC...
vonpredic8
 
PDF
Microservices und das Entity Control Boundary Pattern
vonBrockhaus Consulting GmbH
 
PDF
DACHNUG50 Domino REST API - Konzepte und Hintergruende.pdf
vonDNUG e.V.
 
PDF
Diplomarbeit
vonMarkus Möller
 
ODP
Microservice-Architektur in der Praxis
vongedoplan
 
PDF
10 Dinge die ich an dir hasse - Stolpersteine in der Webentwicklung
vonSebastian Springer
 
PDF
JavaScript: Von einfachen Scripten zu komplexen Anwendungen
vonmolily
 
PDF
API-Design, Microarchitecture und Testing
vonOPEN KNOWLEDGE GmbH
 
PPT
SCD13: Shopware goes responsive
vonshopware AG
 
PDF
Microservices Architecture: Architektur und Patterns
vonOPEN KNOWLEDGE GmbH
 
PDF
Webapplikationen mit Node.js
vonSebastian Springer
 
PDF
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
vonadesso AG
 
KEY
Good by Server... Hello Client!
vonSandro Sonntag
 
PDF
Microfrontends zur Rettung - Frontends auf Anwendungsebene modularisieren
vonMark Lubkowitz
 
PDF
Bachelor%20thesis%20Willi%20Tscheschner
vontutorialsruby
 
PDF
Bachelor%20thesis%20Willi%20Tscheschner
vontutorialsruby
 
PDF
Eclipse Magazin 16 - Die Stärke der Drei
vonHeiko Seeberger
 
PDF
Google App Engine. Zwei Jahre im Produktiveinsatz
vonPer Fragemann
 
PDF
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
vonadesso AG
 
PPTX
06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP
vonChristian Guenther
 
REST: Versprechen, Wirklichkeit & Alternativen: GraphQL, GRPC, JSON RPC...
vonpredic8
 
Microservices und das Entity Control Boundary Pattern
vonBrockhaus Consulting GmbH
 
DACHNUG50 Domino REST API - Konzepte und Hintergruende.pdf
vonDNUG e.V.
 
Diplomarbeit
vonMarkus Möller
 
Microservice-Architektur in der Praxis
vongedoplan
 
10 Dinge die ich an dir hasse - Stolpersteine in der Webentwicklung
vonSebastian Springer
 
JavaScript: Von einfachen Scripten zu komplexen Anwendungen
vonmolily
 
API-Design, Microarchitecture und Testing
vonOPEN KNOWLEDGE GmbH
 
SCD13: Shopware goes responsive
vonshopware AG
 
Microservices Architecture: Architektur und Patterns
vonOPEN KNOWLEDGE GmbH
 
Webapplikationen mit Node.js
vonSebastian Springer
 
Wozu Portlets – reichen HTML5 und Rest nicht aus für moderne Portale?
vonadesso AG
 
Good by Server... Hello Client!
vonSandro Sonntag
 
Microfrontends zur Rettung - Frontends auf Anwendungsebene modularisieren
vonMark Lubkowitz
 
Bachelor%20thesis%20Willi%20Tscheschner
vontutorialsruby
 
Bachelor%20thesis%20Willi%20Tscheschner
vontutorialsruby
 
Eclipse Magazin 16 - Die Stärke der Drei
vonHeiko Seeberger
 
Google App Engine. Zwei Jahre im Produktiveinsatz
vonPer Fragemann
 
Vergleich des Scala Web-Frameworks Lift mit dem Java EE Programmiermodell
vonadesso AG
 
06 Software Development Guidelines der COMLINE Cloud Service Platform - CSP
vonChristian Guenther
 

Mehr von Johann-Peter Hartmann

PPTX
The End of my Career
vonJohann-Peter Hartmann
 
PDF
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
PDF
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
PDF
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
PDF
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
KEY
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 
PDF
Surviving Complexity
vonJohann-Peter Hartmann
 
The End of my Career
vonJohann-Peter Hartmann
 
E-Commerce vs Architektur CodeTalks.Commerce_2018
vonJohann-Peter Hartmann
 
JavaScript und Security - JavaScript Days 2013 Berlin
vonJohann-Peter Hartmann
 
Profiling for Grown-Ups
vonJohann-Peter Hartmann
 
Serverside Cryptoparty
vonJohann-Peter Hartmann
 
Paradigmenwechsel bei webapplikationen
vonJohann-Peter Hartmann
 
Surviving Complexity
vonJohann-Peter Hartmann
 

RoofTop Brains & BBQ: Ein Gästbuch für China

  • 1.
    Ein Gästebuch mit Node.js. FürChina. Ja, ganz China Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.
  • 2.
    „Skalieren von WebApps istein gelöstes Problem.“ Ich, klugscheissend Gehen wir also zurück zur Ausgangsfrage. Eine Gästebuch auf der Basis von Node.js für China, ganz China.
  • 3.
    Wer nutzt Node.js produktiv? Erstmal ein paar Abfragen. Ich bin selbst eher Generalist als Spezialist, deshalb freue ich mich immer, wenn ein paar Spezialisten dabei sind. Die dann die speziellen Fragen beantworten können, die ich nicht beantworten kann :-)
  • 4.
    Wer nutzt Docker produktiv? Werhier nutzt Docker produktiv?
  • 5.
  • 6.
    Wer nutzt MicroServices auf Basisvon Docker & Node.js? Und wer nutzt MicroServices auf der Basis von Docker, in Node.js? Wer in Go? Rust? Haskell? Clojure?
  • 7.
    Wir machen dasauch. Aber warum?
  • 8.
    ä Weil es geradeauf der Mitte des Hypecycles angekommen ist, und es jetzt einfach jeder machen muss? Oder gibt es auch gute Gründe?
  • 9.
    Software Architecture is not about lookingcool in front of your friends. Schliesslich ist Softwarearchitektur kein Gefährt, auf dem man seine eigene Coolness produzieren will. Aber es gibt tatsächlich ein paar gute Gründe, warum man MicroServices machen will.
  • 10.
    ä Neue Projekte machenSpass. Dinge neu beginnen, mit guten Tools, das ist einfach. Man ist sehr produktiv.
  • 11.
    ä Boilerplate Useful Code Und klar,die entstehende Software sieht ja auch super aus. Sie ist klein, wir haben weitgehend nützlichen Code, der wirkliche Dinge tut, nur wenig Boilerplate, und wir verstehen, was da passiert.
  • 12.
    Und am Endehabe ich eine Software, die gut funktioniert und genau das tut, was sie machen soll. Unsere Nutzer lieben das, endlich mal was, was wenig Aufwand gekostet hat und gut funktioniert.
  • 13.
    Und deshalb wollensie noch mehr davon, und verlangen nach mehr Funktion, und die bauen wir dann auch ein.
  • 14.
    Und am Endesieht unsere kleine Software so aus.
  • 15.
    ä WTF?! Boilerplate Useful Code Die klassischeSpaghetti-Lösung hat zwar immer noch Boiler-Plate-Code und funktionalen Code, aber ebenfalls auch viel Code, der nur noch da ist, weil sich niemand traut ihn zu löschen. Code, bei dem Dinge mehrfach vorkommen, wenn auch zum Teil leicht verändert. Bei dem der Technical Debt hoch ist.
  • 16.
    Und wir allekennen das Gefühl, wenn man mit aller Energie nur noch einen Big Ball of Mud langsam bewegt? Und es macht weder richtig Spass, noch kommt man gut voran? Und immer wieder, wenn man in Mist fasst denkt man „ok, das sollte man jetzt prinzipiell sauber machen“ - tut es aber nicht, weil keine Zeit dazu da ist?
  • 17.
    Könnte ich inZukunft bitte - weniger Redundanz - weniger Komplexität - mehr Vorhersehbarkeit - mehr Verlässlichkeit bekommen? in der Situation fragt man sich, ob man nicht bitte in Zukunft weniger Redundanz, weniger Komplexität, mehr Vorhersehbarkeit und mehr Verlässlichkeit bekommen kann …
  • 18.
    Und klar kannman. Eigentlich wussten wir ja schon wie das geht, und deshalb hat die Gang of Four das 1994 aufgeschrieben. Eigentlich hätten wir es also schon immer wissen können, und hätten es also auch von Anfang an vermeiden können :-)
  • 19.
    Brauche ich beikleinen Projekten nicht, deshalb vergessen wir es bei jeder neuen Sprache erst mal :-) Und warum vergessen wir es jedes mal wieder? Weil wir es bei kleinen Lösungen nicht brauchen. Das Problem entsteht erst mit Wachstum der Software, die nicht mehr in unser Hirn passt.
  • 20.
    Die Design Patternserzeugen Vorhersehbarkeit, klare Verantwortung und eine klare Zuordnung von Tätigkeiten zu Code.
  • 21.
    Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Das istso eine typische Verteilung von Verantwortung - eine layer-basierte Architektur. So sehen bis heute viele grössere Webapplikationen aus. Wer hat schon einmal an so einer Applikation mit diversen Layers gearbeitet? Genau, ich auch.
  • 22.
    Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Und auchin den Layers hat alles seinen Platz. Inzwischen haben wir sogar im JavaScript ein MVC-Design, das gleiche im Frontend-Layer, das gleiche dann noch mal im Rest-Service Layer dahinter, unter dem dann final ein Business Object layer liegt.
  • 23.
    Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest/ REST Unit-Tests Und weil wir jetzt ja mit Qualität arbeiten gibt es auch noch diverse Testumgebungen, die das ganze stabilisieren. Meist wird die Business-Logik lokal mit Unit Tests stabilisiert, das Backend-Layer mit REST-Integrationstest und das Frontend mit Akzeptanztests.
  • 24.
    „Bitte zweiten Vornamen einführen.“ Wer -wie ich - solche Architekturen schon mehrfach gebaut hat, ist nach einer Weile genervt von Ihnen. Spätestens, wenn der Pointy Haired Boss um die Ecke kommt und fragt, ob er bitte den zweiten Vornamen ins Formular haben kann.
  • 25.
    Client-Layer Frontend-Layer Backend-Layer Business-Object Layer View Controller Model View Controller Model View Controller Model Business-Objects ORM Acceptance Tests Integrationstest/ REST Unit-Tests Und dann muss man tatsächlich die Acceptance Tests, den View, den Controller, das Model, den Controller, das Model, den REST-Test, den Unit-Test, das Business- Object und das ORM anfassen, und die Datenbank ändern.
  • 26.
    1 Concern soseparated, dass wir 12 mal Code anfassen müssen. Wir haben tatsächlich die Software vorhersehbar gemacht, aber dabei aus einem Concern eine Sache gemacht, die in 12 mal Code anfassen resultiert.
  • 27.
    Client-Layer Frontend-Layer Backend-Layer Business-Object Layer Everyf*ckingfunctionality Das istauch kein Wunder - denn die Business-Aspekte treten jeweils in jeder Schicht einmal auf.
  • 28.
    Solche Architekturen werdenvon den MicroService-Jungs gerne Lasagne-Architekturen genannt. Sie bestehen aus vielen Schichten,und wenn ich was will, muss ich durch alle durch :-) .
  • 29.
    Ein Gästebuch mit Node.js. FürChina. Ja, ganz China Ok, aber eigentlich sind wir ja für China hier. Und China wartet jetzt, auf Slide 28, immer noch auf sein Gästebuch.
  • 30.
    Gucken wir dochmal, was wir da so brauchen. Ganz China klingt ja schon mal enterprisig. Schauen wir uns das mal im Detail an.
  • 31.
    1.400.000.000 Personen China, das sindzur Zeit etwa 1.4 Milliarden Menschen. Etwa jeder siebte Mensch ist Chinese.
  • 32.
    55% 721.434.547 Personen mit Internet Teilmeiner Überlegung war, dass vermutlich sehr wenige von denen das Internet nutzen. Das stimmte aber nicht - mehr als die Hälfte nutzt das Internet. Das sind zwar noch immer weniger als die 80% der Einwohner hier, trotzdem mehr als 10 mal so viele Internetnutzer.
  • 33.
    1 Besuch proWoche Ansicht, Blättern, Eintrag, Ansicht Gehen wir mal davon aus, dass man so ein Gästebuch überschaubar nutzt. Man besucht es einmal pro Woche, also 52 mal im Jahr.
  • 34.
    1 Besuch proWoche 3 GET, 1 POST Startseite Blättern Eintragen Angucken Und der durchschnittliche Besuch sind 4 Anfragen, die an dynamischen Content gehen. Startseite, einmal blättern, einmal eintragen, angucken, und wieder weg.
  • 35.
    2.885.738.188 Req /Woche 412.248.313 Req / Tag 4.771 Req / Sekunde Das sind dann pro Woche ja nur knappe 3 Milliarden Requests. Am Tag sind das 412 Millionen Requests, weil die Gästebücher nicht saisonal sind - bei e-Commerce hätte man da mehr drauflegen müssen. Macht pro Sekunde 4771 Requests.
  • 36.
    5.000 Req/Sekunde Average 10.000Req/Sekunde Peak = 2500 POST &7500 GET Also gehen wir mal von einem Average von 5000 Requests aus, die wir für die Peakzeiten bequem auf 10.000 Requests pro Sekunde hochskalieren müssen. Pro Sekunde sind das 2500 Posts und 7500 Gets,umgerechnet. Das ist wichtig für das Caching - es muss 2500 mal pro Sekunde aktualisiert werden. 2500 mal pro Sekunde, das ist das Der Ton ist das Dis ganz rechts auf der Klaviertastatur, also Taste 79 von 88.
  • 37.
    POST: 100.000 LPUSH/s GET:50.000 LRANGE/s Benötigt: 2.500 POST 7.500 GET 10.000 Req/s Ok, gucken wir mal, ob das machbar ist. Erster Kandidat: Redis. Redis haben wir schon bei ein paar dicken Applikationen im Einsatz, das kann das gut. und ich habe es noch mal extra auf einem normalen, etwas dickeren Amazon-Server (c3.large) gemessen, da komme ich bequem im Redisbenchmark auf 100.000 LPUSH, mit dem ich Daten in eine Liste eintrage, und auf 50.000 LRANGE-Leserequests, bei denen ich die letzten 10 Einträge abhole. Das ist doch cool.
  • 38.
    >100.000 Req/s Benötigt: 10.000Req/s 10.000 Req/s Und, kann das auch der Webserver? Je nach Amazon-Klasse kann ein nginx-Node unterschiedliche Requests, praktisch sind es aber fast immer 6-stellige Zahlen. Also: kein Problem.
  • 39.
    >50.000 Req/s Benötigt: 10.000Req/s 10.000 Req/s Und node.js selbst? Wenn er eine CPU für sich alleine bekommt, dann kann er auf den 4 Cores bequem 50.000 Requests in der Sekunde abfackeln. Die Rahmenbedingungen sind also gegeben.
  • 40.
    Das ist dochmachbar. Aller Erfahrung nach sollte das also gehen.
  • 41.
    Und zwar aufeinem einzigen Rechner. Und zwar auf einem einzigen Rechner. 2 CPUs mit jeweils 4 Kernen, sollte gehen.
  • 42.
    Klar geht das. Miteinem HelloWorld. Der Nachteil an der Überlegung: das geht, klar. Mit einem hello-World-Script. Wenn meine Software darüber hinaus geht sieht es anders aus.
  • 44.
    Was im Requestpassiert Kernel Serverprocess Compiler/Interpreter Applikation Aber schauen wir uns das mal im Detail an. Wenn der Request auf dem Webserver landet, dann ist das erst mal ein Interrupt auf Hardware-Eben, der dann den Kernel veranlasst, eines seiner Module danach zu befragen, was damit geschehen sollte. Das liest die Daten aus und gibt sie an den Servierprozess weiter, und der wirft den Compiler/Interpreter an. Und erst da beginnt die Applikation.
  • 45.
    Was im Requestpassiert 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befüllen 13.Template rendern 14.Response erstellen Und da beginnt erst die richtige Arbeit. Der Request muss vom Framework geparsed werden. Dann wird der Router angeworfen, um herauszufinden, welcher Controller sich darum kümmert. Dann wird dieser angeworfen, und muss erst mal gucken, welche Daten da von ihm von draussen kamen. Und dann denkt er über diese Daten nach, und findet heraus, was auf dieser Basis er von der Datenbank holen soll. Also einen Datenbankrequest gebaut, den über Kernel zur DB, dort bearbeitet, wieder zurück, Ergebnis demarshallen, Aufbereiten, damit rechnen, das Template initialisieren, befüllen und rendern, und dann dem Webserver zur Ausgabe geben.
  • 46.
    Was im Requestpassiert Applikation: 1. Request parsen 2. Router -> Controller 3. Controller starten 4. Wenn da Daten sind: URL/Body-Parser 5. DB-Request Erstellen 6. IO zur DB 7. (ORM-Foo hin & zurück) 8. IO von der DB 9. DB-Ergebnis aufbereiten 10.Werte errechnen 11.Template initialisieren 12.Template befallen 13.Template rendern 14.Response erstellen Nimmt man die ganzen Indirektionen und Abstraktionen raus, dann gibt es eigentlich nur 3 Dinge wirklich zu tun - Request verstehen, Wert berechnen und wieder zurückgeben. Die Datenbank könnte ich ja auch selbst im Ram halten.
  • 47.
    Was im Requestpassiert Real Code Boilerplate Language Prozess Kernel Die wahre Ressourcennutzung in meinem Request liegt also nicht im Funktionalen Code, sondern in der ganzen Boilerplate drumherum. Etwas ist zwangsläufig, weil wir einen Kernel mit Prozessen etc haben, vieles ist aber die Boilerplate unserer Programmierumgebungen.
  • 48.
    Fun Fact 1:
 Bei PHP-Symfony- Applikationen liegt der funktionale Anteil 
 unter 0.1 %. Ich kenne das selbst sehr gut aus Consulting-Projekten im PHP-Bereich: der tatsächlich relevante Code ist nur ein Bruchstück dessen, womit die CPU ihre Zeit verbringt. In diesem Kontext - bei Symfony, das ist quasi Spring für PHP, liegt es praktisch immer unter 0.1%.
  • 49.
    0 750 1500 2250 3000 Request / Sekunde Node.jsnativ Node.js Express-Routing Node.js Express + Jade-Template Fun Fact 2: Dito Node.js Bei Node.js ist es aber auch nicht wirklich besser. In meiner lokalen Testumgebung auf einem i7-Core, ohne Virtualisierung konnte die gleiche Gästebuchapplikation mit nativem Code etwa 2500 Request, mit express als Framework etwa 1500 Requests - und mit Jade zur Ausgabe bei nur einem Template, aber einer Schleife nur noch 50. Hier wirken also 98% Boilerplate.
  • 50.
    Fun Fact 3:
 Das Gästebuch als Kernelmodul würde auf einem Raspberry PI China versorgen. Und noch ein Fun-Fact: wenn wir das ganze als Kernelmodul in C direkt auf dem ethernet-Driver programmieren würden, könnten wir China vermutlich mit einem Raspberry PI versorgen.
  • 52.
    Wäre es dannzum Skalieren nicht viel sinnvoller auf den funktionalen Code zu fokussieren? Da stellt sich die Frage: wenn ich so viele Dinge mache, die eigentlich nur Boilerplate sind, damit der Code sich um sich selbst kümmern kann und der Entwickler auf der Ebene höherer Konstrukte arbeitet, wäre es nicht besser, bei skalierbaren Applikationen den Fokus auf den echt wirksamen Code zu setzen?
  • 53.
    Und davon dannfür jede Funktion eine kleine Applikation anbieten, die genau diese Sache schnell & skalierbar macht? Man könnte dann ja die ganze grosse Applikation in kleine Scheiben schneiden, die für den jeweiligen Aspekt im wesentlichen aus viel Funktion und wenig Boilerplate bestehen. Und diese Scheiben wären dann echt schnell und skalierbar.
  • 54.
  • 55.
    Ack, und daskönnten wir dann „MicroServices“ nennen. Ja, könnte man machen, und das könnte man dann MicroServices nennen. Die Jungs, die damit angefangen haben - und damit meine ich vor allem Amazon und Konsortien - haben genau diese Aufgabe und diesen Plan gehabt. Wenn ich viele Millionen Server habe ist es wichtig, ob ich 0.1%,1% oder 80% der CPU für echte Funktion nutze. 100 mal mehr Server, dafür aber schönerer Code - das ist schwer zu verargumentieren.
  • 56.
    „The services are small- fine-grained to perform a single function.“ Schauen wir uns doch mal die Quasioffizielle Definition von MicroServices in der Wikipedia an: the die Services sind kleingeschnitten, so dass sie nur eine einzige kleine Funktion erfüllen.
  • 57.
    Each service iselastic, resilient, composable, minimal, and complete. Sie sind elastisch, minimal, vollständig und man kann sie verdrahten.
  • 58.
    The culture anddesign principles should embrace failure and faults, similar to anti-fragile systems. Damit ich das brauchbar machen kann, brauche ich eine Kultur der Fehlertoleranz. Ich muss es überleben, wenn ein paar von denen zeitweilig weg sind.
  • 59.
    The organization culture shouldembrace automation of deployment and testing. Und am Ende soll die Organisationskultur das ganze auch automatisieren können, damit ich schnell skalieren kann - und auch schnell entwickeln kann. Und während ich die Aspekte Agilität, Developereffizienz und Agilität normalerweise liebe, verzichte ich heute zugunsten der Zeit und der Skalierbarkeit darauf.
  • 60.
    ä MicroServices „Applications that fit inyour head. Eine ebenfalls schöne Definition ist : Applikationen, die in den Kopf passen.
  • 61.
    ä MicroServices „Applications that fit inyour head. Boilerplate Useful Code Boilerplate Useful Code Boilerplate Useful Code Also: ganz viele kleine Greenfields.
  • 62.
    ä MicroServices Node.js Docker WTF Node.js &Docker?! Ok, MicroServices macht also Sinn - aber warum, um Himmels Willen, nodejs? Und warum bitteschön Docker? Kann
  • 63.
    ä Es skaliert gut… … über Entwickler Die Antwort darauf ist einfach - beide Werkzeuge skalieren sehr gut über die Ressource, die in unserer Branche am wenigstens vorhanden ist - Developer.
  • 64.
    ä „Applications that fit intheir heads. Aber das sind doch alles Anfänger! Und klar gibt es dann immer das Argument, dass die Heerscharen der Docker- und Node-JS-Nutzer viele Juniors enthalten. Und klar ist die Antwort: Ja, natürlich, wenn das alles nur Seniors wären, dann wären das ja auch nicht viele Entwickler. Aber es gibt einen Vorteil: MicroServices sind genau darauf eingestellt. Einen Junior kann man deutlich besser mit einem MicroService als mit einem Monolithen betreuen. Die kleinere, einfacher zu verstehende Software.
  • 65.
    ä „Applications that fit intheir heads. Yep, MicroServices eignen sich gut für Anfänger. Das klingt jetzt total doof, ist aber trotzdem so- MicroServices eignen sich gut für Anfänger. Das ist quasi ein Abfallprodukt des Initialplans.
  • 66.
    „Elastic“, „fine-grained“, „automated“ deployed, „failure“& „fault“- tolerant? Und bei Docker sprechen auch viele andere Dinge für den Einsatz bei MicroService-Architektur
  • 67.
    Und das habenauch viele andere gemerkt. Google sagt, es gäbe zur Zeit etwa eine halbe Million Treffer zu Docker und MicroServices, und praktisch seit 2014/15 kommen beide häufig nicht alleine zur Party. Die Trefferzahl zu JavaScript bzw. Nodejs MicroServices liegt auf dem gleichen Niveau.
  • 68.
    Tools für eine MicroService- Orchestrierungmit Docker Wie sieht das also konkret aus, wenn ich Docker und MicroServices für die Orchestrierung von, sagen wir mal, einem hochskalierbaren Gästebuch einsetzen will. Ich werde zunächst die Mitspieler vorstellen, und dann kurz den Einsatz an einem echten Beispiel zeigen.
  • 69.
    Outing 1: Ja, esgibt auch andere Tools, die das können. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.
  • 70.
    Outing 2: Der aktuelleRC von Docker hat vieles Builtin. Und kaputt. Das ist längst nicht der einzige Lösungsweg, man könnte das auch mit Kubernetes, Rancher, Mesos, Deis und vielen anderen machen - ich bleibe heute bei den Docker- eigenen Tools.
  • 71.
    Tools: Docker - Container-CLI -Erstellen von Images - Veröffentlichen von Images - Remote-Interface zum Docker-Host - Daemon/ Docker-Host - Rest-Service als Interface auf Port - Starten, stoppen, laden von Images Beginnen wir mit Docker. Die, die es schon kennen, langweilt es vermutlich eher.
  • 72.
    Tools: Docker Machine -Maschinen mit Docker-Host erzeugen - auf VirtualBox - Amazon Eck - Digital Ocean … - Verwaltung der Maschinen - Docker-CLI auf die Maschine wechseln - Listen , Stoppen etc Das nächste Tool der Wahl ist Docker-Maschine. Da kommen die kleinen DOCKER_HOSTS her, mit diversen Interfaces.
  • 73.
    Tools: Docker Swarm -Docker über mehrere Server - Gemeinsamer Docker-Host - Swarm-Manager mit Fail-Safety - neue Server können Joinen - mit Event-Bus Etwas frischer ist der Docker Swarm, der gerade in der Version 1.0 rausgekommen ist - und vor 2 Wochen gab es dazu die Swarm Week mit vielen Blogartikeln. Ich mag swarm, weil er Dinge, die sonst kompliziert sind (Hallo, Kubernetes), auf einem recht überschaubarem Dilletantenniveau hält.
  • 74.
    Tools: Swarm-Mode - Neuin Docker 1.12 - Scaling vorhanden - Service Discovery über DNS - Ingress Load Balancing - Rolling Updates! Now: BuiltIn Swarm-Mode Inzwischen - mit dem aktuellen Release-Candidate - ist der Swarm-Mode default-Bestandteil von Docker.
  • 75.
    Tools: Docker Compose -Docker-Cluster anlegen - YAML-Konfiguration über docker- compose.yaml - Anlegen von Services/Containern - Anlegen von Netzwerken - Anlegen von gemeinsamen Devices - Skalieren von Services! Damit die diversen Docker-Service mit einander zurecht kommen gibt es Docker Compose. Docker Compose bekommt eine wirklich einfache Yaml-Datei, mit der man nicht nur die Services und Ihr Zusammenspiel orchestrieren kann, sondern auch gemeinsame Volumes und Netzwerke einrichten kann. Und so geil das Tool ist, ein paar Lücken gibt es noch - zB. klappt das verteilen von lokal gebauten Images noch nicht im Schwarm, da muss also die eigene Registry her, wenn man den bedienen will.
  • 76.
    Tools: Consul - Key-Value-Storagezur Verwaltung - Fail-Safe - DNS-Support - Support von Docker Swarm - eigentlich „Konsensus-Tool“ Ebenfalls schon länger mit dabei: Consul als Key-Value-Store, der zur Verwaltung der Daten genutzt wird. Er ist Cluster-fähig, und eine der Backends, das vom Docker Swarm verwendet werden kann.
  • 77.
    Tools: Interlock - Event-Plugin-System -Lauscht auf dem Event-Bus eines Swarm - Startet Plugins: - nginx - haproxy - ergänzt neue Container in nginx/ haproxy ein Und kommen wir zum letzten Tool der Orchestrierung: Interlock. Interlock nennt sich selbst ein Event-Plugin-System, das alle Events aus dem Docker-Schwarm mitbekommt - also zB neue Container, die joinen. Und wenn er erkennt, dass diese Container zu http geroutet werden sollen, dann aktualisiert er den dazugehörigen Proxy oder Webserver.
  • 78.
    1. Eine Node-Appzu einem Container 
 machen DockerFile-> ATOM Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerfile.
  • 79.
    docker build -tjohannhartmann/ noderedis . docker push johannhartmann/noderedis Als erstes müssen wir unsere Node-App zu einem Docker-Container machen - das geht ganz einfach über ein Dockerfile.
  • 80.
  • 81.
    Aber kommen wirmal zur konkreten Architektur: Draussen wohnt das Internet, hier drinnen wohnen wir - mit 4 Host-Nodes, einem Redis-Node, einem Manager und dem Interlock/Redis-Node als Manager.
  • 82.
    Manager-Maschine:
 Consul starten docker run--restart=unless-stopped -d -p 8500:8500 -h consul progrium/ consul -server -bootstrap Jetzt habe ich also ganz viele Maschinen, und die sollen zu einem Schwarm werden. Und ich beginne mit Consul, dem Storage für den Schwarm.
  • 83.
    Manager-Maschine: Swarm-Manager starten docker run--restart=unless-stopped -d -p 3375:2375 swarm manage consul://192.168.33.11:8500/ Damit der Schwarm auch tatsächlich einer werden kann starte ich einen Schwarm-Manager. Das können wie bereits gesagt mehrere sein, in diesem Beispiel nutze ich aber nur einen. Der Schwarm-Manager lauscht selbst, wie der Docker-Host sonst auch, auf Port 2375 bzw. 2376 bei tls. Weil ich den Port auf dem Host schon für den normalen Docker-Container nutze, muss ich hier auf Port 3375 ausweichen.
  • 84.
    Manager-Maschine: Nodes registrieren docker -H=tcp://192.168.33.20:2375 run-d swarm join -- advertise=192.168.33.20:2375 consul://192.168.33.11:8500/ Ein Schwarm ohne weitere Rechner nutzt mir aber nichts. Deshalb registriere ich mal alle anderen Maschinen - beginnend mit den Workern. Die Registration sieht ähnlich dem swarm manage von eben aus, nur jetzt mit dem Kommando join. Er soll sich selbst für den Swarm als Docker-host bekannt machen, und zwar auf der IP 192.168.33.20. Und für die Datenverwaltung soll er auf den Consul-Service auf dem Manager-Node zurückgreifen.
  • 85.
    Manager-Maschine: Redis, Interlock, Manager docker-H=tcp://192.168.33.250:2375 run -d swarm join -- advertise=192.168.33.250:2375 consul://192.168.33.11:8500/ … Die gleiche Registration passiert auch auf den anderen Maschinen.
  • 86.
    Wenn sie gejointhaben kann ich mir die vollständige Liste der Container - also der Container, die auf den beteiligten Docker-Hosts laufen, wenn auch nicht im Swarm - wieder mit docker ps -a angucken.
  • 87.
    Manager-Maschine: Overlay Network docker networkcreate --driver overlay mynet Auch die Docker-Netzwerk-Fähigkeiten lassen sich in dem Swarm nutzen - Voraussetzung it allerdings, dass hier der Key-Value-Storage, hier im Beispiel Consul, existiert. Dann kann ich mit diesem Befehl das Overlay-Network anlegen.
  • 88.
    Docker Compose: docker-compose.yml https://github.com/johannhartmann/chinaguestbook/blob/ master/docker-compose.yml Docker-Compose wirdüber die docker-compose.yml gesteuert. Diese Daten enthält alle relevanten Informationen über die Container selbst, den Netzwerke und die gemeinsame Volumes.
  • 89.
    Lokal: Compose-Cloud starten docker-compose build- öhm, doch nicht. docker-compose up Normalerweise würde man jetzt die Pakete für den Docker-compose bauen. Aber: Docker-Compose kann lokal gebaute Pakete noch nicht an einen Schwarm verteilen. Also muss ich sie vorher selbst pushen. Wenn ich das getan habe kann ich meine Cloud aber durchstarten. Das mache ich mit „docker compose up“ - und in Folge werden alle Images auf alle hosts gepullt, und dann anhand der Constraints auf den Hosts gestartet.
  • 91.
    Benchmark 1 Container Jetzt,wo meine Cloud - wenn auch nur mit einem Container - online ist, kann ich ja mal gucken, wieviel Durchsatz sie hat. Und tatsächlich - es sind nur 80 Requests/ Sekunde.
  • 92.
    Lokal: Compose-Cloud skalieren docker-compose scaleweb=100 Also müssen wir das skalieren. Das machen wir mit einem sehr einfachen Befehl - docker-compose scale web=100 - und schwupps, wird die Zahl der laufenden Container auf 100 erhöht. Weil diese Applikation CPU-Bound ist, muss ich schlicht etwa so viele container bauen, wie ich Kerne habe - denn mehr als 100% CPU-Last möchte ich nicht auf den Maschinen haben.
  • 93.
    Benchmark 100 Container Undtatsächlich - wenn ich 100 Container durchstarte auf den beiden grossen Hosts, dann bekomme ich genug Traffic für knapp ein halbes China. Sorry, dass ich hier nicht ganz China gedemoed habe - das war mir bei den m4.x10large-Images zu teuer :-) Aber es geht.
  • 94.
    Strategie für Micro- ServiceArchitekturen mit Node.js auf Docker 1. Node.js-Services klein schneiden und einzeln als Container paketieren Also, mal alles zusammengenommen: ich zerlege meine App in mehrere Services, die jeweils für sich autark laufen. Jeden dieser Services packe ich in einen Docker-Container.
  • 95.
    2. Micro bedeutetauch die Chance, auf Boilerplate verzichten zu können, und das erzeugt Performance Strategie für Micro- Service Architekturen mit Node.js auf Docker Ich nutze die Chance, auf boilerplate und Libraries zu verzichten, wenn ich wirklich skalieren muss. Boilerplate & Frameworks haben einen Impact von Faktor 10 bis Faktor 1000. MicroServices erlauben mir, auch ohne Boilerplate Software zu überleben.
  • 96.
    3. diese Serviceskann man über docker-compose/swarm einfach skalieren Strategie für Micro- Service Architekturen mit Node.js auf Docker Wenn ich die Services in einem Container habe, fällt mir das skalieren leicht.
  • 97.
    4. und überDienste wie interlock auch unmittelbar nach aussen freigeben. Strategie für Micro- Service Architekturen mit Node.js auf Docker Über Dienste wie interlock integriere ich neue Dienste oder zusätzliche Container implizit, ohne dass zusätzlicher Aufwand ensteht. Mit den aktuellen Docker-Tools ist die Schwelle zur Konfiguration und zur Nutzung deutlich geringer geworden, als dies vorher der Fall war. Ich habe den Komfort von PAAS, ohne mich an einen Anbieter binden zu müssen.
  • 98.
    Ich brauche 4 m4.10xlargeHosts für China mit Jade. China-Fazit:
  • 99.
    Die Docker-Welt hat immernoch viele Bugs und wenig Doku.
  • 100.
    Es wird trotzdemein Commodity-Ding für alle.
  • 101.
  • 102.
  • 103.
    ä Wenn man dasso macht, dann hat die Arbeit wieder deutlich mehr Greenfield-Feeling.
  • 104.
    Files: https://github.com/johannhartmann/chinaguestbook Slides: http://slideshare.net/johannhartmann Video: Slideshareembedded (Mal ehrlich: ich hätte es trotzdem mit PHP gemacht :-) Vielen Dank!