Event-driven Microservices mit Go und NATS

Meetup-Interview: Event-driven Microservices mit Go und NATS

Avatar von Mayflower

Ende Juni hat unser Alexander in einem Meetup eine kleine Einführung in Microservices mit Go gegeben. Das Thema kam so gut an, dass er sich ziemlich schnell eine Fortsetzung vorgenommen hatte. Und so kommt es, dass er euch am 25. August eine Einführung in Event-driven Microservices mit Go und NATS gibt.

Was euch darin erwartet, erzählt er euch in seinem aktuellen Interview. 

Infos und Anmeldung zum Meetup

Erzähl ein bisschen was über NATS – für welche Einsatzzwecke eignet sich das Messaging System? 

Alexander: NATS ist ein Messaging Bus für unter anderem eventgetriebene Microservices-Architekturen. Im Prinzip ist es also etwas ähnliches wie Kafka. Es hat aber bei Weitem nicht die Komplexität, die Kafka mitbringt. Es hat eine sehr hohe Performance, ist in Go implementiert und fügt sich daher auch sehr schön in schon bestehende Go-Infrastrukturen oder Go-Applikationen ein.  

Das Nette ist, dass es alles mitbringt was man braucht. Nicht zu viel, nicht zu wenig. Es ist sehr flexibel und schnell zu erlernen. Deswegen ist es gut für kleine bis mittelgroße Projekte geeignet –  wesentlich besser als Kafka. Da muss man erstmal das Setup und den Betrieb verstehen, bevor man es in der Praxis gut einsetzen kann. 

Vor ein paar Monaten gab es ein größeres Feature-Release auf die Version 2.0. Was gab es Neues?

Alexander: Ich habe nur die Version 2.0 benutzt, daher habe ich keinen Vergleich.

Alexander Troppmann

Alexander Troppmann

Allerdings weiß ich, dass die Sicherheitskonzepte erweitert wurden; man kann jetzt besser Zugriffsrechte auf den Bus vergeben. Wir verwenden es zwar aktuell nicht im Projekt, weil bei uns der NATS-Bus nur intern dafür verwendet wird, dass die Microservices untereinander kommunizieren können – aber die Möglichkeit gäbe es. Das wird dann interessanter, wenn man den NATS-Bus an KrakenD (ein in Go implementiertes API-Gateway) nach außen hin öffnet. Zum Beispiel kann man NATS an KrakenD anschließen, um dann auch von extern Nachrichten empfangen zu können. In diesem Kontext ergibt eine Authentifizierung selbstverständlich Sinn.

Außerdem wurden in NATS 2.x das Monitoring und Sammeln von System-Metriken verbessert. Insgesamt fühlt sich NATS damit wieder ein Stück „erwachsener“ an.

NATS lässt sich mit vielen Sprachen ansprechen. Was macht den Einsatz von Go(lang) für Dich so attraktiv? 

Alexander: Go finde ich im Moment sowieso sehr attraktiv. Was ich besonders nett fand ist, dass es auch eine sehr gute Protobuf-Integration (Protocol Buffers) für Go gibt.

Das ist eine IDL-Sprache von Google, mit der man unter anderem Nachrichten beschreiben kann, die in einem verteilten System über den Event Bus ausgetauscht werden. Das Besondere bei Google Protobuf ist, dass es ein Binärformat ist, das Mechanismen eingebaut hat, die so ein Eventschema wachsen lassen können. Man kann zum Beispiel sagen „Ich entferne ein Feld“, es bleibt aber in der Spezifikation reserved, damit man bis zu einem gewissen Grad abwärtskompatibel bleibt. Man kann auch neue Felder (im Protobuf-Kontext spricht man auch von „Messages“) dazu nehmen. Und es gibt einen Compiler, der diese Google Protobuf-Spezifikation in verschiedene andere Programmiersprachen übersetzt.

Das fühlt sich in Go wiederum ganz gut an. Vor allem was dort vom Compiler rauskommt, sodass man gefühlt eine sehr enge Integration zwischen Go, Google Protobuf und NATS hat.

Was ich auf den NATS Bus gebe ist aber tatsächlich egal. Also ich kann einfach irgendeinen String, ein binäres Google Protobuf-Paket, aber auch natürlich JSON reingeben. Aber die Kombination dieser drei – Go, Google Protobuf und NATS – fand ich sehr gut.  

Du hast in Deinem letzten Interview davon gesprochen, wie wichtig schlanke Services für eine schnelle und effektive Softwareentwicklung sein können. Schnell und effektiv, widerspricht sich das nicht ein wenig? Welche Halbwertzeit hat so ein schneller und schlanker Service?

