In unserer WUE.tech-Meeetup-Reihe haben wir es uns zum Ziel gesetzt, ein möglichst breites Spektrum an Technologien abzudecken. Wir hatten JavaScript-Themen ebenso wie Mobile-Deployment und Meetups aus den Bereichen GraphQL und Swift. Dieses Mal werden wir uns wieder mit etwas ganz anderem beschäftigen, nämlich mit leichtgewichtigen Microservices in Go.
Unser Alex hat nicht nur ein Pet Project in Go geschrieben, sondern setzt die Sprache auch erfolgreich in einem Kundenprojekt ein. Und weil er so davon überzeugt ist, wird es statt eines kleinen Frontalvortrags-Meetup am 23. Juni gleich einen ganzen Remote-Workshop geben, in dem ihr live mitcoden könnt, wenn ihr wollt.
… und mal ehrlich: wieso solltet ihr das nicht wollen?
Was euch erwartet, wie es um die Lernkurve steht und noch ein paar andere Details findet ihr in diesem kleinen Interview mit Alex.
Wie bist du auf Go(lang) gekommen?
Alex: Ich bin darauf gekommen, weil ein paar Kollegen bei uns das in einem anderen Projektkontext verwendet hatten. Zusätzlich sind aktuell sehr bekannte Tools wie Kubernetes und diverse andere Kommandozeilentools, die man so im Alltag benutzt, in Go implementiert. Was man manchmal zum Beispiel oft auch an den Fehlermeldungen im Logfile sieht. Daraufhin dachte ich mir, dass ich mir das auch einmal anschauen muss.
Was würdest du sagen sind typische Anwendungsfehler?
Alex: Zu typischen Anwendungsfehlern fällt mir aktuell nichts ein. Ich glaube, dass man sehr stark umdenken muss, wenn man diese Programmiersprache benutzt. Schon alleine weil man abseits der klassischen Objektorientierung denken muss. Damit hat es nämlich erst einmal nichts zu tun.
Man muss sich sozusagen auf die Denkweise von Go einlassen. Wenn man das nicht tut, macht man vielleicht Fehler. Zum Beispiel, wenn man versucht Sachen in Go so zu implementieren wie man sie in PHP oder TypeScript implementieren würde. Dadurch, dass Go ein anderes Konzept verfolgt, kommt man damit dann nicht so weit. Andererseits ist das genau das Spannende an Go. Sonst bräuchte man sich ja nicht damit zu beschäftigen, weil es eben gerade Dinge anders macht.
Konntest du die Sprache schon einmal in einem Projekt anwenden? Wenn ja, was hattet ihr dadurch für Vorteile?
Alex: Ja, konnte ich. Ich habe ein privates „Rumspiel-Projekt“, in dem ich Go benutze. Und zusätzlich auch aktuell im Kundenprojekt.
Go ist quasi das krasse Gegenteil zu Java und Spring Boot.
Alex
Vorteile durch die Verwendung im Projekt sind eigentlich die klassischen Vorteile von Go: Man kompiliert es am Ende und hat dann ein statisches, ausführbares File. Das heißt gerade bei Microservices besteht der Vorteil dann darin, dass man keine besondere Laufzeitumgebung mehr braucht und es sehr schlank ist; man packt es in ein Docker-Image und deployed es einfach.
Mal ein konkretes Beispiel: Ein Cluster-Deployment besteht bei uns aktuell einfach darin, dass wir den Pod löschen und er zieht sich dann das neue Image beim Restart. Das dauert tatsächlich nur ein paar Sekunden und dann ist er schon wieder hochgefahren und gestartet. Das geht also rasend schnell und ist sehr, sehr leichtgewichtig.
Wenn man mehrere von diesen Services in Go baut und jeder seine einzelnen Aufgaben macht, hat man eine Summe aus kleinen, schlanken Services, die sich schnell starten, stoppen und neu deployen lassen. Das finde ich zum Beispiel sehr schön. Das krasse Gegenteil zu Java und Spring Boot; also das entgegengesetzte Konzept sozusagen.
Wie lange dauert es in etwa, sich sattelfest in Go einzuarbeiten?
Alex: Für mein Gefühl hat es sich von Anfang an recht gut und stimmig angefühlt. Da braucht man eigentlich nur ein paar Tage, bis man die Grundlagen verstanden hat. Bis man alle Go Idioms gelernt hat, dauert es natürlich etwas länger. Einfach weil es in Go nicht alle Elemente gibt, die es in anderen Sprachen gibt. Beispielsweise hat man keinen ternären Operator. Also die typischen Konstrukte, die es eigentlich in den meisten anderen, üblichen Programmiersprachen gibt, gibt es nicht, weil sich Go maschinennah und sehr low-level versteht.
In Go muss man auf viel Komfort verzichten; es gibt nur wenig Syntax Sugar.
Alex
Man muss auf viel Sprachkomfort verzichten, es gibt sehr wenig syntaktischen Zucker in Go. Das ist das Problem. Das ist am Anfang sehr ungewohnt, wenn man andere Programmiersprachen kennt. Da muss man erstmal lernen, wie man damit umgeht, um dann trotzdem noch den Programmcode relativ schlank zu schreiben.
Aber ansonsten fühlt sich das alles sehr stimmig an. Vor allem, da man eigentlich mit den wesentlichen Grundelementen sehr schnell vertraut ist und viel mit ihnen arbeitet, kommt man auch schnell voran. Man hat eine sehr steile Lernkurve, wie man so schön sagt. Man muss sich allerdings – wie gesagt – vom Denken der anderen bekannten Sprachen lösen.
Im aktuellen Projekt haben wir auch in der Infrastruktur sehr viele Go-Services. Es gibt ein übersichtliches Ökosystem bei Go. Du hast also nicht ein Problem mit der Wahl zwischen fünfzig Bibliotheken, die du benutzen kannst, sondern du hast halt zwei oder drei. Das heißt der Einstieg ist noch relativ leicht. Und es fühlt sich für mich irgendwie gut an, wenn du im Gesamtsystem sehr viele Applikationen hast, die auf Go-Basis sind.
In dem Projekt in dem wir gerade sind, haben wir unser API Gateway in Go, den Ingress-Controller in Go, das Event-System in Go und die eigene Applikation natürlich auch. Das heißt, wir haben jetzt vier grundlegende Komponenten, die alle in Go sind.
Was einem sofort auffällt ist, dass man die alle sehr schnell installieren kann. Es fühlt sich von der Denkweise ähnlich an, wie man damit umgeht, wie man es konfiguriert – es ist einfach ein stimmiges Gesamtkonzept.
Der Vorteil in dem Projekt ist, dass wir da nur sehr wenig Leute sind und jetzt deutlich die Komplexität im Stack reduziert haben. Das ist eben wieder dieses Thema von eben: Wenn man sich auf den Stack einlässt, hat man eine sehr hohe Funktionalität mit einer reduzierten Komplexität und – es fühlt sich alles irgendwie gut an. Das kann ich jetzt allerdings als Entwickler nur intuitiv beschreiben. Manchmal ist weniger mehr, sozusagen.
Gibt es auch etwas an Go(lang) was dir nicht gefällt?
Alex: Ja. Das Fehlerhandling ist sehr rudimentär. Es gibt irgendwie nur einen Fehler und das wars. Man kann zwar schon noch eigene Fehlerklassen aufbauen, aber das alles zu handeln und abzufragen ist ein bisschen Arbeit. Das fühlt sich in anderen Sprachen tatsächlich besser an.
Alexander Troppmann
Und was man doch auch immer vermisst, ist die Objektorientierung an sich. Das kann man sozusagen dadurch kompensieren, dass man anfängt funktionaler zu denken, aber es ist schon ungewohnt. Macht aber auch nichts, weil die Objektorientierung in vielen Projekten die Komplexität mit sich bringt, was manchmal an der Stelle gar nicht so sinnig ist. Zum Beispiel bei Java. Da denke ich jetzt an Dinge wie DTO’s, dass man sehr viele Mapper schreibt und Objekte hin und her transformiert. Da bekommt man in Go schon sehr viel mit und kann das schneller und effektiver machen.
Bei deinem Workshop-Titel hast du auf die Betonung „leichtgewichtige Microservices“ Wert gelegt – wieso?
Alex: Das Go-Konzept lautet „wenig Syntaktischer Zucker, sehr plain, relativ maschinennah, Verzicht auf komplexe Mechanismen und Strukturen wie man sie aus der Objektorientierung kennt“.
Wenn man sich darauf einlässt, dann bekommt man ein System, in dem man beispielsweise für eine REST-API schnell Dinge implementieren kann, die danach effektiv laufen, stabil sind und die man auch schnell ändern kann.
Wenn man sich auf das Go-Konzept einlässt, kann man effektive, stabile und leicht änderbare Dinge implementieren.
Alex
Ich glaube, dass wenn man mit Microservices arbeitet und das Konzept wirklich zu Ende denkt, dann kann man damit sehr schnell effektiv Software schreiben kann. Zu Ende denken heißt: Ich habe keine riesigen monolithische Services, sondern ich habe schlanke, einzelne Services, die im Kontext von anderen Microservices kleine einzelne Aufgaben erledigen. Das bedeutet auch, dass ich kleine Tools habe, die ich sehr schnell in einem Cluster unterbringen kann, sodass alles schön miteinander läuft. Die auch von anderen Entwicklern gut zu verstehen sind. Und ich glaube, dass das in vielen Projekten gegenüber so großen Frameworks wie zum Beispiel Spring Boot ein sehr großer Vorteil ist.
Ich sehe oft Projekte, in denen man mit einem zu großen Framework losschießt und am Ende eine riesige Komplexität hat und – ich sag jetzt mal provokant – trotzdem nur einen Microservice gebaut hat, der irgendwas ganz einfaches mit Usern macht. Das hätte man dann mit deutlich weniger Aufwand auch in Go implementieren können. Vor allem schneller, sicherer, testbarer und so weiter. Und deswegen glaube ich, ist Go ein sehr gutes Werkzeug im Baukasten eines Entwicklers, das man immer wieder ausgraben kann. Zu ganz verschiedenen Zwecken.
Schreibe einen Kommentar