Wolfgang und Andy erzählen ein wenig was über ihre eigenen Side Projects sourcectl (https://gettoknow.sourcectl.dev/), F-Online (https://www.f-online.at/) und the athlete (https://theathlete.app/).
Wir machen eine Rundfahrt durch den verwendeten Technologienzoo, diskutieren ob man Monitoring in Side Projects benötigt, wann es Over-Engineering und wann gerechtfertigt ist, ob der heutige Einsatz von Zend Framework 1 schon als kriminell gewertet werden kann und hören Wolfgang zu, wie er DevOps Anfängerfehler begeht indem ihm die Festplatte voll logs läuft.
Bonus: Wie Wolfgang den ultimativen Reichtum mit seinem eigenen CMS zur dotcom Blase verpasst hat
Feedback an stehtisch@engineeringkiosk.dev oder via Twitter an https://twitter.com/EngKiosk
Andy (https://twitter.com/andygrunwald) und Wolfgang (https://twitter.com/schafele) sprechen im Detail über:
Sprungmarken
(00:00) Intro
(02:03) Vorstellung von Andy und Wolfgang
(02:18) Vorstellung Andy Grunwald
(02:36) Vorstellung Wolfgang Gassler
(03:11) Side Project "inspect": Automatische Generierung einer RabbitMQ Architektur
(04:23) Was ist RabbitMQ?
(05:33) Side Project "sourcectl": Metrik Platform für Inner Source und Open Sorurce Projekte
(06:32) sourcectl: Warum nutzt du RabbitMQ und keine Datenbank für das Message Queuing?
(07:48) sourcectl: Monitoring
(08:55) sourcectl: Verarbeitung von Messages
(09:50) sourcectl: Infrastruktur- und Application-Setup
(12:01) Was zur Hölle ist ein OMR (vs. ein ORM)?
(12:53) Was ist Traefik: The Cloud Native Application Proxy?
(17:45) Traefik Pro und Overengineering: Loadbalancing über mehrere Server und verteilte SSL Zertifikate
(20:00) Side Project "F-Online": Für den Führerschein in Österreich lernen
(21:34) F-Online: Hosting und Monitoring
(25:27) Tipps um Kosten bei Google Cloud unter Kontrolle zu halten
(26:01) F-Online: Infrastruktur- und Application-Setup
(26:42) Wolfgangs Leiche im Keller: Zend Framework 1 auf (teils) aktueller PHP Version
(29:00) F-Online: JavaScript Architektur
(31:29) F-Online: APIs
(32:40) F-Online: Datenbank
(34:39) F-Online: Wie es aussehen würde, wenn es nochmal neu gebaut werden würde
(37:22) Engineers over-engineeren von Haus aus
(37:40) Side Project "the athlete"
(39:02) Ziele, Motivation und die (eigenen) Erwartungen an Side Projects
(40:28) Wolfgang erzählt vom Krieg: Sein eigenes Content Management System
(42:37) Outro
Erwähnte Side Projects
- sourcectl (https://gettoknow.sourcectl.dev/)
- F-Online (https://www.f-online.at/)
- the athlete (https://theathlete.app/)
Erwähnte Technologien
- AMQP (https://www.amqp.org/)
- Babel (https://babeljs.io/)
- Backbone (https://backbonejs.org/)
- DigitalOcean (https://www.digitalocean.com/)
- Docker (https://www.docker.com/)
- Flutter (https://flutter.dev/)
- GitHub (https://github.com/)
- Go (https://go.dev/)
- Google Cloud Free-Tier (https://cloud.google.com/free)
- Grafana (https://grafana.com/)
- GraphQL API (https://graphql.org/)
- Grunt (https://gruntjs.com/)
- Hetzner Cloud (https://www.hetzner.com/de/cloud)
- JQuery (https://jquery.com/)
- Kubernetes (https://kubernetes.io/)
- Lets Encrypt (https://letsencrypt.org/)
- Marionette (https://marionettejs.com/)
- MooTools (https://mootools.net/)
- MySQL (https://www.mysql.com/)
- Nginx (https://www.nginx.com/)
- PHP (https://www.php.net/)
- Prometheus (https://prometheus.io/)
- RabbitMQ (https://www.rabbitmq.com/)
- React (https://reactjs.org/)
- React Native (https://reactnative.dev/)
- Script.aculo.us (https://script.aculo.us/)
- Terraform (https://www.terraform.io/)
- Traefik (https://traefik.io/)
- VueJS (https://vuejs.org/)
- Webpack (https://webpack.js.org/)
- Zend Framework 1 (https://github.com/zendframework/zf1)
Anderes
- OMR - Online Marketing Rockstars (https://omr.com/de/)
- No Code (https://www.nocode.tech/)
Erwähnte Personen
- Matthias Endler (https://twitter.com/matthiasendler / https://endler.dev/)
Hosts
- Wolfgang Gassler (https://twitter.com/schafele)
- Andy Grunwald (https://twitter.com/andygrunwald)
Engineering Kiosk Podcast
Anfragen an stehtisch@engineeringkiosk.dev
Transkript
Wolfi Gassler (00:00:00 - 00:00:33) 
Willkommen zur zweiten Episode vom Engineering-Kiosk. Heute machen wir mal eine Rundfahrt durch unseren Technologien-Zoo, den wir in unseren Side-Projects verwenden. Wir sprechen über MySQL, RabbitMQ, alte Send-Frameworks, BAB-Versionen, Docker Swarm, wie man richtig SSL-Zertifikate generiert, welche Hosting-Plattformen wir verwenden, wie man Monitoring richtig macht, ob man Monitoring überhaupt braucht und wie Andi als Athlet gescheitert ist. Guten Morgen.
Andy Grunwald (00:00:33 - 00:00:36)
Guten Morgen Wolfgang.
Wolfi Gassler (00:00:36 - 00:00:39)
Ich hoffe, du hast das Jahr gut überlebt.
Andy Grunwald (00:00:39 - 00:00:43)
Wir sind noch mit einem Jahr, wir sind sozusagen in den, wie nennt sich das schon, zwischen den Tagen.
Wolfi Gassler (00:00:43 - 00:00:49)
Jetzt hast du es verraten, dass wir jetzt schon aufnehmen und es viel später erst online senden.
Andy Grunwald (00:00:49 - 00:00:55)
Okay, so ist das aber mit Zeitprojekts. Man hat Motivation zu starten und das dann wirklich zu deployen und live zu bringen, ist ja immer so eine Sache.
Wolfi Gassler (00:00:55 - 00:01:22)
Aber es ist wenigstens wirklich früh. Es ist 10 Uhr. Andi hat mir gestern noch einen tollen Screenshot von einem von seinen Side-Projects gesendet. Ich habe keine Ahnung genau, was es gewesen ist. Aber man sieht, dass der Andi auf jeden Fall während den Feiertagen an seinen Side-Projects schraubt. Im Gegensatz zu mir. Ich bin einfach nur in Österreich und genieße den Schnee. Aber einer von uns muss hier arbeiten.
Andy Grunwald (00:01:22 - 00:01:38)
Ob es ein Zeitprojekt ist, weiß ich nicht. Ein schneller Prototyp auf jeden Fall. Ja, in der Tat. Ich habe die Zeit genutzt, zwischen den Tagen, um mal ein bisschen zu relaxen, von der Familie ein bisschen runterzukommen. Und hab mich mal wieder in einem Editor verloren und ein bisschen Code geschraubt.
Wolfi Gassler (00:01:39 - 00:01:59)
Bevor wir uns das Ganze genauer anschauen, wir haben noch eine Rüge bekommen von einem von unseren Testhörern. Er hat gemeint, wir haben uns nie richtig vorgestellt. Also ich würde das gerne kurz nachholen, Andi. Du hast zehn Sekunden, um dich kurz vorzustellen und deinen gesamten Lebenslauf gibt dir zwölf Sekunden.
Andy Grunwald (00:02:01 - 00:02:13)
Hallo liebe Hörer, mein Name ist Andi Grunwald, ich komme aus dem schönen Duisburg, aus dem Ruhrgebiet, bin 34 Jahre alt und bin Software-Engineer und Engineering-Manager seit ungefähr 12 Jahren. Wolfgang, wer bist du?
Wolfi Gassler (00:02:13 - 00:02:40)
Ich bin der Wolfgang, komme aus Österreich. ist scheinbar wichtig zu sagen, das hört scheinbar immer noch nicht jeder. Komme aus einer teilweise Uni-Karriere, war aber auch lang Freelancer, immer nebenbei, kenne also die wissenschaftliche Welt, aber auch die Privatwirtschaft und die Freelancer-Welt und habe dann Andi bei Trivago kennengelernt, wo wir eigentlich beide im Team-Lead-Bereich und Engineering-Manager-Bereich unterwegs waren.
Andy Grunwald (00:02:40 - 00:02:43)
Ich glaube, das war jetzt aber länger als für Kunden. Ich glaube, ich hätte dich auch limitieren sollen.
Wolfi Gassler (00:02:44 - 00:02:54)
Ja, ich habe eben nur gesagt, du hast zwölf Sekunden. Von mir war ja nie die Rede. Aber kommen wir zurück zu deinem Side-Project. Erklär mal kurz, was du in deinem Side-Project da gemacht hast in den Feiertagen.
Andy Grunwald (00:02:54 - 00:03:20)
Die Grundidee war, ich habe einen Message Queue Server, RabbitMQ, Da wo Nachrichten hin und her gesendet werden. Und irgendwie ist die ganze Sache relativ groß geworden und ich hab so ein bisschen die Übersicht verloren. Welche Queues, wohin gehen, wie die ganze Sache aufgebaut ist. Man kennt das, man hackt einfach mal los. Und dann hab ich gedacht, hey cool, lass doch mal die RabbitMQ API anfragen und lass daraus doch mal versuchen, irgendein Diagramm zu erstellen, was mir dann wieder eine Übersicht gibt.
Wolfi Gassler (00:03:21 - 00:03:25)
Du machst das, obwohl du eigentlich nur alleine an dem Side-Project arbeitest. Sehe ich das richtig?
Andy Grunwald (00:03:26 - 00:03:35)
Ja, das siehst du richtig. Aber du weißt ja auch, die Testfrage ist, was hast du vor zwei Tagen zum Frühstück gegessen, Wolfgang?
Wolfi Gassler (00:03:36 - 00:03:37)
Keine Ahnung. Ich frische die Knie.
Andy Grunwald (00:03:39 - 00:03:53)
Okay, er setzte Frühstück durch Mittagessen. Der Punkt ist einfach, du bist mir das nicht sagen können. Deswegen habe ich auch die Überlicht verloren von Queues und Exchanges und welche Daten wo drin sind und so weiter. Also da brauche ich dann einfach mal ein Diagramm.
Wolfi Gassler (00:03:53 - 00:04:05)
Die Frage ist ja überhaupt, warum verwendest du überhaupt RabbitMQ? Das klingt ja schon wieder sehr nach Overengineering. Oder vielleicht erklär mal kurz, was RabbitMQ überhaupt ist in einem Satz, falls jemand RabbitMQ nicht kennen sollte.
Andy Grunwald (00:04:05 - 00:04:19)
Revenant Queue ist eine Open Source Message Queue, ein Message Queue Server. Man kann Nachrichten reinpacken und dann können Prozesse, die auf diesen Warteschlangen horchen, können diese Nachrichten dann verarbeiten. Das ist Revenant Queue in 2 Seconds.
Wolfi Gassler (00:04:20 - 00:04:23)
Und warum verwendet man RabbitMQ? Warum kann er das nicht direkt programmieren?
Andy Grunwald (00:04:24 - 00:04:48)
Du kannst das auch direkt programmieren. Du kannst auch eine In-Memory-Queue bauen, alles super. Der Riesenvorteil ist, wenn du einen externen Server hast, dass du eigentlich so eine Art kleines verteiltes System machen kannst. Das bedeutet, du kannst Producer, das sind die Tools, die die Nachrichten erstellen und deine Consumer auf anderen Servern laufen lassen, in anderen Kontinenten, Datenzentren etc. Okay, klingt.
Wolfi Gassler (00:04:48 - 00:04:57)
Wirklich nach Premature Optimization. Erklär mal, was machst du in dem Projekt? Warum bist du auf die Idee gekommen, überhaupt RabbitMQ dann zu verwenden?
Andy Grunwald (00:04:57 - 00:05:16)
Ja, du kannst von Premature Optimization reden. Offengesprochen lasse ich alles auf einem Server laufen. Also ich lasse die Producer auf einem Server laufen, ich lasse den RabbitMQ-Server auf demselben Server laufen, ich lasse die Konsumenten laufen. Das bedeutet, von diesem Vorteil von Distributed System mache ich eigentlich gar keinen Gebrauch. Es geht mir nur darum, dass ich diese ganze Queue-Funktionalität einfach nie nachprogrammieren wollte.
Wolfi Gassler (00:05:16 - 00:05:19)
Okay, also für was verwendest du die Queue-Funktionalität?
Andy Grunwald (00:05:19 - 00:06:01)
Das für ein größeres Site-Project nennt sich Source Control. Was ich damit eigentlich mache, ist, ich baue eine Matrix-Plattform für Open-Source- und Inner-Source-Projekte. Und primär höre ich da auf Webhook-Events, zum Beispiel von GitHub. Die packe ich in die Message-Queue. Und auf Basis dieser Nachrichten crawle ich dann Repositories, hole mir Informationen, speichere sie weg. Also alles so, sagen wir mal so, Aktionen, die nicht asynchron sind. prozesst werden müssen, weil ich glaube, es gibt sogar Garantien, dass wenn du einen Webhook von GitHub bekommst, dass du innerhalb von einer Sekunde oder zwei antworten musst, weil sonst bist du geblockt und so weiter und so fort. Für asynchrone Prozesse, kurzum.
Wolfi Gassler (00:06:01 - 00:06:14)
Das heißt aber, wenn du so einen Webhook bekommst, also eigentlich nur ein Request auf irgendeine URL, machst du dann die ganzen Aktionen oder sendest du dann Messages, die dann erst später prozesst werden?
Andy Grunwald (00:06:14 - 00:06:21)
Ich nehme den Content von der Werbung entgegen, bei GitHub ist es JSON, und das schmeiße ich dann in verschiedene Queues.
Wolfi Gassler (00:06:21 - 00:06:27)
Und warum verwendest du Rabbit im Queue und keine Datenbank oder sowas?
Andy Grunwald (00:06:27 - 00:06:54)
Ja, bei der Datenbank, da müsste ich ja dann schon wieder, also nehmen wir mal MySQL, natürlich könnte ich diese Message Queue auch einfach in der Tabelle inserten. Aber dann muss ich da ja schon wieder sagen, okay, diese Nachricht wurde von diesem Konsumenten gelesen und ein anderer Konsument soll diese Nachricht nicht nehmen, weil die ist ja gerade schon im Processing und so weiter. Also da müsste ich ja diese ganze Funktionalität, die RabbitMQ ja schon bietet, weil es ist ja ein nativer MessageQueue-Server, müsste ich ja da nachprogrammieren und das wollte ich dann eigentlich nicht.
Wolfi Gassler (00:06:55 - 00:07:08)
Und die Prozesse, die dann am Ende die Messages lesen und was damit machen, die laufen ständig und fragen einfach nach, ob neue Nachrichten da sind, ob es irgendwelche neuen Tasks gibt zum Prozessen. Versteht das richtig?
Andy Grunwald (00:07:08 - 00:07:43)
Also ja, das sind Prozesse, die laufen kontinuierlich, aber die haben eine konstante Verbindung zum RabbitMQ. Du kannst dir vorstellen, wie Websockets ähnlich, dass der RabbitMQ-Server dann die Nachricht an die Konsumenten pusht. Moment, jetzt stellst du mir eine gute Frage. Pusht der die oder fragt der Konsument immer konstant nach? Muss ich zugeben, weiß ich gerade im Detail nicht, müsste ich mal im AMQP-Protokoll nachschauen. AMQP ist das unterliegende Protokoll, was RabbitMQ nutzt. Und RabbitMQ ist nur einer von verschiedenen Servern, die das AMQP-Protokoll implementieren.
Wolfi Gassler (00:07:44 - 00:07:48)
Machst du Monitoring, ob RabbitMQ läuft?
Andy Grunwald (00:07:50 - 00:07:54)
Sollte ich tun, ja. Nein, tue ich nicht.
Wolfi Gassler (00:07:54 - 00:07:55)
Machst du irgendwo anders ein Monitoring?
Andy Grunwald (00:07:55 - 00:07:56)
Nein, das ist ein Side-Project, natürlich nicht.
Wolfi Gassler (00:07:57 - 00:08:18)
Ah, okay, okay. Weil das ist immer meine Argumentation, wenn du so zusätzliche Tools hast und gerade bei Distributed Systems, du musst natürlich alles genau monitoren und das können dir halt statt einem Prozess können dir irgendwie 20 Prozesse irgendwo abfliegen und sterben. Und die Chance ist halt dann einfach höher, dass irgendwo was bricht, als wenn man einen Prozess hat, der einfach alles macht.
Andy Grunwald (00:08:18 - 00:08:47)
Ja, ich hätte mir bei diesem Side-Projekt einfach mal gedacht, ganz im Ernst Andi, hör mal, versuch mal nicht over zu enginieren und versuch einfach mal irgendwie was an den Start zu kriegen, eine Webseite, die ich nutzen kann und die schon mal ein bisschen was macht. Weil hätte ich mir diese Privilege nicht gesetzt, dann wäre ich jetzt glaube ich immer noch dabei, mein Prometheus und Grafana Setup aufzusetzen und hätte schon irgendwie, weiß ich nicht, 200 Dollar Cloudkost pro Monat, bevor ich überhaupt eine simple Webseite habe, wo ich mich einloggen kann. Und deswegen habe ich einfach mal gedacht...
Wolfi Gassler (00:08:48 - 00:09:01)
Ich würde ja sagen, RabbitMQ ist auch schon ziemlich over-engineered, man hätte es auch einfacher machen können, aber wie viele Messages verarbeitest du da bei so einem Webhook oder was entsteht dann dahinter draus, wenn man so einen Webhook verarbeitet?
Andy Grunwald (00:09:01 - 00:09:38)
Das kommt ja mal ganz drauf an, was man da richtet. Nehmen wir mal an, jemand installiert meine Source-Control-Github-App, Dann kriege ich den Account und sage, hey, da wurde eine neue App installiert. Und diese Person ist zum Beispiel Matthias Endler. Matthias Endler hat, glaube ich, 200 Open-Source-Repositories und keine Ahnung wie viele Private-Repositories. Aber dann fliegen da schon mal so ein paar tausend Messages durch. Wie zum Beispiel, gib mir mal alle 200 Repositories. Die werden dann gecrawled auf Basis dieser ... Repositories werden dann weitere Messages erzeugt, also es geht dann schon in die vierstellige Anzahl an Messages dann für eine Installation.
Wolfi Gassler (00:09:38 - 00:09:42)
Und machst du das mit einem Prozessor oder läuft das dann parallel?
Andy Grunwald (00:09:42 - 00:09:48)
Was ich hab ist, an jeder Queue hängt ein Prozess, weil die pro Queue müssen andere Aktionen getätigt werden.
Wolfi Gassler (00:09:49 - 00:10:05)
Und wenn du jetzt gesagt hast, das Ganze ist nicht over-engineert, um möglichst schnell etwas an den Start zu bringen, wie läuft es? Läuft es in Docker oder ist es einfach auf einem virtuellen Server geknallt und alles installiert dort oder wie ist da das Setup?
Andy Grunwald (00:10:05 - 00:10:30)
Der Revit MQ Server läuft in Docker. Der HTTP-Service, der dem Webhook entgegennimmt, läuft in Docker. Consumer, also die Prozesse, die die Nachricht verarbeiten, laufen in Docker. Davor hab ich noch mal einen Docker-Container mit einem Traffic-Load-Balancer oder Traffic-Proxy oder wie du's immer nennen möchtest. Und das ganze Setup läuft mit Terraform. Wird automatisch mit GitHub Actions deployed. Ich weiß nicht, ist das schon overengineert?
Wolfi Gassler (00:10:30 - 00:10:38)
Meiner Meinung nach, wenn man sich irgendwo gut auskennt, kann man das natürlich auch verwenden. Dann ist man wahrscheinlich sogar schneller, als wenn man das irgendwie manuell baut, das Ganze zu bauen.
Andy Grunwald (00:10:38 - 00:12:08)
Genau, die ganze Sache klingt super overengineert. Offen gesprochen ist das für mich inzwischen ein relativ einfaches Setup, weil durch ein bis zwei vorherige Side Projects, wo ich sehr, sehr, sehr viel experimentiert habe und diese ganzen Learnings, wie setze ich ein Traffic auf, wie deploye ich das per GitHub Actions, wie replace ich Docker-Container, und ich nutze kein Kubernetes oder kein Docker-Swarm, ganz klassisch Docker-Run, et cetera, et cetera. Wie setze ich meine Infrastruktur automatisiert auf mit Terraform? Die Learnings habe ich alles schon gemacht. Das bedeutet, für dieses Source-Control-Projekt war das eigentlich nur Copy-Paste für mich. Das bedeutet, die Basis-Infrastruktur, innerhalb von 20 Minuten war die am Start. weil ich die ganzen Learnings halt vorher schon gemacht hab. Und vorher hab ich halt hard overengineert mit GraphQL API und schieß mich tot. Was ich bei Source Control mach, ist ganz einfach. Ich hab da eine Webseite, die wurde mit Go programmiert. und die geht ganz knallhart hinten auf eine MySQL-Datenbank mit wirklich Select-Stern-From-Table. Also kein ORM, keine REST-API, keine GraphQL-API oder nix mit gRPC oder Ähnliches. Ich war so frustriert von meinen vorherigen Seitenprojekten, dass ich da einfach über Monate hinweg irgendwas geschraubt habe und niemand konnte etwas nutzen. Und hier hatte ich dann nach zwei Tagen schon etwas, wo Leute dann mal was nutzen konnten. Und das muss ich zugeben, motiviert schon sehr.
Wolfi Gassler (00:12:09 - 00:12:32)
Man merkt halt auch, dass du aus der Infrastrukturecke kommst, da bist du dann eher am Aufwand von komplexeren Tools und Möglichkeiten, die du da verwendest, im Gegensatz zu, keine Ahnung, OMR oder irgendwelche Datenbanken oder so. Wobei, ich bin jetzt auch kein großer Fan von OMRs, überhaupt nicht. Die machen mehr Probleme, als was sie helfen, meiner Meinung nach.
Andy Grunwald (00:12:32 - 00:13:02)
Moment mal, OMRs? Wir sind hier nicht bei Online-Marketing-Rockstars. Du meinst ORMs, richtig? Also, der Wolfgang ... Du hast zu viel OMR gehört. Der Wolfgang ist anscheinend auch Engineer und möchte sich im Bereich Marketing weiterbilden. Deswegen hört er, glaub ich, immer den Online-Marketing-Rockstars-Podcast und verwechselt dann ... ORMs, also Datenbank-Abstraktions-Layer, mit... Object-Relational-Mapping? Genau, also so was hab ich alles gar nicht drin. nee. Aber die...
Wolfi Gassler (00:13:02 - 00:13:10)
Aber erklär mal Traffic. Das ist wirklich ein cooles Tool, meiner Meinung nach. Das auch sehr viele Dinge vereinfacht.
Andy Grunwald (00:13:10 - 00:13:47)
Traffic ist ein, Achtung, das nennt sich Cloud-Native-Application-Proxy. Kannst du dir vorstellen, wie ein Loadbalancer, steht ganz vorne, der nimmt ein Call entgegen und auf Basis von diversen Regeln, der Domain, dem Port, irgendeinem Header, kannst du diesen Request halt irgendwohin weiterleiten. Sei es an mein Handy oder vielleicht auch einfach nur lokal an irgendeinem Docker-Container. Und das macht das natürlich sehr einfach. Der hat Tools drin wie z.B. generiert mir automatisch ein SSL-Zertifikat. Das mache ich z.B. mit Let's Encrypt. Das macht er, der refresht das automatisch.
Wolfi Gassler (00:13:48 - 00:14:42)
Das heißt, wenn man sich eine simple Web-App vorstellt, die man so baut, dann hat man einen Docker-Container mit seiner Applikation, einen Docker-Container mit irgendeinem Speicher-Storage-Layer wie einer MySQL-Datenbank und ganz zu Beginn, ganz am Anfang, da wo die ganzen Requests reinkommen, das ist jetzt dieser Traffic-Docker-Container, der einfach die ganzen Requests dann weiterleitet, umleitet zu den richtigen Docker-Containern, Wenn man nur einen Docker-Container, eine App hat, ist das recht einfach, aber oft hat man ja auf einem Server irgendwie drei verschiedene Apps oder Backend-APIs oder was auch immer und dann muss man an diese fünf Apps oder APIs je nach Domain unterschiedliches Routing machen, dass man zu der richtigen App kommt und Traffic übernimmt. Das ist komplett automatisch und generiert auch SSL-Zertifikate.
Andy Grunwald (00:14:42 - 00:15:16)
Ja, ganz genau. Also ich hab da jetzt einen Server laufen. Auf dem Server laufen drei oder vier, nee, sieben Docker-Container, einen RabbitMQ-Server und so weiter. Und die laufen alle auf einer Domain, sourcecontrol.app. Auf jeden Fall kann ich dann sagen mq.sourcecontrol.dev und komme dann auf meinen RabbitMQ Server. Oder einfach auf die Webseite. Oder du kannst sagen meinedomain.com slash admin und slash admin geht dann auf dein Admin-Doc.
Wolfi Gassler (00:15:16 - 00:15:27)
Bevor jetzt Leute eingeben, sourcecontrol ist geschrieben sourcectl.dev, aber wir verlinken das in den Journals natürlich. Dann kann es jeder gerne mal ausprobieren, weil ich glaube, es ist frei zur Verwendung.
Andy Grunwald (00:15:27 - 00:15:29)
Das ist aktuell frei zur Verwendung, richtig.
Wolfi Gassler (00:15:30 - 00:16:08)
Auf jeden Fall Traffic kann ich sehr empfehlen. Ich habe es zwar selber noch nie verwendet, aber ich weiß, wie aufwendig es ist, das selber zu programmieren und ich habe mir das selber zusammengeschnitzt mit Nginx und Let's Encrypt, Crunch Ops und ähnlichen Dingen, damit ich mehrere Domains verwalten kann und so weiter. Das selber zu machen ist wirklich ein großer Pain und Traffic scheint das wirklich out of the box extrem einfach zu lösen und das ganze Setup wesentlich zu vereinfachen. Also jeder, der mit Docker und Webapps arbeitet, soll sich Traffic auf jeden Fall mal anschauen. Macht die ganze Geschichte wesentlich einfacher.
Andy Grunwald (00:16:08 - 00:17:39)
Man darf es aber nicht so runterspielen. Das bedeutet, die Lernkurve, um Traffic richtig zu konfigurieren, hat man natürlich schon. Aber ich bin ganz ehrlich, ich glaube, die hat man überall so ein bisschen. Aber der hat halt Live Reload und so weiter drin. Also ein sehr cooles Feature speziell, das für meinen Anwendungsfall ist. Ich habe ja gesagt, ich habe einen Server, den hat auch ein 7-Docker-Container. Und mein Traffic hat eigentlich gar keine Konfiguration. Also das bedeutet, in meinem Traffic habe ich einfach nur gesagt, okay, hallo lieber Traffic, starte bitte. Und hier hast du bitte den Token für DigitalOcean für DNS, damit ich da Let's Encrypt generieren kann. Ich mache DNS-Authentifizierung, damit ich ein Wildcard-Zertifikat über SSL kriege. Das ist alles. Und habe eben gesagt, da liegt mein Docker-Socket. Und was Traffic dann macht ist, Traffic geht auf den lokalen Server. Nutze ich den Docker Socket und immer wenn ich einen neuen Container starte, neuen Application Service, gebe ich diesem Container ein paar Labels mit. Die nennen sich dann Traffic Punkt Settings Punkt irgendwas. Und in diesen Labels konfiguriere ich dann, wie Traffic mit dem Docker Container umgehen soll. Das bedeutet, mein Load Balancer oder mein Application Proxy, den fasse ich eigentlich gar nicht mehr an. Ich deploy einfach irgendwelche neuen Container und die haben dann ein paar spezifische Labels mit. Das ist die Domain und so weiter, weil der Traffic ja an den Docker Socket geht. Dann registriert er die automatisch und, ja, launcht den. Und dann ist er da. Und das macht's halt superbequem, einfach mal einen neuen Container zu launchen, einfach mal eine neue Testwebseite zu launchen oder, oder, oder.
Wolfi Gassler (00:17:39 - 00:17:49)
Das heißt, man kann da wahrscheinlich dann auch extrem einfach Staging-Environments und solche Dinge machen, weil man da einfach einen neuen Container hochfahren kann und dann automatisch in das Subdomain verknüpfen kann.
Andy Grunwald (00:17:49 - 00:17:55)
Ja, ja, genau. So mach ich das auch. Und dann immer, wenn ich was noch nicht öffentlich machen möchte, pack ich da so einen htaccess-out vor.
Wolfi Gassler (00:17:56 - 00:18:25)
Der einzige Nachteil, das geht nur mit der kostenpflichtigen Traffic-Version, dass man mehrere Traffic-Server am Start hat, dass man wirklich Load Balancing davor auch schon machen kann und dann die Zertifikate dementsprechend verteilt über die verschiedenen Instanzen von Traffic. Das geht nur in der kostenpflichtigen Pro-Variante, aber das ist dann natürlich schon für viel größere Setups, wo man irgendwelche Docker Swarms oder Hochverfügbarkeiten Challengst du mich nicht.
Andy Grunwald (00:18:25 - 00:18:28)
Die ganze Zeit mit Over-Engineering?
Wolfi Gassler (00:18:28 - 00:18:44)
Ja, natürlich, aber es gibt ja auch andere Leute, die haben Side-Projects, die sind wichtiger als nur so Spielereien nebenbei und die brauchen dann, haben dann vielleicht solche Anforderungen. Bist du so einer? Möchte ich jetzt gar nicht beurteilen.
Andy Grunwald (00:18:44 - 00:18:48)
Du hast aber auch ein Side-Project am Start, oder? Und soviel ich weiß, nutzt du da auch so ein paar Swarm, oder?
Wolfi Gassler (00:18:49 - 00:19:17)
Ich nutze Docker Swarm und habe aber auch dieses Problem noch nicht gelöst, dass wenn ich mehrere Instanzen von dem Inbound Gateway hätte, dass die Zertifikate geshared werden. Das ist natürlich ein dummes Problem einfach mit Docker und persistenten Storage, den man irgendwie braucht und von mehreren Instanzen angesprochen wird und so weiter. Also das ist ein komplexes Problem, das man vielleicht gar nicht unbedingt lösen will so schnell.
Andy Grunwald (00:19:17 - 00:19:24)
Also das Feature, was du gerade erwähnt hast, was es nur in der Pro- oder Enterprise-Variante von Traffic gibt, das brauchst du gerade wirklich?
Wolfi Gassler (00:19:24 - 00:19:38)
Ich hätte es gerne, aber ich hab's einfach nach hinten geschoben. Ich verwende derzeit meinen eigenen NGINX-based inbound gateway, also reverse proxy NGINX, und der macht alles, aber da gibt's nur eine Instanz aktuell.
Andy Grunwald (00:19:38 - 00:19:44)
Und wieso nutzt du da nicht einfach irgendwie, weiß ich nicht, von AWS irgendwie so einen Load Balancer oder von Google oder Ähnliches?
Wolfi Gassler (00:19:45 - 00:20:16)
Es gibt auch zum Beispiel bei Hetzner Cloud, das ist ja ein sehr günstiger Anbieter aus Deutschland, der wirklich super Preise hat im Vergleich zu den zu den großen wie Google oder AWS und die haben auch einen Load Balancer mittlerweile, der aber schon meiner Meinung nach recht teuer ist, wenn man viele Domains hat und einiges damit machen will und meines Wissens ist er auch nicht verteilt auf zwei Nodes, also der löst dieses Problem auch nicht.
Andy Grunwald (00:20:16 - 00:20:27)
Moment mal, also reden wir über ein Projekt oder reden wir gerade über mehrere Projekte, wenn du sagst viele Domains? Oder hast du ein Side-Project, was irgendwie automatisch Domains kauft und irgendwie so Affiliate-Marketing-Scam-Kram macht?
Wolfi Gassler (00:20:28 - 00:21:49)
Es fühlt sich teilweise so an, als würden Domains automatisch bei mir gekauft werden. Aber das ist, glaube ich, ein anderes Problem. Auf dem Docker Swarm laufen natürlich mehrere Projekte und das soll alles dieselbe Infrastruktur nutzen. Aber erfahrungsgemäß, egal wo man ist, Server fallen aus und es wäre halt einfach nett, wenn es da Failover gäbe oder Loadbalancing, wie man das auch immer dann realisiert. Aber erfahrungsgemäß hat man das einfach viele Kopfschmerzen schon bereitet, weil dieses Projekt oder eines der größeren Projekte im Bezug von, oder wenn man es von User-Sicht sieht, ist so eine Lernplattform in Österreich, wo man sich auf den österreichischen Führerschein vorbereiten kann, auf die theoretische Prüfung vom österreichischen Führerschein. Und wir haben da doch relativ viele User und sobald da mal was kracht oder irgendwas offline ist, hast du sofort eine volle Mailbox mit Usern, die sich beschweren. Da werden bis zu so eine Million, eine Million Fragen pro Tag gelernt von Leuten und da hast du natürlich sofort eine volle Mailbox und da hat sich einfach gezeigt, wenn du da eine Ausfallsicherheit hast, wenn sich die leicht irgendwie machen lässt dann hat es natürlich schon vorteil und nimmt dir auch stress weg weil du dann halt einfach zeit hast um irgendwas zu fixen.
Andy Grunwald (00:21:49 - 00:21:51)
Das bedeutet auch du hast dafür Monitoring.
Wolfi Gassler (00:21:51 - 00:21:53)
Dafür habe ich Monitoring.
Andy Grunwald (00:21:53 - 00:22:02)
Wie sieht dein Monitoring-Stack aus? Ist das wirklich so Prometheus, Grafana, Obstgenie für On-Call und was es da nicht noch alles gibt oder was ist das?
Wolfi Gassler (00:22:02 - 00:23:03)
Wir wollen gerade umstellen auf einen neuen Server und wollten bei dem alten Server eigentlich nicht mehr so viel Monitoring machen. Und daher gibt es auch kein Monitoring, ob die Festplatte voll läuft. Und natürlich, was gerade kürzlich vor ein paar Tagen passiert ist, ist, dass die Festplatte vollgelaufen ist aus irgendeinem Grund. Es waren glaube ich hauptsächlich Dockerlogs. Und die ganze Seite ist gestanden aus dem Grund, Oder würde ich mal sagen, dass Monitoring sehr, sehr wichtig ist und man sollte das nicht so lange aufschieben. Monitoring, finde ich, könnte man auch bei kleinen Sideprojekts relativ leicht realisieren. Was ich verwende für Monitoring ist die Google Cloud. Da kommt man relativ weit mit dem kostenlosen Free Tier und kann so Basics eigentlich relativ schnell realisieren, einfach mal ob ein Endpoint online ist und bekommt dann recht schnell Slack Messages oder was man auch immer definiert als Notification Channel. Das funktioniert also relativ problemlos.
Andy Grunwald (00:23:03 - 00:23:39)
Ich glaube, jede Person, die im Bereich Backend-Infrastruktur arbeitet, lacht sich gerade kaputt, weil du bist gerade in das One-on-One-Monitoring-Problem gelaufen. Festplatte ist voll und man hat die Lock-Rotation vergessen. Und die zweite Geschichte ist, ich glaube, jede Person im Infrastrukturbereich kräuselt sich grad irgendwie so nein bitte tu das nicht so die die nägel wenn du sagst ja man kommt sehr weit mit dem mit dem mit dem fried hier von google cloud aber wenn man da 35 lambda functions laufen lässt. Dann kann die rechnung auch mal ganz anders aussehen weil ich meine du hast.
Wolfi Gassler (00:23:39 - 00:23:44)
Ja ich spreche ich spreche nur vom monitoring also das monitoring da kommt man relativ weit.
Andy Grunwald (00:23:44 - 00:23:50)
Achso Moment du du hast jetzt du hast also jetzt deine server bei hetzer und bei google cloud machst du dann jetzt das monitoring oder was.
Wolfi Gassler (00:23:51 - 00:23:52)
Korrekt, ja.
Andy Grunwald (00:23:52 - 00:23:54)
Wieso?
Wolfi Gassler (00:23:54 - 00:24:59)
Weil Google einfach ein sehr einfaches Monitoring hat, das man aufsetzen kann. Also man kann sowohl interne Daten wie Speicherplatz und so weiter über einen Docker-Container recht einfach zu Google pipen und dort verarbeiten, aber die Basic Checks, um einfach einen API Endpoint zu checken, das sind einfach zwei Klicks in Google Cloud. Das ist wirklich super einfach, Notifications laufen stabil und ist auch alles leicht einzurichten. Und daher war das für mich die erste Wahl, weil es einfach eigentlich kostenlos ist und gut funktioniert. Das ist alles. Und sonst müsste man halt irgendeinen Service verwenden, wo man wieder 5 oder 10 Euro pro Monat zahlt und Google Cloud in dem Fall einfach leicht ausreichend ist und super einfach. Und es ist ja, wie gesagt, ich habe dieses Monitoring für diesen neuen Docker Swarm Cluster habe ich schon, aber derzeit läuft das Projekt noch auf einem alten Server und dort war mir einfach die Zeit zu schade, dass ich dort nochmal dieses Monitoring installiere. Und hab mir gedacht, ich zieh sowieso das Projekt gleich um, aber gleich ist halt immer relativ.
Andy Grunwald (00:24:59 - 00:25:04)
Aber hat Hetzner Cloud nicht irgendwie so ein Monitoring?
Wolfi Gassler (00:25:04 - 00:25:06)
Meines Wissens nicht.
Andy Grunwald (00:25:06 - 00:25:07)
Das ist ja strange.
Wolfi Gassler (00:25:07 - 00:26:03)
Ja, Hetzner Cloud ist ein super einfaches, die haben super einfach begonnen, eigentlich nur mit virtuellen Maschinen, die man hochfahren kann und jetzt langsam fügen sie neue Features hinzu, wie zum Beispiel eben der Load Balancer oder dass man interne Netzwerke machen kann. Also die fangen, die sind mit dem Feature Development sehr, sehr langsam im Vergleich zur AWS natürlich, aber es ist einfach ein unschlagbarer Preis. Ich glaube, da Die kleinste VM kostet irgendwie drei Euro pro Monat oder so und sobald man mal mit AWS oder GCB außerhalb vom Free Tier gearbeitet hat, weiß man, wie schnell das nach oben skaliert, also auch der Preis skaliert sehr schnell nach oben. Du hast ja sehr viel mit Google, mit GCB gearbeitet und hast ja auch so, ich glaube, mindestens siebenstellige Rechnungen oder so verwaltet. Mit GCB, was wäre dein Tipp, um die unter Kontrolle zu halten, die Kosten?
Andy Grunwald (00:26:03 - 00:26:06)
Das Einfachste würde ich da jetzt erstmal Budget Alerts einstellen.
Wolfi Gassler (00:26:06 - 00:26:14)
Das heißt ich kann einfach eine Notification einstellen ab 10, wenn ich 10 Euro überschritten habe, dann send mir eine E-Mail.
Andy Grunwald (00:26:14 - 00:26:18)
Genau, du kannst in der Billingkonsole geht das irgendwo. Also das ist das Einfachste.
Wolfi Gassler (00:26:19 - 00:26:21)
Okay, werde ich auf jeden Fall machen.
Andy Grunwald (00:26:21 - 00:26:41)
Du sagtest gerade, das ist schon relativ alt, das Projekt. Was heißt alt? Wie sieht der Tastestack eigentlich aus? Okay, wir haben jetzt Docker Swarm, wir haben Hetzner Cloud, wir haben einen NGINX Ingress, den du ersetzen möchtest mit Traffic. Wir haben mehrere Server. Was ist mit dem Rest?
Wolfi Gassler (00:26:42 - 00:27:01)
Dieses Projekt ist, glaube ich, zehn Jahre alt oder über zehn Jahre alt schon. Ist natürlich immer wieder mal recht spät, aber doch geupdatet worden und mit neuer Technologie, eben läuft mittlerweile auf Docker. Vor zehn Jahren war das natürlich noch kein Docker. Ist auch eine extrem alte PHP-Version, leider noch.
Andy Grunwald (00:27:02 - 00:27:07)
Jetzt sei mal ehrlich, ist es PHP 3 oder 4 oder wo sind wir da?
Wolfi Gassler (00:27:08 - 00:27:16)
Eine gute Frage, was das vor 10 Jahren war, war schon PHP 5, glaube ich. Wir verwenden Zend Framework 1.
Andy Grunwald (00:27:16 - 00:27:19)
Also ihr verwendet jetzt gerade noch Zend Framework 1?
Wolfi Gassler (00:27:19 - 00:27:20)
Ja, korrekt.
Andy Grunwald (00:27:21 - 00:27:21)
Das ist ein Brett.
Wolfi Gassler (00:27:21 - 00:27:29)
Man muss da auch einiges machen, damit man das auf neuen PHP-Versionen zum Laufen kriegt und in Docker und so weiter.
Andy Grunwald (00:27:29 - 00:27:31)
Also habt ihr eine modifizierte Version von Zend Framework dazwischen?
Wolfi Gassler (00:27:32 - 00:27:36)
Glaubt es ist sogar eine modifizierte version damit es mit mit bhp 7 läuft.
Andy Grunwald (00:27:37 - 00:27:41)
Ich bin schockiert ich hätte es jetzt.
Wolfi Gassler (00:27:41 - 00:27:48)
Auch nicht verraten sollen weil wahrscheinlich probieren jetzt ganz viele leute irgendwie diese diesen server zu hacken also eins kann man.
Andy Grunwald (00:27:48 - 00:27:52)
Dir nicht vorwerfen zumindest nicht bei deinem php-stack und das ist overengineering Definitiv.
Wolfi Gassler (00:27:52 - 00:28:04)
Es ist auch der PHP-Code von vor 10 Jahren, der noch läuft primär eigentlich. Der Client, da wurde mal eine neue Version gemacht, aber PHP ist noch, glaube ich, ziemlich die originale Version.
Andy Grunwald (00:28:04 - 00:28:13)
Und jetzt die Frage, warum willst du erst die Server umziehen, den Ingress-Load-Balancer wechseln und hast dann so eine Leiche im Keller?
Wolfi Gassler (00:28:14 - 00:29:08)
Primär, weil, wie gesagt, die User stört es weniger, ob da sehr alter PHP-Code im Hintergrund läuft. Die User interessiert es nur, ob das Ganze online ist. Und wie gesagt, da läuft recht viel Traffic drauf, paar Millionen Requests pro Tag auf dem ganzen System. Und da ist Ausfallsicherheit halt doch sehr praktisch, wenn man da den Stress wegbekommt, den man hat sonst, wenn irgendwas ausfällt. Und wir sind halt nur vier Leute und da muss man dann immer jemanden finden, der Zeit hat, um irgendwas zu fixen, die Leute zu beruhigen, Messages zu schreiben, zu antworten. Das macht dann schon viel aus und wenn man das im Vorhinein durch ein paar einfache Aktionen ändern kann, dann ist das schon sehr hilfreich. Aber zu meiner Verteidigung, wir arbeiten auch gerade an neuen Versionen und dass der Code neu geschrieben wird.
Andy Grunwald (00:29:09 - 00:29:17)
Aber müsst ihr da oft ran an den Code? Also macht ihr da ziemlich viele Modifikationen, neue Features, Bugfixes etc.? Oder sagt ihr, die letzten zwei, drei Jahre habe ich da nichts gemacht?
Wolfi Gassler (00:29:17 - 00:29:49)
Da ist sehr, sehr wenig passiert eigentlich in dem Bereich. Mal hin und wieder irgendein kleines Problem fixen, aber eigentlich im JavaScript-Code, der auch extrem alt ist, der aktuelle, der läuft. Das läuft auf Frameworks, die gibt's gar nicht mehr. Und jedes Mal, wenn man kompiliert, ist es eine große Spannung, ob das irgendwie durchkompiliert oder ob man's irgendwie wieder zum Laufen bringt überhaupt. Also, JavaScript ist da ein größerer Pain. Ich bin eigentlich sehr erstaunt, wie gut BHP funktioniert, so zehn Jahre Alter kommt.
Andy Grunwald (00:29:49 - 00:29:58)
Also, okay, wir reden jetzt hier nicht von React, Vue.js. Wir reden eher so jQuery, Mutools oder Scriptaculous und solche Geschichten. Wovon reden wir hier?
Wolfi Gassler (00:29:59 - 00:30:19)
Also bei JavaScript verwenden wir das Marionette-Framework. Es basiert auf Backbone. Das kennst du wahrscheinlich noch, Backbone. Und Marionette war so ein Framework drübergestülpt, das nochmal diese ganzen Sachen schön separiert mit Templates, mit Daten und View und solche Geschichten.
Andy Grunwald (00:30:19 - 00:30:23)
Ja, Moment mal, aber Backbone ist ja schon nach jQuery.
Wolfi Gassler (00:30:24 - 00:30:41)
Backbone war nach jQuery, jQuery gibt es ja immer noch meines Wissens, aber wenn man natürlich größere App baut und das ist schon komplexer Client, dann willst du da schon professionelleres Framework haben und das war halt zu damaliger Zeit eines davon war Marionette.
Andy Grunwald (00:30:41 - 00:30:46)
Und wenn du sagst kompilieren, ich meine PHP muss ja nicht kompiliert werden, was kompilierst du da mit? Javascript?
Wolfi Gassler (00:30:47 - 00:31:08)
Ja, da kompilieren, aber du musst halt bilden und du hast ja extrem, du kennst ja Javascript, hunderttausende Abhängigkeiten. Und das Ganze fliegt dir halt meistens um die Ohren, weil irgendwie ein Package nicht mehr existiert oder irgendwie nicht mehr bilden kann und so weiter. Also da gibt's da gibt's schon viele, viele Probleme jedes Mal, wenn man diesen Build anwirft.
Andy Grunwald (00:31:08 - 00:31:26)
Also klar, ich kenne, ich kenne Webpack, Babel und wie sie alle heißen, aber ich habe nicht erwartet, dass euer Javascript-Stack das schon nutzt? Weil früher hab ich eine Javascript-Datei gehabt, die liegt in meinem Dockroot, und die mach ich dann per Script-Tag, inkludiere ich die da, und da war nichts mit Precompile und Asset-Building und wie so aller.
Wolfi Gassler (00:31:26 - 00:31:56)
Wir hatten einen, oder wir haben immer noch einen Spezialisten im Team. Mittlerweile macht er kaum mehr Javascript, aber damals war er sehr viel unterwegs im Javascript-Raum. Und der hat uns eigentlich diese ganzen Tools schon näher gebracht. Wir verwenden Grunt zum zum Bilden und machen da auch Asset Building und so weiter. Aber das war alles vor Webpack Zeiten natürlich. Also das ist schon alles noch sehr oldschool und es ist auch sehr rot, wenn man das Ganze bildet.
Andy Grunwald (00:31:56 - 00:32:21)
Okay, okay, okay. Wir haben ein ganz altes PHP, ein noch älteres Zen-Framework. Wir haben, ich würd schon fast sagen, ein adäquates JavaScript. Du bist ja schon im Compilesektor drin, das ist ziemlich cool. Habt ihr irgendwelche APIs oder Ähnliches? Oder ist das wirklich PHP ... surft die Webseite und gut ist? Habt ihr eine REST-API, eine GraphQL-API, eine SOAP-API, irgendwie so was?
Wolfi Gassler (00:32:21 - 00:32:45)
SOAP wär nett, ja. Nein, auf keinen Fall. GraphQL hat es damals natürlich noch nicht gegeben. Es ist so eine mehr schlechte als rechte REST API, würde ich mal sagen. Das waren noch die guten alten Zeiten, wo man alles irgendwie in die Payload gebackt hat, um irgendwelchen Status zu senden oder zum Client zu schicken. Es ist keine schöne REST-API, aber sie funktioniert.
Andy Grunwald (00:32:45 - 00:32:55)
Die nutzt ihr ... Habt ihr alles strikt getrennt, REST und AJAX und allem? Oder sagt ihr, okay, ihr macht auch sogenanntes Server-Side-Rendering, wie man's heutzutage nennt?
Wolfi Gassler (00:32:56 - 00:33:10)
JavaScript ist komplett independent und läuft eigenständig. Kann auch auf einem anderen Server laufen. Also ist komplett getrennt, PHP und JavaScript. War ganz ursprünglich auch teilweise anders, ist jetzt aber komplett getrennt.
Andy Grunwald (00:33:10 - 00:33:11)
Welche Datenbank nutzt ihr?
Wolfi Gassler (00:33:11 - 00:33:14)
Wir nutzen MySQL, ja. Irgendwas, irgendwas, irgendein cooles Feature davon?
Andy Grunwald (00:33:14 - 00:33:19)
Oder wirklich nur, hier ist eine Datenbank, da sind fünf Tables und wir machen Select und Insert?
Wolfi Gassler (00:33:19 - 00:34:04)
Wir verwenden die Datenbank sehr stark, weil wir den Lernstand von jedem User speichern. Und du kennst es ja von den Fragen für den Führerschein. Das sind so 1600 Fragen. Ich glaube, in Deutschland ist es ähnlich viel. Das heißt, bei jedem User speichern wir einen Lernstand von 1600 Fragen. Wenn du viele User hast, dann geht das schon relativ schnell in die Millionen oder noch mehr Zeilen in so einer Tabelle. Also die Datenbank ist eigentlich ziemlich groß und macht sehr viel. Grundsätzlich verwendet man eigentlich nur Basisfunktionen, würde ich mal sagen, keine fancy Features. Das einzige, was wir vielleicht verwenden, würde ich heutzutage auch anders machen, sind Trigger. Die waren damals ja ganz cool und neu in MySQL.
Andy Grunwald (00:34:04 - 00:34:05)
Die nutzt ihr gerade aktiv?
Wolfi Gassler (00:34:05 - 00:34:56)
Die nutzen wir, das wurde aber heutzutage garantiert, anders machen. Damals war das so eine Idee, dass wir da einfach die Performance von der Datenbank mitnehmen können, damit wir eben nicht zehn SQL Queries abfeuern müssen, sondern eine SQL Query und danach schmeißt sich der Trigger an und korrigiert irgendwelche Statistiken oder sowas zum Beispiel. Das würde ich heutzutage einfach alles in die App legen, in den Code, weil du hast jetzt wieder zwei Bereiche, wo du eigentlich Logik hast. Du hast einmal in der Datenbank Logik und einmal in deinem Code Logik, was extrem schwierig ist und Debugging natürlich schwieriger macht. Und das bisschen, was man da wirklich aus Performancegründen rausholt, ist es heutzutage auf keinen Fall mehr wert, einfach diese Komplexität mit reinzubringen in deine Software.
Andy Grunwald (00:34:57 - 00:35:07)
Jetzt sagst du, okay, wir sind bei der Hetzner Cloud, wir haben Monitoring bei Google, wir haben Docker Swarm, wir haben MySQL mit Triggers, wir haben eine super alte PHP-Version, wir haben NGINX und Ingress Gateway. Was haben wir noch?
Wolfi Gassler (00:35:07 - 00:35:09)
Das war's?
Andy Grunwald (00:35:09 - 00:35:15)
Du hast jetzt die Aufgabe, F Online noch mal neu zu bauen. Was würdest du anders machen? Wie würde der Stack heute aussehen?
Wolfi Gassler (00:35:16 - 00:36:39)
Also wenn man das heutzutage betrachtet, wie leistungsstark die ganzen Handys und Endgeräte sind, würde eigentlich wesentlich mehr Logik auf den Client bringen, weil wir lösen jetzt eigentlich fast alles in der Datenbank. Also der Großteil der Logik beziehungsweise der ganzen Speicherung, auch vom Lernstand und so weiter, funktioniert so, dass man in der Datenbank alles halten, speichern, ändern. Der Client macht eigentlich sehr wenig. Der Client zeigt nur an. Wenn ich das neu bauen müsste, die neue Architektur, würde ich auf jeden Fall alles am Client speichern und nur ein Backup oder irgendwie eine Synchronisation mit dem Server machen. weil der Lernstand betrifft ja immer nur einen User und andere User brauchen die Information gar nicht. Das heißt, wir speichern alles zentral, obwohl wir eigentlich das ganze zentral gar nicht benötigen würden. Also wenn man jeden User das einfach im Client machen lassen würde und dann das Ergebnis einmal am Server abspeichert, das könnte man wahrscheinlich sogar in Dateien abspeichern, wenn man es ganz, ganz dumm macht, weil der User greift ja immer nur seine eigenen Daten an, dann könnte man das wesentlich vereinfachen und würde extrem viel Load von der Datenbank wegbringen zum User. Und der User könnte dann auch noch offline lernen zum Beispiel, was er jetzt nicht kann, weil er immer online sein muss.
Andy Grunwald (00:36:39 - 00:36:40)
Was würdest du an der Infrastruktur ändern?
Wolfi Gassler (00:36:41 - 00:38:00)
Die Infrastruktur ist eigentlich relativ modern, würde ich mal sagen. Wie gesagt, docker-based und ist eigentlich sehr flexibel. Da würde ich eigentlich wenig ändern. Auch BHP ist immer noch meiner Meinung nach sehr, sehr stark. Das könnte man natürlich ersetzen mit einer anderen Sprache, aber das macht dann auch nicht viel Unterschied. Aber einfach eine schöne API, die sauber definiert ist. Von Anfang an eine saubere Trennung. Client-Server ist glaube ich wichtig. Und dann das Ganze möglichst einfach halten. MySQL würde ich auf jeden Fall wiederverwenden. Ist einfach extrem stark, verlässlich, einfach zu warten. Ich würde nie auf irgendein MongoDB oder sowas setzen. braucht es auch nicht. Wie gesagt, wir haben ein paar Millionen Requests jeden Tag und das Ganze läuft auf einem Server und der ist nicht mal ausgelastet. Also da braucht man überhaupt nicht an irgendeine Skalierung von MySQL denken. Das ist super, super stark und wenn man skalieren müsste, könnte man immer noch sagen, okay, man setzt MySQL auf einen eigenen Server und kann so skalieren, aber aktuell sitzt alles auf einem Server und der ist vielleicht zu 30 Prozent ausgelastet. Ja, ich glaub, ganz allgemein mal unterschätzt eigentlich, wie stark solche Nodes oder VMs eigentlich sind.
Andy Grunwald (00:38:00 - 00:39:32)
Ich denke, dass Engineers generell ein Problem haben. Und dass, wenn sie keinen ganz klaren Produktmindset haben, dass sie generell overengineeren. Und so war das bei mir auch. Ich hatte mal ein anderes Side-Project, das nannte sich ZS Lead. Und die Grundidee war folgende. Gib einem, welches Sport-Equipment du hast und der spuckt dir die Workouts aus. Und was ich da gemacht hab, ist, ich hab gedacht, hey cool, wenn ich irgendwo bin, draußen, dann hab ich ja kein Laptop dabei, also mein Handy, also wird das eine Mobile-First-App. Grandios. Was nimmst du da? React Native, Flutter. Da hab ich mir erst mal einen Videokurs gekauft und hab erst mal 40 Stunden Flutter gelernt. Völlig overengineert, bin ich ganz ehrlich. Hab dann auch irgendwie eine App hingekriegt, hab die dann auch auf mein Handy deployed. Und dann, hm, wie komme ich denn jetzt an die Daten? Ja, die müssen irgendwie serverseitig sein. Ich kann die jetzt alle, die ganzen Workouts in die App mitliefern, aber ich will die ja irgendwie, weiß ich nicht, vom Server auch bedienen. Okay, dann machst du eine GraphQL API und so weiter. So hat sich das dann alles weiterentwickelt. Auf einmal hatte ich da so ein mega Stack, hab super viel Zeit investiert und hab's noch niemals geschippt. Ja? Und warum? Weil ich dachte, ja, das ist ein bisschen ein Startup, das muss modern sein, das ist ein Side-Project. Aber eigentlich hab ich die App leider selbst nie genutzt. Und irgendwann hab ich's halt einfach aufgegeben, weil ich sehr frustriert war, dass ich was geschrieben habe, was ich nie genutzt habe. Obwohl ich natürlich sehr, sehr viel gelernt hab. Ich hab gelernt, wie ich den GraphQL-Server aufsetze, wie das Node-Resolving da läuft, et cetera, et cetera. Traurige Geschichte.
Wolfi Gassler (00:39:32 - 00:40:01)
Wir haben das ja in der letzten Episode schon besprochen mit den Side Projects. Es kommt immer darauf an, was für ein Ziel du hast und in dem Fall hast du extrem viel gelernt, was du jetzt auch einsetzen kannst für Source Control zum Beispiel. Also wie Traffic funktioniert. Also es gibt ja schon auch Learnings, die man da rausziehen kann. Aber ganz klar, ich glaub, das Wichtige ist einfach, dass man möglichst schnell eine funktionsfähige Version mal rausbringt, und alles andere kann man dann am Weg optimieren und verbessern.
Andy Grunwald (00:40:01 - 00:41:06)
Ja, das Riesenproblem ist halt einfach nur, du musst dich damit zufriedengeben, dass die erste Sache, die du schippst, peinlich ist. Und eigentlich ist sie so peinlich, dass du dich gar nicht traust, das zu veröffentlichen. Weil jeder von uns weiß, zu was wir fähig sind, wenn wir genug Zeit haben. Und das ist eigentlich so supertraurig. Aber eigentlich, wenn man sich darauf einlässt, dann geht's super. Also, wie hab ich mit Source Control angefangen? Ich hab zuerst den Deployment-Prozess gebaut und habe dann einen Default-Nginx-Docker-Container eingecheckt und der wurde automatisch deployed. Das bedeutet, auf der Domain kam dann eine Nginx-Hello-World-App. Ja, Default-Nginx-Docker-Container. Und von da aus hab ich dann weitergemacht. Ich hab dann den Nginx-Docker-Container irgendwann weggespitzen, hab dann eine Golang-Applikation hingepackt, die dann einfach nur ein Hello World per Web-Server ausgibt. geschickt und von so hab ich dann wirklich continuous deployment oder delivery, weiß ich grad gar nicht, ohne freigabe auf jeden fall, ich hab's committed und dann ging's sofort live, aber es interessiert ja keinen, weil keiner geht auf die domain, also ist ja jetzt nicht so als wartet die welt auf mein zeitprojekt. Hast du auch so Probleme oder bin ich der Einzige?
Wolfi Gassler (00:41:06 - 00:42:38)
Nein, natürlich. Das ist ein ganz klassisches Problem, das wir alle haben. Ich habe da auch ein sehr gutes Beispiel aus ganz alter Zeit. Ich war noch ziemlich jung und das war glaube ich vor der 2000-Wende. Und zwar habe ich damals ein Content-Management-System programmiert. Und das war lang vor der Zeit, bevor Content-Management-Systeme Open Source waren. Das war wirklich eine andere Zeit. Ich habe da ein CMS programmiert und das hat eigentlich schon grundlegend funktioniert, aber was für mich ganz wichtig war, war das Rechtesystem. Und ich habe da ein extrem aufwändiges Rechtesystem programmiert, wirklich, dass man auf Unterordner Rechte geben kann und verschiedene, jede Aktion hat ein eigenes Recht. Und ich habe das Ding dann schlussendlich auch abgeschlossen. Hat natürlich viel, viel länger gedauert als erwartet. Und alle Benutzer, die wir gehabt haben, und wir hatten Kunden damals, die das verwendet hatten, Die hatten genau einen Admin und der Admin hat einfach Zugriff auf alles bekommen. Und kein einziger hat jemals dieses Rechtesystem verwendet. Also hätte ich das Rechtesystem einfach programmiert am Anfang, hätte ich wahrscheinlich ein halbes Jahr gespart und wäre früher am Markt gewesen und hätte mich dann darum kümmern können, was sind die Features, die die Kunden wirklich brauchen. anstatt ein super fein granulares rechtes System zu bauen. Also das ist, glaube ich, ganz, ganz wichtig, dann einfach anzufangen und dann zu schauen, was braucht der Kunde, was brauchen die User und wo wollen die hin, was ist für die wichtig und was bringt denen das, denen was im alltäglichen Leben, anstatt dass man immer von sich ausgeht.
Andy Grunwald (00:42:38 - 00:42:41)
Der Klassiker, ein eigenes Content-Management-System schreiben.
Wolfi Gassler (00:42:42 - 00:43:12)
Damals, also zu der Zeit, da waren Content-Management-Systeme wirklich, da hat man eine Million gezahlt für ein Content-Management-System. Okay, das waren noch Shilling-Zeiten. Das ist jetzt schwierig für dich umzurechnen. Und Open Source gab es einfach nicht. Daher war das eigentlich eine gute Idee, in CMS zu programmieren. Und es hat auch Verwendung gefunden. Aber ich glaube eben, wenn ich solche Sachen auch besser beachtet hätte damals, dass man sich eben mehr auf den Kunden konzentriert und weniger auf seine eigenen Ideen wie das komplexe rechte System, dann wäre die ganze Sache wahrscheinlich auch erfolgreicher geworden.
Andy Grunwald (00:43:12 - 00:43:16)
Willst du mir grad sagen, dass du in Goldgräber-Stimmung warst bei der Dotcom-Bubble?
Wolfi Gassler (00:43:16 - 00:43:18)
Ja, und ohne meinem rechten System hätt's vielleicht sogar funktioniert.
Andy Grunwald (00:43:19 - 00:43:42)
Kommen wir mal wieder von den Trainings weg. Super Story mit F1-Line. Ich habe sehr viel mitgenommen. Ich wusste nicht, dass man Zen Framework 1 noch auf PHP 7 betreiben kann. Also, falls da jemand Interesse daran hat, wie man das macht, schreibt dem Wolfgang ruhig eine E-Mail. Der bringt euch das bei. Und MySQL scheint wirklich immer noch eine Datenbank zu sein, wo es sich lohnt, sie einzusetzen. Felix, ich weiß, GitHub und Booking laufen auf MySQL, ne?
Wolfi Gassler (00:43:43 - 00:43:43)
Ja, korrekt.
Andy Grunwald (00:43:44 - 00:44:13)
Okay, das war's wieder mit einer weiteren Folge vom Engineering-Kiosk. Vielen Dank an alle Hörerinnen und Hörer. Lasst uns doch mal bitte wissen, was für Side-Projects ihr so macht und was ihr für Learnings rausgezogen habt. Und wie euer Tech-Stack aussieht, das interessiert mich. Overengineert ihr? Oder sagt ihr, ha? Static HTML-Seite und Abfahrt. Und ich gehe voll die No-Code-Route. Das würde uns mal interessieren. Und Wolfgang, wo können die Leute uns kontaktieren?
Wolfi Gassler (00:44:13 - 00:44:40)
Also einerseits auf Twitter natürlich. Das ist unser Hauptkanal, würde ich mal sagen. Aber wenn ihr lieber ein E-Mail schreibt, wir haben die E-Mail-Adresse jetzt stetig at engineeringkiosk.dev. Verlinken wir natürlich auch in den Show Notes. Gerne ein E-Mail. Auch ein E-Mail, wenn ihr irgendwelche Vorschläge habt, was wir denn besprechen sollten. Wenn ihr irgendwelche Fragen habt oder sonstiges Feedback. Wir freuen uns auf jeden Input natürlich.
Andy Grunwald (00:44:40 - 00:44:41)
Genießt den Tag. Bis zum nächsten Mal. Tschüss.