WEBVTT 00:00:00.238 --> 00:00:02.905 Willkommen im Maschinenraum. Wir sind heute zu Gast bei Softwarearchitektur 00:00:02.905 --> 00:00:06.995 im Stream und reden über Simple Cloud in der Praxis. Mein Name ist Lucas Domen 00:00:06.995 --> 00:00:08.885 und ich bin Principal Consultant bei SWAGLab. 00:00:09.375 --> 00:00:13.975 Und zu Gast habe ich heute Dirk Breuer. Hallo Dirk, magst du dich mal kurz vorstellen? 00:00:14.785 --> 00:00:20.535 Sehr gerne. Ich bin Dirk, ich bin freier Softwareentwickler seit sehr langer Zeit mittlerweile, 00:00:21.465 --> 00:00:24.875 und bin vor allen Dingen im Bereich Webentwicklung unterwegs, 00:00:24.875 --> 00:00:28.745 mache da so Betriebssachen auch mit und vor allen Dingen mit der Programmiersprache 00:00:28.745 --> 00:00:32.025 Ruby on Rails, was ich noch viel länger mache, als dass ich als freiberuflicher 00:00:32.025 --> 00:00:33.065 Softwareentwickler unterwegs bin. 00:00:34.825 --> 00:00:38.045 Super. Bevor wir ins eigentliche Thema starten, habe ich dir noch eine Frage 00:00:38.045 --> 00:00:42.525 mitgebracht. Wann hast du eigentlich das letzte Mal Production kaputt gemacht? 00:00:44.145 --> 00:00:47.725 Also das genaue Datum kann ich dir jetzt gar nicht genau sagen, 00:00:47.725 --> 00:00:52.115 aber allzu lange ist es nicht her und so ganz hart kaputt war es auch nicht, 00:00:52.115 --> 00:00:55.715 aber es war auf jeden Fall offline, ungeplant, es gab keine Wartungsseite und 00:00:55.715 --> 00:00:58.995 die Leute haben auf jeden Fall einen 503 gesehen, also zählt das glaube ich. 00:00:59.335 --> 00:01:04.425 Und zwar habe ich ja gesagt, ich mache hauptsächlich Rails und jeder, 00:01:04.425 --> 00:01:07.985 der das vielleicht schon mal benutzt hat, da gibt es sowas wie Datenbankmigration, 00:01:07.985 --> 00:01:11.845 die legt man an, super praktisch, die werden dann einfach immer ausgeführt beim Deployment, 00:01:12.565 --> 00:01:15.755 was auch in der Regel super ist, aber manchmal, wenn man Dinge tut, 00:01:15.755 --> 00:01:20.305 die vielleicht etwas länger gehen, so wie größer angelegte Indizes ändern oder eine, 00:01:21.505 --> 00:01:24.405 Stored Functions ändern, die auch die andere dann brauchen und man dann nicht 00:01:24.405 --> 00:01:27.405 daran gedacht hat, ah, das wird gleich deployed, da müssten wir vielleicht eine 00:01:27.405 --> 00:01:30.475 Wartungsseite online schalten, damit er das sauber durchführen kann, 00:01:30.845 --> 00:01:32.885 ja, dann geht dann schon mal die Produktion down. 00:01:34.085 --> 00:01:36.895 In der Regel ist es dann auch wieder in Ordnung, aber das war auf jeden Fall das letzte Mal. 00:01:37.495 --> 00:01:40.305 Ja, ich meine, das ist ja auch so ein Kritikpunkt an der Art und Weise, 00:01:40.305 --> 00:01:42.585 wie Ruby on Rails das macht. Ich meine, Ruby on Rails ist ja nicht die Einzigen, 00:01:42.585 --> 00:01:47.575 die das so machen, aber dass diese Migrations so ein bisschen Teil der Anwendung 00:01:47.575 --> 00:01:51.305 sind und so mitlaufen, das führt ja manchmal doch zu Problemen. 00:01:52.485 --> 00:01:58.335 Ja, das ist an vielen Stellen super praktisch, macht andere Probleme weniger. 00:01:58.875 --> 00:02:01.725 Aber in solchen Fällen muss man halt explizit daran denken, okay, 00:02:01.725 --> 00:02:06.525 du machst da eine Migration, die Einfluss darauf hat, die potenziell deine 00:02:06.525 --> 00:02:09.055 Produktion dann in dem Moment lahm legt. 00:02:10.145 --> 00:02:12.605 Merkst du halt nicht lokal und das merkst du in der Regel auch nicht, 00:02:12.605 --> 00:02:16.185 wenn du es auf Staging deployst, weil du da nicht die ganze Zeit drauf guckst 00:02:16.185 --> 00:02:19.325 während des Deployments. Da ist nicht die ganze Zeit Last drauf und ja. 00:02:20.545 --> 00:02:22.965 Ja, und ich finde auch, das ist auch so ein bisschen ein Zeichen dafür, 00:02:23.345 --> 00:02:26.585 wie sicher wir uns damit fühlen, in Produktion zu gehen, weil man halt gar nicht 00:02:26.585 --> 00:02:28.525 mehr so das krass babysittet, sondern 00:02:28.525 --> 00:02:32.145 irgendwie man shipped halt und dann funktioniert es halt, weil es halt in, 00:02:32.675 --> 00:02:36.335 99,9 Prozent der Fälle einfach völlig problemlos funktioniert. 00:02:36.695 --> 00:02:38.945 Und das ist aus meiner Sicht eigentlich ein gutes Zeichen. Und wenn es dann 00:02:38.945 --> 00:02:43.625 halt irgendwie ein bis zwei Minuten sind, dann geht ja auch nichts wirklich kaputt. 00:02:43.925 --> 00:02:47.045 Also wenn man jetzt nicht irgendwie eine medizinische Anwendung baut oder so. 00:02:47.565 --> 00:02:50.345 Das stimmt, das ist korrekt. Schöne Frage auf jeden Fall, Lucas. 00:02:51.275 --> 00:02:55.915 Danke dir. Dann würde ich sagen, wir starten jetzt mal rein in das Thema. 00:02:56.625 --> 00:02:59.985 Worüber wollen wir eigentlich heute sprechen? Also ich habe den Dirk eingeladen, 00:02:59.985 --> 00:03:07.895 weil Dirk und ich arbeiten zusammen an fejo.dk und dort machen wir beide Operations. 00:03:09.685 --> 00:03:14.265 Wir haben letztes Jahr diesen Umstieg gemacht von AWS auf Hetzner Cloud und, 00:03:15.495 --> 00:03:18.015 darüber wollen wir gar nicht so sehr jetzt sprechen, wie diese Migrationen gelaufen 00:03:18.015 --> 00:03:20.555 sind. Dazu haben wir auch schon mal einen Vortrag gehalten, wer sich dafür interessiert. 00:03:20.845 --> 00:03:24.905 Wir wollen heute mal darüber sprechen, wie sich das so anfühlt oder wie das 00:03:24.905 --> 00:03:26.675 genau aussieht, in einer Simple 00:03:26.675 --> 00:03:30.335 Cloud eine Rails-Anwendung laufen zu haben. Das ist das Thema heute. 00:03:30.715 --> 00:03:34.355 Und darum haben Dirk und ich überlegt, wir wollen euch da so ein bisschen durchführen. 00:03:34.355 --> 00:03:41.445 Wie wäre es, also quasi, wir haben alle Server gelöscht und jetzt deployen wir das Ganze nochmal neu. 00:03:42.385 --> 00:03:46.425 Was würde da passieren? Welche Tools sind da am Werk? Warum haben wir diese 00:03:46.425 --> 00:03:48.565 Tools ausgewählt? Welche Alternativen gäbe es? 00:03:48.925 --> 00:03:51.415 Und warum haben wir für diesen Fall diese Alternativen gewählt? 00:03:51.415 --> 00:03:54.575 Und dabei ist es uns ganz wichtig, das heißt nicht, dass das die beste Wahl 00:03:54.575 --> 00:03:57.485 für jedes System ist. Also das ist klar. 00:03:58.305 --> 00:04:03.635 Aber wir denken, dass es für viele eine Option ist, die unterschätzt wird, 00:04:04.565 --> 00:04:08.385 weil viele zu komplexeren Tools greifen, als sie das vielleicht bräuchten für 00:04:08.385 --> 00:04:10.705 den Use Case. Das ist so ein bisschen das, was wir euch erzählen wollen. 00:04:11.115 --> 00:04:14.245 Aber bevor wir das können, müssen wir so ein bisschen was zu Fejo erzählen, 00:04:14.245 --> 00:04:17.595 damit man einschätzen kann, wie das so ist. Magst du damit einmal kurz anfangen, 00:04:17.595 --> 00:04:19.595 Dirk? Wie sieht Fejo denn so aus? 00:04:20.055 --> 00:04:24.945 Also Fejo ist eine Ferienhausvermittlungsplattform für Ferienhäuser in Dänemark, 00:04:25.505 --> 00:04:30.115 suggeriert die Endung DK vielleicht schon und auch ausschließlich in Dänemark. 00:04:30.115 --> 00:04:34.655 Also man kann keine in Norwegen oder Schweden oder sowas oder in Norddeutschland, nur Dänemark. 00:04:35.295 --> 00:04:38.605 Und das ist ein relativ spezieller Ferienhausmarkt, der dänische. 00:04:39.785 --> 00:04:43.905 Gut, es gibt Ferienhäuser überall und Ferienwohnungen, aber der dänische Ferienhausmarkt 00:04:43.905 --> 00:04:48.105 ist insofern speziell, dass es eben, die sind im Grunde fast alle in privater 00:04:48.105 --> 00:04:51.565 Hand, die Ferienhäuser. Die Dänen haben einfach Ferienhäuser, sehr, sehr viele. 00:04:52.125 --> 00:04:55.615 Und Teile davon werden vermietet an Touristen. 00:04:56.885 --> 00:05:00.455 Auch für sich selber, aber vor allen Dingen an Touristen ist es auch vorgeschrieben. 00:05:00.455 --> 00:05:03.255 Und weil die da so viele von haben, gibt es entsprechend Infrastruktur. 00:05:03.255 --> 00:05:06.285 Das heißt, nicht jeder ist da Privatvermieter, sondern es gibt, 00:05:07.785 --> 00:05:11.755 so Agenturen und Büros, die sammeln dann diese Ferienhäuser und kümmern sich 00:05:11.755 --> 00:05:14.615 um die Vermietung, kümmern sich darum, dass die Verträge geschlossen werden, 00:05:14.615 --> 00:05:17.975 Schlüsselübergabe, Reinigung, dieser ganze Kram und auch Ansprechpartner vor Ort. 00:05:18.375 --> 00:05:21.295 Weil der Däne, dem das Haus gehört, der Dänin, die sitzt vielleicht in Kopenhagen 00:05:21.295 --> 00:05:24.025 und trinkt nen Kaffee, hat keine Lust darauf, dann kontaktiert zu werden, 00:05:25.185 --> 00:05:27.355 wenn der deutsche Urlauber da ein Problem hat. 00:05:28.765 --> 00:05:32.305 Und das sind die Ansprechpartner, mit denen wir kommunizieren. 00:05:32.305 --> 00:05:34.305 Von denen bekommen wir die Daten über diese Häuser. 00:05:34.535 --> 00:05:39.225 Mit denen rechnen wir sozusagen die Provision auch ab, die wir dann für eine 00:05:39.225 --> 00:05:42.215 Buchung bekommen. So verdient Fejo Geld für diese Vermittlung. 00:05:43.785 --> 00:05:48.845 Und da ist dann auch relativ, wird schon deutlich, wo ein Großteil der Arbeit 00:05:48.845 --> 00:05:51.275 liegt, nämlich die Aufarbeitung dieser Daten, die müssen irgendwie 00:05:51.625 --> 00:05:54.765 von den Partnern zu uns kommen, die sind in ganz vielen unterschiedlichen Formaten, 00:05:55.005 --> 00:05:57.685 die müssen irgendwie verarbeitet werden, das heißt, es gibt bei Fejo einen 00:05:57.685 --> 00:05:59.225 relativ großen Anteil an, 00:05:59.815 --> 00:06:04.585 Hintergrund Datenverarbeitung, wo wir in die Datenbank schreiben und dann gibt 00:06:04.585 --> 00:06:08.525 es eben den ganzen Teil, wo man als Kundin ein Ferienhaus suchen kann, 00:06:08.825 --> 00:06:10.105 buchen kann und das vermitteln wir dann. 00:06:11.625 --> 00:06:15.335 Ein wichtiger Aspekt ist, es gibt keine Bezahlfunktion auf Fejo, 00:06:15.335 --> 00:06:17.785 also das Bezahlen läuft völlig out of band. 00:06:18.195 --> 00:06:23.775 Das ist insofern relevant, weil das natürlich so ein paar Dinge sehr viel einfacher im Betrieb macht. 00:06:23.775 --> 00:06:27.065 Wir müssen keine Webhooks für Zahlungsanbieter haben, auch so Sicherheitssachen, 00:06:28.305 --> 00:06:33.005 sind einfach nicht so relevant für die Plattform, wie wenn du eine Kreditkartenanbindung 00:06:33.005 --> 00:06:37.405 hättest oder was ähnliches. Also bestimmte Zertifizierungen fallen weg und dergleichen. 00:06:37.885 --> 00:06:41.535 Das ist, finde ich, immer ein relativ wichtiger Punkt, wenn man sich auch so 00:06:41.535 --> 00:06:43.065 Architektur anguckt und Entscheidungen, 00:06:43.065 --> 00:06:48.355 weil das einfach deutlich Sachen einfacher macht. Ja, genau. 00:06:49.245 --> 00:06:52.765 Und dann der andere wesentliche Aspekt, das hat auch gar nichts mit Ruby und 00:06:52.765 --> 00:06:56.865 Rails zu tun. Wir haben uns entschieden, dass es so eine ganz klassische Server-Site 00:06:56.865 --> 00:07:02.385 gerenderte Seite ist mit JavaScript, was Dinge anreichert. 00:07:02.715 --> 00:07:05.805 Im Grunde funktioniert die Anwendung mehr oder weniger auch ohne JavaScript. 00:07:05.805 --> 00:07:09.685 Das ist natürlich Quatsch, aber das ist so der Grundgedanke dahinter. 00:07:10.155 --> 00:07:14.645 Und ich glaube, diese Aspekte sollten einigermaßen gut aufspannen, 00:07:14.645 --> 00:07:18.755 mit was wir hier hantieren und da könnt ihr dann ja schauen, 00:07:18.755 --> 00:07:20.875 ob das dann für euch auch passt, Teile daraus. 00:07:20.875 --> 00:07:23.175 Weil das hat auf jeden Fall Auswirkungen auf die Architektur, 00:07:23.175 --> 00:07:25.385 die wir in der Infrastruktur gewählt haben. 00:07:26.015 --> 00:07:29.485 Genau. Aber ich finde, einen wichtigen Aspekt hast du noch nicht erwähnt und 00:07:29.485 --> 00:07:34.595 das ist die Größe des Teams. Also wir reden darüber, dass wir im Team sechs 00:07:34.935 --> 00:07:38.335 Leute sind, also im Entwicklungsteam sechs Leute sind. 00:07:38.685 --> 00:07:42.525 Das heißt, es ist kein riesiges Team, wo man jetzt irgendwie einen Operations-Teil 00:07:42.525 --> 00:07:46.815 hat und einen Dev-Teil oder sonst irgendwas, sondern wir sind insgesamt sechs. 00:07:47.935 --> 00:07:51.745 Das sind nicht sechs Vollzeitäquivalente. Vollzeitäquivalente sind weniger. 00:07:52.245 --> 00:07:57.485 Ja, das ist ein wesentlicher Aspekt. Wir sind ein relativ kleines Team und dazu 00:07:57.485 --> 00:08:02.895 muss man auch sagen, auch das Team, was im Backoffice Kundenanfragen und Verwaltungssachen, 00:08:03.515 --> 00:08:05.225 macht, ist auch nicht viel größer. 00:08:06.995 --> 00:08:11.855 Personenzahlen sind das mehr, aber das ist das Vollzeitäquivalent noch weniger im Grunde. 00:08:12.225 --> 00:08:16.025 Instagram ist Fejo ein sehr überschaubares Team und das ist ein wesentlicher 00:08:16.025 --> 00:08:19.195 Aspekt, dass wir versuchen sowohl in der Entwicklung als auch im Backoffice 00:08:19.545 --> 00:08:20.735 sehr effizient zu arbeiten. 00:08:21.095 --> 00:08:25.815 Ja, definitiv. Und ich finde auch, das muss man auch noch mal betonen, 00:08:26.475 --> 00:08:30.405 weil Konkurrenten ja durchaus wesentlich größer sind. Also das scheint ja gut 00:08:30.405 --> 00:08:35.735 zu funktionieren, dieses Setup, dass das mit so einem relativ kleinen Team sehr gut läuft. 00:08:36.045 --> 00:08:39.665 Und ich finde auch noch mal zu ergänzen ist, dass der Großteil des Entwicklungsteams 00:08:39.665 --> 00:08:43.235 tatsächlich entweder Freelancer wie du oder Externe wie ich sind. 00:08:43.235 --> 00:08:47.485 Das heißt, wir müssen auch damit rechnen, dass mal jemand eine Zeit lang nicht verfügbar ist. 00:08:48.315 --> 00:08:52.245 Das heißt, auch das ist Teil von den Entscheidungen, die wir treffen. 00:08:53.015 --> 00:08:54.235 Und vollständig remote. 00:08:54.915 --> 00:08:55.275 Stimmt. 00:08:55.575 --> 00:08:58.875 Gleich, wenn wir über organisatorische Aspekte sprechen, auch noch ein wichtiger 00:08:58.875 --> 00:09:01.895 Aspekt. Das ist vollständig remote und es arbeiten, nicht alle zur gleichen 00:09:01.895 --> 00:09:05.425 Zeit. Also wir müssen sowieso auch asynchron kommunizieren. Daher, 00:09:06.165 --> 00:09:09.395 das sind die Aspekte, die da mit reinspielen in die Dinge, über die wir heute 00:09:09.395 --> 00:09:10.115 wahrscheinlich reden werden. 00:09:10.775 --> 00:09:14.765 Genau, das denke ich auch. Gut, dann würde ich sagen, starten wir mal rein in 00:09:14.765 --> 00:09:20.505 die Infrastruktur. Also, wir haben schon erwähnt, wir sind irgendwie aus AWS weggegangen. 00:09:20.795 --> 00:09:25.155 Wir sind auf einen, was wir Simple Cloud Anbieter gewechselt. 00:09:25.495 --> 00:09:29.905 Das ist bei uns Hetzner Cloud, aber es ist ganz bewusst so, dass wir gar nichts 00:09:29.905 --> 00:09:32.215 haben, was uns nur Hetzner Cloud bieten würde. 00:09:32.535 --> 00:09:36.175 Weil das ist genau das, was wir vermeiden wollen, was jetzt bei AWS eben sehr 00:09:36.175 --> 00:09:38.735 üblich ist, dass das Wegwechseln sehr teuer ist. 00:09:38.925 --> 00:09:44.645 Das, was wir bei Hetzner Cloud bekommen, kriegen wir bei mehreren anderen Anbietern auch. 00:09:45.035 --> 00:09:47.775 Das heißt, wir wollen uns da auch nicht so fest dran binden. 00:09:47.775 --> 00:09:50.975 Deswegen ist es für unsere Erklärung heute gar nicht so relevant, 00:09:50.975 --> 00:09:52.105 dass wir auf Hetzner Cloud sind. 00:09:52.635 --> 00:09:54.825 Wir können nur sagen, es funktioniert gut. Das ist der Teil, 00:09:54.825 --> 00:09:59.405 den wir dazu erzählen können, aber im Prinzip spielt es für den Rest keine Rolle. 00:09:59.865 --> 00:10:04.885 Das heißt, was benutzen wir von Hetzner Cloud? Wir benutzen da ganz intensiv 00:10:04.885 --> 00:10:07.495 natürlich die VMs, die uns zur Verfügung gestellt werden. 00:10:07.915 --> 00:10:14.415 Wir benutzen Load Balancer, wir benutzen die Storage, also das S3-Äquivalent 00:10:14.775 --> 00:10:19.165 von denen und natürlich dieses ganze Firewalling und Networking, 00:10:19.165 --> 00:10:22.075 was so ein System anbietet. 00:10:23.475 --> 00:10:25.905 Und das ist im Prinzip schon alles, oder habe ich was vergessen, Dirk? 00:10:26.995 --> 00:10:30.215 Nee, so technisch hast du die wesentlichen Sachen genannt. 00:10:31.135 --> 00:10:34.755 Ein wichtiger Aspekt, der natürlich da vorhanden sein muss, wenn man jetzt was 00:10:34.755 --> 00:10:38.185 anderes nimmt und den ja auch viele andere dann anbieten, ist natürlich eine 00:10:38.185 --> 00:10:41.285 API, über die man diese Infrastruktur fernsteuern kann. 00:10:41.875 --> 00:10:46.835 Wir wollen das auf jeden Fall nicht irgendwie mit Clicky-Bunty in so einem Web-Interface machen. 00:10:47.285 --> 00:10:53.305 Nicht, weil wir uns dem zu fein sind, sondern weil wir einfach das im Team verteilen 00:10:53.305 --> 00:10:56.035 müssen und keine Anleitung schreiben wollen und müssen bitte hier klicken und 00:10:56.035 --> 00:10:59.095 dann da klicken und dann ändert sich das Interface, was durchaus vorkommt. 00:11:00.465 --> 00:11:03.385 Auch bei AWS kommt das regelmäßig vor, dass sich das Interface ändert, 00:11:03.925 --> 00:11:07.385 sondern wir möchten das gerne im Code haben, dieses sogenannte Infrastructure 00:11:07.385 --> 00:11:12.045 as Code, damit man es eben versionskontrolliert haben kann. Wir können Codereviews 00:11:12.045 --> 00:11:15.235 durchführen und man hat ausführbare Dokumentation. 00:11:15.525 --> 00:11:18.025 Das finde ich ist immer ein ganz gutes Bild an der Stelle. 00:11:18.025 --> 00:11:23.545 Genau, genau. Und es bringt uns natürlich auch den Vorteil, also wir haben ein Staging Environment, 00:11:24.385 --> 00:11:29.725 in dem wir Changes halt vorab nochmal in produktionsnahe Umgebung testen können, 00:11:30.565 --> 00:11:33.325 und das wollen wir natürlich so nah an Produktion haben wie möglich. 00:11:33.325 --> 00:11:37.085 Das heißt also, klar, das ist runterskaliert, das sind weniger Server, 00:11:37.085 --> 00:11:40.065 das sind kleinere Server, das wäre ja einfach Geldverschwendung, 00:11:40.725 --> 00:11:44.225 aber es ist an sich das gleiche und deswegen ist für uns dieses Infrastructure 00:11:44.225 --> 00:11:47.745 as Code auch eine der wesentlichen Aspekte, die wir auch nicht missen wollten 00:11:47.745 --> 00:11:50.565 im Vergleich zu einem Hyperscaler wie AWS. 00:11:50.905 --> 00:11:55.215 Also das wollen wir haben. Wir wollen eben nicht alles auf Oldschool, 00:11:55.215 --> 00:11:59.345 einfach so einem Root-Server, wo man alles so von Hand einrichtet und dann muss 00:11:59.345 --> 00:12:01.555 man irgendwie Staging genauso einrichten und wenn man was ändert, 00:12:01.555 --> 00:12:03.365 muss man daran denken, es auf allen Environments zu machen. 00:12:03.655 --> 00:12:07.785 All so was wollen wir natürlich vermeiden und das bringt uns dann glaube ich auch 00:12:07.785 --> 00:12:12.055 direkt schon zum ersten Tool in der Toolbox und das ist dann Terraform. Ja. 00:12:13.595 --> 00:12:15.915 Und als wir den Vortrag gehalten haben, wurden wir auch direkt gefragt, 00:12:15.915 --> 00:12:18.585 warum Terraform und nicht Open Tofu. Können wir gerne gleich nochmal darauf 00:12:18.585 --> 00:12:22.635 eingehen. Aber grundsätzlich, was bietet ein Tool wie Terraform? 00:12:22.865 --> 00:12:25.575 Das bietet genau das, was Dirk sagt. Es nimmt eben diese API, 00:12:25.575 --> 00:12:30.925 die der Provider zur Verfügung stellt und erlaubt uns halt so eine Deklaration zu schreiben. 00:12:30.925 --> 00:12:33.785 Da steht dann halt drin, wir haben hier so einen Server, davon haben wir fünf 00:12:33.785 --> 00:12:38.585 Stück und da ist eine Netzwerkregel dran und da hängt übrigens eine feste IP 00:12:38.585 --> 00:12:39.835 dran und so weiter und so fort. 00:12:39.835 --> 00:12:45.905 All das können wir dort textuell beschreiben, sodass es zum einen für alle sichtbar 00:12:45.905 --> 00:12:48.465 ist, also alle im Team können da einfach reingucken und sehen, 00:12:48.465 --> 00:12:49.435 so sieht Produktion aus. 00:12:49.435 --> 00:12:53.075 Das ist halt keine Dokumentation in dem Sinne, also es ist schon Dokumentation, 00:12:53.075 --> 00:12:55.935 aber es ist halt wahre Dokumentation, weil wenn wir daran was ändern, 00:12:55.935 --> 00:12:58.215 dann ändert sich auch Produktion mit quasi. 00:12:58.215 --> 00:13:02.485 Also natürlich müssen wir das ausführen, aber grundsätzlich ist es eben die 00:13:02.485 --> 00:13:08.565 Beschreibung der Realität und das Tool ist halt aus meiner Sicht mittlerweile 00:13:08.565 --> 00:13:09.485 auch schon gut abgehangen. 00:13:09.485 --> 00:13:12.315 Ich weiß gar nicht, wie lange es Terraform schon gibt, aber eine ganze Weile, 00:13:13.025 --> 00:13:15.925 und funktioniert einfach sehr, sehr gut. 00:13:16.925 --> 00:13:20.305 Und was muss eine Cloud dafür bieten, damit das funktioniert? 00:13:20.985 --> 00:13:25.535 Die muss eben diese APIs bieten, der Dirk gesagt hat. Es muss eine API geben, 00:13:25.535 --> 00:13:29.015 mit der man sagen kann, hey, leg mal eine VM an, hey, löscht mal eine VM. 00:13:29.015 --> 00:13:32.095 All diese Sachen müssen über eine API zur Verfügung stehen und nicht nur über, 00:13:32.865 --> 00:13:34.305 Klicken in einem Web-Interface. 00:13:34.525 --> 00:13:38.445 Und dann muss sich halt jemand hinsetzen und einen sogenannten Provider schreiben. 00:13:38.445 --> 00:13:46.085 Das ist Code, der eben dieser Terraform-Sprache die ganzen Objekte 00:13:46.085 --> 00:13:50.645 zur Verfügung stellt, wie eine VM oder einen Load-Balancer oder was auch immer. 00:13:51.565 --> 00:13:54.525 Und man kann sich vorstellen, bei AWS ist das sehr, sehr umfangreich, 00:13:54.525 --> 00:13:57.015 weil es da eben sehr, sehr viele Services gibt, die man da einfügen kann. 00:13:57.015 --> 00:14:00.085 Und das ist bei Hetzner übersichtlicher. Da gibt es halt einfach nicht so viele 00:14:00.085 --> 00:14:02.875 Services. Da müssen sie auch nicht so viele Sachen schreiben. 00:14:03.455 --> 00:14:09.775 Und genau, wir benutzen eben diesen Provider und der hat bisher uns auch keine 00:14:09.775 --> 00:14:12.805 Probleme gemacht. Ich glaube, wir haben nur eine Sache gefunden, die gefehlt hat. 00:14:13.205 --> 00:14:18.095 Das waren die Storage, das S3 in Anführungsstrichen, was nicht da war. 00:14:18.345 --> 00:14:22.355 Aber sonst ist alles da und hat für uns sehr gut funktioniert, oder? 00:14:23.065 --> 00:14:28.295 Ja, auf jeden Fall. Also genau, das S3 war das Einzige, was so im Großen und Ganzen gefehlt hat. 00:14:28.915 --> 00:14:34.615 Und ja, das wird halt kontinuierlich auch weiterentwickelt, aber das meiste funktioniert ganz gut. 00:14:36.085 --> 00:14:40.255 Was auf jeden Fall so eine Besonderheit ist, wo man vielleicht drüber stolpert, 00:14:41.905 --> 00:14:47.585 das ist bei AWS auch so gewesen, die verlangen ja, dass so eine Instanz einen Namen bekommt. 00:14:47.745 --> 00:14:52.015 Und eigentlich wollen wir ja gar keinen Namen vergeben, es ist ja wurscht, wie das Ding heißt. 00:14:53.205 --> 00:14:57.105 Und die kann man dann zufällig generieren. Und das war auf jeden Fall bei Hetzer 00:14:57.105 --> 00:14:57.475 ein bisschen komplexer, 00:14:58.925 --> 00:15:02.465 oder ist immer noch etwas umständlicher, den so zufällig zu generieren, 00:15:02.465 --> 00:15:05.175 weil wenn man eine neue Instanz hochfährt, dann möchte man vielleicht, 00:15:05.175 --> 00:15:07.795 oder das machen wir zumindest, erst die neue Instanz vor oben haben, 00:15:07.795 --> 00:15:08.995 bevor man die alte abschaltet. 00:15:09.325 --> 00:15:12.765 Einfach um sicher zu gehen, dass alles da ist, bevor man das alte Ding runterfährt, 00:15:13.105 --> 00:15:15.885 was dann auch im laufenden Betrieb nämlich ein Update der Server erlaubt. 00:15:16.495 --> 00:15:19.815 Und die Namen dürfen sich natürlich nicht duplizieren, also kann ich nicht zweimal 00:15:19.815 --> 00:15:24.135 irgendwie eine Worker-Instanz irgendwo haben, sondern muss da immer so etwas 00:15:24.135 --> 00:15:25.295 zufälliges hinten dran hängen. 00:15:27.795 --> 00:15:30.585 Das ist aber jetzt nicht super spezifisch, das ist nur eine Sache, 00:15:31.055 --> 00:15:33.385 über die man vielleicht das erste Mal so stolpert, wenn man das macht. 00:15:33.385 --> 00:15:38.065 Stimmt. Ja, guter Punkt. Genau. Und um das jetzt mal konkreter zu machen, 00:15:38.065 --> 00:15:39.425 was beschreiben wir jetzt da? 00:15:39.945 --> 00:15:45.065 Also wir haben in unserem Terraform-Ding beschreiben wir unsere Web-Knoten. 00:15:45.065 --> 00:15:48.315 Also auf den Web-Knoten kommen wir gleich zu, da läuft diese Rails-Anwendung 00:15:48.315 --> 00:15:51.425 drauf, da läuft auch noch ein bisschen mehr drauf, können wir auch gern gleich noch was zu sagen. 00:15:52.475 --> 00:15:56.365 Dann haben wir einen sogenannten Image Server. Das ist einfach ein Server, 00:15:56.365 --> 00:15:58.605 der liefert die Hausbilder aus. 00:15:59.895 --> 00:16:04.475 Da benutzen wir eine Software, die heißt Image Proxy, also imgproxy, 00:16:04.645 --> 00:16:08.575 die wir jetzt auch schon lange benutzen und mit der wir sehr zufrieden sind. 00:16:08.575 --> 00:16:13.085 Die funktionieren einfach so völlig langweilig. Also wir müssen uns darum nie 00:16:13.085 --> 00:16:16.475 kümmern. Ich glaube, ich weiß gar nicht, ob wir die überhaupt anfassen mussten 00:16:16.475 --> 00:16:18.335 seit einer halben Ewigkeit. 00:16:19.275 --> 00:16:24.525 Und die bietet uns so Funktionalität wie Resize mal das Bild auf 800 mal 600 00:16:24.525 --> 00:16:28.665 oder sowas. Weil wir wollen responsive images haben. Wir haben viele Leute, 00:16:28.665 --> 00:16:32.695 die mobil auf die Seite zugreifen. Also sollen die natürlich auch kleinere Bilder bekommen. 00:16:33.795 --> 00:16:37.285 Das ist quasi gerade mal so das Service von dem, was das bietet. 00:16:37.285 --> 00:16:41.015 Aber das ist so die für uns wichtigste Funktionalität, dass es eben schnell 00:16:41.015 --> 00:16:46.205 Bilder ausliefern kann und eben solche Transformationen wie Resizing oder in 00:16:46.205 --> 00:16:48.435 andere Bildformate umwandeln. 00:16:48.435 --> 00:16:51.635 Genau, vor allem die anderen Bildformate. Das ist der spannende Punkt, 00:16:51.635 --> 00:16:53.885 warum wir das dann am Ende genutzt haben. 00:16:54.265 --> 00:16:57.095 Weil es nämlich erkennt, okay, kann der Client, der das anfragt, 00:16:57.095 --> 00:17:00.255 webP oder will er lieber AVIF? Und der prüft auch, ist das AVIF kleiner, 00:17:00.255 --> 00:17:03.505 ist das webP kleiner oder nehme ich einfach das JPEG oder was auch immer davor liegt. 00:17:04.375 --> 00:17:08.535 Genau, weil das eben Dinge sind, die, wenn man sie einkauft, 00:17:08.535 --> 00:17:10.085 sehr schnell sehr teuer werden. 00:17:10.415 --> 00:17:16.095 Also wenn man das bei Cloudflare macht oder Cloudinary oder es gibt ja genügend 00:17:16.515 --> 00:17:19.605 Dienste, die das anbieten, dann wird das relativ schnell teuer. 00:17:19.985 --> 00:17:24.435 Und selbst wenn man nur das Resizing selber macht und dann das Erkennen, 00:17:24.435 --> 00:17:27.995 okay, will ich WebP oder AVIF ausliefern, dann zum Beispiel von Cloudflare 00:17:27.995 --> 00:17:31.415 oder seinem CDN machen lässt, ja, dann hat man erst noch einen extra Schritt. 00:17:31.895 --> 00:17:35.355 Das ist aus unserer Erfahrung einfach nicht auch sehr robust gewesen. 00:17:35.355 --> 00:17:38.505 Dann wurde doch das Falsche ausgewählt. Dann hat sich der Lighthouse-Report beschwert. 00:17:38.925 --> 00:17:41.615 Und deswegen haben wir ja vor einiger Zeit gesagt, okay, wir nehmen einfach 00:17:41.615 --> 00:17:45.985 diese imgproxy. Das funktioniert einwandfrei. Das ist ein Docker... das ist in Go geschrieben, 00:17:45.985 --> 00:17:49.155 aber es läuft als Docker-Container irgendwo und macht einfach, 00:17:49.155 --> 00:17:50.995 was es soll, ohne zu murren. 00:17:51.765 --> 00:17:55.585 Genau, genau. Das ist eine gute Zusammenfassung. Genau. 00:17:56.695 --> 00:18:00.875 Und daneben haben wir dann noch Worker-Nodes. Dirk hat ja eben schon ausgeführt. 00:18:01.195 --> 00:18:04.965 Die sind tatsächlich bei uns, brauchen die mehr CPU als die Web-Worker, 00:18:04.965 --> 00:18:09.375 weil wir halt so viel importieren und verwalten müssen im Hintergrund. 00:18:09.375 --> 00:18:13.415 Und auf der technischen Ebene ist das auch einfach die Rails-Anwendung, 00:18:13.415 --> 00:18:14.655 die wir so geschrieben haben. 00:18:15.275 --> 00:18:19.465 In Rails ist es so, das ist ja auch in anderen Programmsprachen oder in anderen 00:18:19.465 --> 00:18:24.375 Frameworks anders, dass man eben solche Worker im Code mit definiert. 00:18:24.375 --> 00:18:27.405 Und dann kann man halt einfach eine weitere Instanz davon hochfahren und sagen, 00:18:27.405 --> 00:18:33.535 hey, du lauschst übrigens auch auf Jobs hier und arbeitet die halt im Hintergrund ab. 00:18:33.535 --> 00:18:38.915 Das ist das, was die Worker für uns tun. Jetzt habe ich Web Worker gesagt, 00:18:38.915 --> 00:18:41.375 das wäre ja völlig verwirrend. Genau, die Worker für uns tun. 00:18:42.515 --> 00:18:46.635 Auch nochmal auf der technischen Ebene ist es eben so, dass wir dabei Postgres 00:18:46.635 --> 00:18:50.475 als den, in Anführungsstrichen, Message Bus 00:18:50.475 --> 00:18:54.325 benutzen, also der die Nachrichten weiterleitet von der Anwendung an die 00:18:54.325 --> 00:18:59.405 Worker, was auch für uns sehr solide funktioniert. Wir hatten früher da Redis 00:18:59.405 --> 00:19:04.045 für im Einsatz und jetzt machen wir das mit Postgres und das funktioniert sehr, sehr gut. 00:19:04.585 --> 00:19:07.895 Können wir auch gerne noch ein paar Sachen zu den Shownotes werfen, 00:19:07.895 --> 00:19:13.085 wer sich dafür interessiert, weil früher, also kurzer Seitennotiz. 00:19:14.405 --> 00:19:16.345 Hatte sich das so zum Anti-Pattern entwickelt. 00:19:16.345 --> 00:19:19.785 Also viele haben gesagt, mach das lieber nicht, das ist zu langsam, das skaliert nicht. 00:19:20.585 --> 00:19:23.115 Aber es gibt halt mittlerweile doch viele Sachen in Postgres, 00:19:23.115 --> 00:19:27.965 die das wesentlich verbessert haben, dass das jetzt wunderbar funktioniert. 00:19:27.965 --> 00:19:33.445 Also wo das halt früher relativ brute force war, klappt das jetzt halt einfach 00:19:33.625 --> 00:19:36.065 total unaufgeregt, würde ich jetzt mal sagen. Weil ich glaube, 00:19:36.315 --> 00:19:40.725 auch damit hatten wir, seitdem wir live gegangen sind, eigentlich keine Probleme. Nicht nur eigentlich. 00:19:40.975 --> 00:19:46.245 Das hat keinerlei Probleme gemacht. Wobei man, also wir verarbeiten sehr viel 00:19:46.245 --> 00:19:48.795 im Hintergrund, aber nicht an Menge. 00:19:48.795 --> 00:19:53.515 Also für unsere Verhältnisse sind das schon ein paar 10.000 Jobs, 00:19:53.515 --> 00:19:56.505 die da jeden Tag laufen. Aber das sind jetzt nicht Millionen Jobs pro Stunde, 00:19:56.505 --> 00:20:00.595 die da durchgeschoben werden. Also da muss man dann vielleicht noch als Hinweis 00:20:00.595 --> 00:20:02.645 schon nochmal gucken, passt das dann immer noch? 00:20:02.995 --> 00:20:07.315 Wenn ich wirklich so sehr hohe Anforderungen an niedrige Latenz habe, 00:20:07.315 --> 00:20:11.555 ob das dann mit Postgres immer noch so hinhaut, das muss man einfach einmal durchmessen am besten. 00:20:12.025 --> 00:20:14.545 Das muss man auch mit Redis durchmessen, ob das alles passt. 00:20:15.835 --> 00:20:20.065 Da ist man dann einfach in einem anderen Scope. Aber das funktioniert super 00:20:20.065 --> 00:20:25.145 für uns. Wir haben zum Beispiel aber ja auch den Cache in die Postgres verlagert. 00:20:25.375 --> 00:20:27.495 Das geht auch mittlerweile recht gut. 00:20:28.465 --> 00:20:31.595 Das war auch vorher bei Redis. Das war einfach bei AWS sehr einfach. 00:20:31.595 --> 00:20:34.725 Man klickt sich einfach eine Redis-Instanz oder diese Elastic Cache-Instanzen, 00:20:34.725 --> 00:20:38.605 wie sie dann da heißen, und kriegt das einfach fertig hingestellt. 00:20:38.945 --> 00:20:43.145 Und der Grund war ja, wir wollten möglichst wenig Abhängigkeiten haben. 00:20:43.145 --> 00:20:45.505 Wir hätten dann Redis selber betreiben müssen. Das wollten wir nicht. 00:20:47.405 --> 00:20:50.705 Da haben wir allerdings Probleme gehabt mit dem Cache. Das ist nicht so problemlos 00:20:50.705 --> 00:20:56.495 gelaufen, weil die Implementierung für den Cache in Postgres bei Rails ist der 00:20:56.495 --> 00:20:59.365 Meinung, man muss die Tabellen trotzdem loggen, 00:21:00.905 --> 00:21:04.735 was für ein Cache herzlich irrelevant ist, ob der geloggt ist oder nicht. 00:21:04.735 --> 00:21:07.495 Und das hat den Durchsatz deutlich verbessert. 00:21:08.115 --> 00:21:14.875 Ja, genau. Aber auch da, also es war wirklich, es war sehr langsam geworden, 00:21:14.875 --> 00:21:16.355 Aber es ist nicht völlig kaputt gegangen. 00:21:16.355 --> 00:21:20.455 Aber es war halt wirklich, ja, also wir waren überrascht darüber, 00:21:20.455 --> 00:21:23.075 dass wir uns das darum selber kümmern mussten, ehrlich gesagt, 00:21:23.075 --> 00:21:26.825 weil wir gedacht haben, das wird ja wohl standardmäßig in dieser Implementierung 00:21:26.825 --> 00:21:28.395 so sein. Wir haben da gar nicht drüber nachgedacht. 00:21:28.775 --> 00:21:31.725 Aber so ist das halt manchmal mit diesen Details, dass man dann merkt, 00:21:31.725 --> 00:21:34.505 okay, vielleicht hätten wir das doch ganz genau anschauen müssen. 00:21:35.025 --> 00:21:39.375 Genau, aber so klappt das auch wieder unaufgeregt, würde ich es einfach nennen. 00:21:39.375 --> 00:21:44.865 Also jetzt cachen wir halt in der Datenbank, die halt einfach nicht persistiert im Prinzip. 00:21:45.665 --> 00:21:47.365 Das funktioniert sehr, sehr gut. 00:21:48.175 --> 00:21:51.455 Genau, das heißt also, was haben wir jetzt bisher beschrieben an VMs? 00:21:51.465 --> 00:21:54.375 Wir haben Webnodes, wir haben Worker-Nodes, wir haben diese Image-Nodes. 00:21:54.735 --> 00:21:58.425 Dann haben wir Datenbank-Knoten. 00:21:59.975 --> 00:22:04.555 Da haben wir eine sehr bewusste Entscheidung getroffen, wirklich nur eine zu haben. 00:22:05.465 --> 00:22:08.865 Aber da die Datenbank so ein spezielles Thema ist, haben wir überlegt, 00:22:09.015 --> 00:22:11.625 da reden wir am Ende nochmal drüber. Wir schieben jetzt die Datenbank mal zur 00:22:11.625 --> 00:22:16.115 Seite. Wir sagen einfach, da ist ein Node, da läuft eine Datenbank drauf. Der Rest kommt später. 00:22:17.295 --> 00:22:21.135 Genau. Und dann haben wir noch einen ganz kleinen Server, den Proxy. 00:22:21.755 --> 00:22:25.515 Den brauchen wir für manche der Partner. Wenn wir von denen Daten importieren, 00:22:25.515 --> 00:22:29.195 dann erwarten die eine feste IP aus Gründen. 00:22:30.055 --> 00:22:34.395 Und um dem entgegenzukommen, ist das halt ein einfacher Proxy. 00:22:34.895 --> 00:22:38.265 Alle Requests, die an diese Partner gehen, gehen einmal durch diesen Proxy durch. 00:22:38.995 --> 00:22:43.575 Ist nicht so schlimm, funktioniert. Auch wieder sowas, was uns lange nicht mehr 00:22:43.575 --> 00:22:46.035 überhaupt beschäftigt hat. Also wir gucken da, glaube ich, gar nicht mehr so 00:22:46.035 --> 00:22:47.625 richtig drauf. Der läuft halt einfach so. 00:22:47.625 --> 00:22:49.405 Ja, der läuft einfach vor sich hin. 00:22:50.185 --> 00:22:54.255 Genau. Und das ist auch der Knoten, dem wir eine feste IP zugewiesen haben. 00:22:54.255 --> 00:22:58.765 Und der Rest hat keine festen IPs. Also der, genau. 00:23:00.715 --> 00:23:05.185 Ja, dann würde ich sagen, lass uns noch mal kurz über den Loadbalancer sprechen. 00:23:05.185 --> 00:23:07.715 Das ist ja so ein Leidenschaftsthema von dir, Dirk, das überlasse ich mal dir. 00:23:08.465 --> 00:23:15.115 Also den Loadbalancer, den nutzen wir von Hetzner und das hat den, 00:23:16.085 --> 00:23:20.525 also wir hätten den natürlich auch selber als Node zur Verfügung stellen können. Das ist kein Problem. 00:23:21.505 --> 00:23:26.105 Was ich sehr sympathisch daran finde, das auszulagern auf den Dienstleister, 00:23:26.105 --> 00:23:28.695 das war bei AWS auch so, das geht auch bei vielen anderen so, 00:23:28.995 --> 00:23:30.885 dass der nämlich dann TLS-Terminierung macht. 00:23:30.885 --> 00:23:37.195 Ich muss also keine Secrets auf meine VMs spielen, sondern lade die quasi in 00:23:37.195 --> 00:23:39.485 die Cloud da hoch, konfiguriere das da drüber. 00:23:41.205 --> 00:23:44.185 Manchmal erlauben die dir dann ja auch, dass die da automatisch gemanagt werden 00:23:44.185 --> 00:23:45.515 und verlängert werden und all so ein Kram. 00:23:46.645 --> 00:23:49.705 Das benutzen wir also da. Das ist sehr angenehm. Und die regeln dann, 00:23:49.705 --> 00:23:54.455 okay, da sind jetzt nur von den drei Nodes, die eigentlich antworten sollten, 00:23:54.455 --> 00:23:57.165 sind nur zwei gesund, also wird der andere rausgenommen. 00:23:58.065 --> 00:24:02.305 Ja, wir haben am Ende auch total unaufgeregt. Und der Hauptgrund ist im Grunde 00:24:02.305 --> 00:24:08.345 die TLS-Terminierung und dass der Endpunkt eben auf deren Hardware läuft und 00:24:08.345 --> 00:24:12.425 nicht bei uns, wenn wir eine VM dann da durchläuft. Und wir uns dann noch darum kümmern müssten. 00:24:12.785 --> 00:24:17.225 Das spielt auch in das Firewall-Thema dann rein, das wir auch von Hetzner benutzen. 00:24:17.225 --> 00:24:23.025 Also die Kisten sind alle nicht von außen erreichbar, außer über SSH dann entsprechend, 00:24:23.025 --> 00:24:26.245 um irgendwie drauf deployen zu können und alles anderes eben gesperrt. 00:24:26.715 --> 00:24:30.765 Nur der Load Balancer kann eben auf den HTTP-Endpunkt zugreifen in den einzelnen 00:24:30.765 --> 00:24:32.845 Kisten. Und der Worker zum Beispiel, der hat überhaupt gar keinen, 00:24:33.175 --> 00:24:35.555 der exposed gar keinen HTTP-Point an der Stelle. 00:24:35.555 --> 00:24:38.855 Ja, genau. Ja, das ist auch ein wichtiger Punkt. 00:24:38.855 --> 00:24:42.375 Also die Netzwerkregeln sind auch extrem übersichtlich. 00:24:42.375 --> 00:24:45.605 Also es ist jetzt kein Dschungel von tausend von Regeln, weil es ist sehr, 00:24:45.605 --> 00:24:48.255 sehr klar. Also ich glaube, das kann sich auch jeder und jede, 00:24:48.255 --> 00:24:52.305 die zuhört, denken, wie diese Regeln ungefähr aussehen, wer welcher Knoten auf 00:24:52.305 --> 00:24:53.975 welchen anderen Knoten zugreifen kann. 00:24:55.145 --> 00:24:58.145 Also ja, auch wieder einfach gehalten. 00:24:59.345 --> 00:25:01.785 Aber wie machen wir das denn mit dem Autoscaling, Dirk? 00:25:03.305 --> 00:25:08.665 Gar nicht. Also dazu musst du vielleicht kurz einmal umreißen, 00:25:08.985 --> 00:25:11.185 was Autoscaling bei so einem Hyperscaler bedeutet. 00:25:11.885 --> 00:25:14.785 Das ist ja der Name Scaler im Hyperscaler mit drin. 00:25:16.855 --> 00:25:20.535 In meiner Wahrnehmung war das damals so eines der coolen Features von AWS. 00:25:20.535 --> 00:25:24.535 Du hast einen Autoscaler und der skaliert automatisch, wenn du ganz viel Zeug brauchst. 00:25:24.995 --> 00:25:27.085 Und dann denkt man so, boah, wie cool, dann kann ich dann nachts, 00:25:27.085 --> 00:25:30.005 da habe ich nur einen Server und dann tagsüber, wenn es so richtig brummt, 00:25:30.005 --> 00:25:31.915 dann habe ich irgendwie zehn Server und dann stellt man fest, 00:25:31.915 --> 00:25:33.665 man braucht überhaupt immer nur einen. 00:25:35.985 --> 00:25:39.945 Also vor allen Dingen mit zunehmender Leistungsfähigkeit der einzelnen Maschinen. 00:25:40.825 --> 00:25:45.055 Und dazu, ich hole jetzt einmal ein bisschen länger aus. 00:25:45.055 --> 00:25:48.855 Irgendwann sind ja dann, also man kann ja nicht beliebig kleine Maschinen nehmen, 00:25:48.855 --> 00:25:50.545 weil an einer beliebig kleinen Maschine, 00:25:51.135 --> 00:25:54.055 die hat zwar wenig CPU, die hat aber auch wenig I/O, die hat wenig RAM, 00:25:54.055 --> 00:25:58.405