Alexander: Dazu sollte man erst sagen was ich unter effektiv verstehe. Unter der Effektivität und Effizienz eines Softwareprogramms, in unserem speziellen Fall jetzt eben einem Microservice, verstehe ich, dass es genau das tut was es soll. Nicht mehr und nicht weniger. Dass es aber trotzdem sehr flexibel ist. Dass es eine hohe Performanz hat – sprich, dass es später im Cluster auch skalierbar ist. Dass ich einen sehr geringen Speicherverbrauch habe und dass ich Dinge später auch leicht anpassen und ändern kann. Das betrifft auch den Startup eines neuen Containers, der beispielsweise bei Spring Boot oftmals enorm viel Zeit benötigt – was einer Skalierung evtl. im Weg stehen kann.

NATS bringt alles mit, was man braucht. Nicht zu viel und nicht zu wenig.

Alexander Troppmann

All das was ich jetzt aufgezählt habe, trifft meiner Meinung nach auf diese Microservices, die man in Go implementieren kann, sehr gut und speziell auch auf NATS zu.

Ich habe während der Arbeit mit NATS gemerkt, dass es sehr stark auf den Punkt gebracht ist. Man trifft diesen Software-Stil oft im Go-Ökosystem an. Da sind viele Leute unterwegs, die eine gewisse Philosophie in der Softwareentwicklung verfolgen und das spürt man bei NATS genauso, wie man es auch bei Go spürt. Man vermisst nichts. Man kann alles tun, was man tun möchte, obwohl man gar nicht so viele Parameter hat. Das führt auch dazu, dass man das System sehr schnell verstehen und dann auch sehr schnell einsetzen kann. Und wenn man es ausbauen möchte, muss man nur an wenigen Schrauben drehen und ist dann schon einen riesigen Schritt weiter als vorher.

Schnell und effektiv widerspricht sich daher überhaupt nicht. Effizienz heißt: Ich kann dieses Stück Software schneller entwickeln/ausbauen/verändern und es performt trotzdem nach wie vor technisch sehr gut, weil ich eben Technologien gewählt habe, mit denen man gut arbeiten kann.

Und deswegen bin ich sowohl schnell in der Entwicklung, als auch schnell was die Ausführung des fertigen Programms später angeht. Es ist daher kein Widerspruch, im Gegenteil, es ist eigentlich eins, zumindest empfinde ich das so im Go-Ökosystem.  

Was dürfen die TeilnehmerInnen in Deinem zweiten Workshop erwarten? 

Alexander: Wie schon im ersten Workshop auch, versuche ich einen praxisnahen Einblick zu geben, wie man im eigenen Softwareprojekt NATS verwenden kann.

Das heißt, nach dem Workshop wird jeder ein sehr gutes Grundgefühl dafür haben, um sich folgende Fragen zu beantworten: Kann ich das verwenden oder nicht, wie schwer ist es, wie komplex ist es, wie schnell ist es zu lernen, wie einfach oder wie schwierig ist es einzusetzen und was muss ich tun, um mit NATS konkret zu arbeiten?

Nach dem Meetup werdet ihr ein gutes Gefühl dafür haben, was alles mit Microservices in Go und NATS möglich ist.

Alexander Troppmann

Man wird auch wissen, was man benötigt, um ein Event zu produzieren – also wie programmiere ich einen Producer, was brauche ich alles um so ein Event zu konsumieren und was muss ich tun, um das Ganze dann auch in meiner Infrastruktur zu deployen? Und natürlich auch, wie der Softwareentwicklungs-Prozess an sich aussieht, wenn man damit arbeitet.

Also wieder ein allumfassender Gesamtüberblick, wie im ersten Workshop. Sodass man einen guten Ausgangspunkt hat, um NATS auch in eigenen Projekten einzusetzen. 

Da ich neulich gehört habe, dass Go schon 10 Jahre alt und schon gesetzt sei, möchte ich noch sagen, dass meiner Meinung nach jetzt ein guter Zeitpunkt ist, um sich mit Go zu beschäftigen.

In der Vergangenheit hatte ich wenig Projekte mit Go gesehen, inzwischen ist Go aber trendy geworden. Gemessen an GitHub-Metriken gehört Go in 2020 zu den Top-10 am schnellsten wachsenden Programmiersprachen. Immer noch exotisch im Vergleich zu Java, PHP, JS, Python, Ruby und anderen – aber mit viel Potential.

Als Entwickler hilft mir Go in Projekten und in der täglichen Arbeit. Auch das versuche ich in meinem Workshops zu zeigen.

Infos und Anmeldung zum Meetup

Avatar von Mayflower

Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert


Für das Handling unseres Newsletters nutzen wir den Dienst HubSpot. Mehr Informationen, insbesondere auch zu Deinem Widerrufsrecht, kannst Du jederzeit unserer Datenschutzerklärung entnehmen.