Wie man mit MicroServices beliebig skaliert

1. 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.

2. „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.

3. 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 :-)

4. Wer nutzt Docker
produktiv?
Wer hier nutzt Docker produktiv?

5. Wer nutzt
MicroServices
produktiv?
Und wer nutzt MicroServices?

6. 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?

7. Wir machen das auch. Aber warum?

8. ä
Weil es gerade auf 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
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.

10. ä
Neue Projekte machen Spass. 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 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.

13. Und deshalb wollen sie noch mehr davon, und verlangen nach mehr Funktion, und die bauen wir dann auch ein.

14. Und am Ende sieht unsere kleine Software so aus.

15. ä
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.

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

17. 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
…

18. 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 :-)

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

20. Die Design Patterns erzeugen Vorhersehbarkeit, klare Verantwortung und eine klare Zuordnung von Tätigkeiten zu Code.

21. 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.

22. 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.

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

27. 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.

28. 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 :-) .

29. 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.

30. Gucken wir doch mal,
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 sind zur Zeit etwa 1.4 Milliarden Menschen. Etwa jeder siebte Mensch ist Chinese.

32. 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.

33. 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.

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

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

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

39. >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.

40. Das ist doch machbar.
Aller Erfahrung nach sollte das also gehen.

41. Und zwar auf einem
einzigen Rechner.
Und zwar auf einem einzigen Rechner. 2 CPUs mit jeweils 4 Kernen, sollte gehen.

42. 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.

44. 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.

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

46. 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.

47. 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.

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

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

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

54. Ravioli instead of
Lasagna or Spaghetti

55. 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.

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 is elastic,
resilient, composable,
minimal, and complete.
Sie sind elastisch, minimal, vollständig und man kann sie verdrahten.

58. 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.

59. 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.

60. ä
MicroServices
„Applications that fit
in your head.
Eine ebenfalls schöne Definition ist : Applikationen, die in den Kopf passen.

61. ä
MicroServices
„Applications that fit
in your 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
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.

65. ä
„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.

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

68. 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.

69. 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.

70. 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.

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

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

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

79. 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.

80. 2. Einen Schwarm
erzeugen

81. 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.

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

87. 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.

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

93. 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.

94. 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.

95. 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.

96. 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.

97. 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.

98. Ich brauche 4
m4.10xlarge Hosts
für China mit Jade.
China-Fazit:

99. Die Docker-Welt hat
immer noch viele Bugs
und wenig Doku.

100. Es wird trotzdem ein
Commodity-Ding
für alle.

101. Die aktuellen LargeScale-
Tools werden Commodity.

102. Kleine Services, wenig
Boilerplate.

103. ä
Wenn man das so macht, dann hat die Arbeit wieder deutlich mehr Greenfield-Feeling.

104. 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!