Get in touch
In dieser dreiteiligen Blogartikel-Serie wollen wir Dir Flamingo, das auf Go-basierende, modulare Open Source-Framework von AOE, schrittweise näherbringen. Falls Du den ersten Teil über die Programmiersprache Go oder den zweiten Teil über Development Frameworks verpasst haben solltest, kannst Du beide Blog-Beiträge jederzeit hier noch einmal nachlesen. Im heutigen dritten und letzten Teil dreht sich alles rund um Flamingo, AOEs schnelles Application Framework mit Plug-in-Funktionalität.
Sei gespannt auf Teil 3: Einführung in Flamingo
In realen Technologieumgebungen gibt es selten das eine generische Tool oder die eine Standard-Lösung, die wie die Faust aufs Auge passen. Die Eignung hängt von den fallspezifischen Anforderungen, Einschränkungen, dem weiteren Umfeld sowie dem Kontext ab. Dies gilt natürlich auch für Golang-Frameworks. Um zu prüfen, ob ein spezielles Framework sinnvoll ist, muss vor der Einführung hinterfragt werden, für welche Art der Prozessoptimierung das Framework entwickelt wurde und, wie bereits in Teil eins und zwei ausführlicher beschrieben, für welche Art von Benutzer:in.
Flamingo ist ein Golang-Framework für die Full-Stack-Webentwicklung innerhalb von Unternehmen, welches auf den nachfolgenden business-relevanten Prioritäten basiert:
In einem Unternehmen ist es eher selten, dass eine Anwendung vollkommen isoliert läuft. Die meisten verhalten sich eher wie Knoten innerhalb eines riesigen Netzwerks und interagieren ständig mit verschiedenen Datenspeichern sowie externen Diensten. In jedem Fall muss die Anwendung am Ende des Tages ihre erzeugten Daten irgendwo speichern, und dieser Ort ist im Allgemeinen eine gemeinsam genutzte Datenbank, betreut von einer esoterischen Crew aus Datenbank-Jünger:innen.
Eine Unternehmensdatenlandschaft besteht jedoch aus mehr als nur aus ein paar Datenbanken, die sich im stillen Kämmerlein austauschen. In der Regel handelt es sich eher um eine rauschende Datenparty mit Gästen, die von den neuen Kids im Viertel (hallo, Vektordatenbanken) über Zeitreihen, Suchfunktionen, viele verschiedene SQL-Varianten und NoSQL bis hin zur alten Garde reichen (die standhaften IBM-Mainframes der Z-Serie, die sich weigern, die Party zu verlassen, obwohl es für sie schon lange Zeit ist).
Darüber hinaus muss eine durchschnittliche Anwendung eine Vielzahl von Aufgaben jonglieren: Datenhäppchen verdauen, Notizen an andere Anwendungen weitergeben, ein Feuerwerk an Warnmeldungen auslösen und Protokolle erstellen, als gäbe es kein Morgen. Jede Aufgabe zwingt Entwickler:innen dazu, herauszufinden, wo sie im Labyrinth der Codes neue Funktionalitäten unterbringen sollen und wie sie diese mit allem anderen in Einklang bringen können.
Jede dieser Entscheidungen trägt dann zu einem wachsenden Wirrwarr von verschiedenen, oft unzusammenhängenden Meinungen von Entwickler:innen bei. Diese Meinungen fließen dann in jeden Winkel der Anwendung ein, von der glänzenden Benutzeroberfläche bis hin zu einem verstaubten Hintergrundskript. Und dabei spielt es keine Rolle, wie viel REST, GRPC oder SOAP eingesetzt wird; eine API ist nur eine weitere Abhängigkeit, die in die Anwendung einfließt. Innerhalb des Unternehmens können all diese stillschweigend eingebetteten Meinungen schnell unüberschaubar werden. Der Versuch, von einer mittlerweile uncoolen Technologie wegzukommen, wird so zu einer Herkulesaufgabe, bei der die Entwickler:innen in der Codebasis Verstecken spielen und jeden heimlichen Verweis auf die veraltete Technologie aufspüren.
Hier kommt das Flamingo-Framework ins Spiel, der charmante Diplomat der Unternehmens-IT-Welt, der die komplexe Geopolitik der Anwendungsarchitektur dank seiner Geheimwaffe geschickt navigiert: der hexagonalen Architektur oder, wie die Tech-Kenner es nennen, den Ports und Adaptern. Stell Dir die Kerngeschäftslogik Deiner Anwendung als den kühlen und konzentrierten Botschafter vor, der im Herzen einer geschäftigen Botschaft stationiert ist. Um unseren Botschafter herum befinden sich die verschiedenen Abteilungen und Attachés – die Ports und Adapter. Das sind die Spezialist:innen mit ihrem/seinem Fachwissen im Umgang mit der Außenwelt, sei es bei der Verbindung mit Datenbanknationen, beim Versenden von Sendungen über Webdienste oder beim Aushandeln von Verträgen mit APIs. Sie sind die unverzichtbaren Vermittler:innen, die die Anforderungen und Antworten zwischen dem Kern und der Außenwelt interpretieren und übersetzen.
Mit der Finesse eines erfahrenen Diplomaten sorgt Flamingo dafür, dass der Botschafter (die Geschäftslogik) von den Komplexitäten der externen Kommunikation nicht abgelenkt wird. Musst Du Deine diplomatische Herangehensweise an eine Datenquelle ändern oder Dein Kommunikationsprotokoll umstellen? Kein Problem! Das ist die Aufgabe der Adapter, die das diplomatische Personal austauschen, um es besser an die sich verändernde internationale Landschaft anzupassen. Diese Flexibilität ermöglicht reibungslose Übergänge und Anpassungsfähigkeit wie ein diplomatisches Korps, das sich auf neue politische Gegebenheiten einstellt.
Und um die Analogie zur Diplomatie noch ein wenig weiter zu spinnen, kann Flamingo auch für das interne Entwicklungsteam als solches fungieren. Durch die Bereitstellung eines strukturierten Ansatzes zur Organisation von Code und Abhängigkeiten nimmt Flamingo dem Team einen Großteil der Entscheidungsfindung und der erforderlichen Absprachen ab und ersetzt sie durch die bewährten Meinungen von Flamingo. Und wie jeder, der schon einmal zwischen Entwickler:innen in Fragen wie Logging-Frameworks, Formatierung oder Test-Frameworks vermitteln musste, bestätigen kann, kann dies viel Zeit sparen.
Flamingo ist so konzipiert, dass es sich gut in moderne Produktionsumgebungen einfügt. Es ist außerdem ein Framework, bei dem die Batterien bereits enthalten sind. Das bedeutet, dass Anwendungen, die mit Flamingo entwickelt werden, sofort einsatzbereit sind. Für das Deployment selbst erstellt Go einzelne Binäranwendungen, die sich perfekt für die Containerisierung eignen. So können moderne Infrastrukturteams, die DevOps- oder Platform-Engineering-Ansätze verwenden, Flamingo-basierte Anwendungen einfach mit Docker, EKS oder Tools wie Fargate bereitstellen.
In der Produktion haben Flamingo-Anwendungen in der Regel einen geringeren Ressourcenbedarf. Da es sich bei Flamingo um eine Golang-Binärdatei und nicht um eine interpretierte Sprache handelt, benötigen Flamingo-Anwendungen weniger Ressourcen als ein Python- oder Java-Pendant. Darüber hinaus sind sie auch eher in der Lage, moderne Multi-Core-Systeme zu nutzen , wodurch die neuesten Cloud-Ressourcen kostengünstiger eingesetzt werden können. Und um die Überwachung zu vereinfachen, ist in Flamingo OpenTelemetry integriert. Dies ermöglicht es Anwendungsentwickler:innen schnell und einfach Anwendungstelemetrie hinzuzufügen. Und für Plattform-Ingenieure oder Betriebsteams vereinfacht dies auch die Überwachung und Nachverfolgung, was bedeutet, dass Systemprotokolle und Metriken leicht zu finden und konsistent über alle Flamingo-Apps hinweg implementiert sind. Ebenso sind die Geschäftsmetriken für Analysen intuitiver und konsistent.
Flamingo stützt sich auf die inhärente syntaktische Einfachheit und die Benefits, die Golang selbst mitbringt. Dies bringt zwei große Vorteile mit sich: Erstens ist die Lernkurve für Entwickler:innen, die aus Sprachen wie PHP oder Ruby kommen, gleichermaßen schnell wie auch sanft. Der zweite, damit zusammenhängende Vorteil ist, dass in einem Unternehmen, in dem diese Sprachen vielleicht schon seit Jahrzehnten verwendet werden, bestehende interne Entwickler:innen einfach in ein mit Flamingo geschriebenes Projekt eingebunden werden können. Oft wissen diese langjährigen internen Entwickler:innen am besten, wie die Business-Logik in einer bestimmten Anwendung kodiert wird und warum. Dies ist genau die Art von Stammeslogik, die leicht verloren geht, wenn etablierte Entwickler:innen sich durch neue Anforderungen verdrängt fühlen, eine stumpfsinnige neue Sprache zu erlernen, die gerade erst in Mode gekommen ist.
Darüber hinaus verbindet die Designphilosophie von Flamingo eine starke, benutzerfreundliche Sprache mit einer Vorliebe für Konventionen und Konfiguration gegenüber direkter Codierung. Viele dieser Funktionen können mit einem Schnipsel YAML oder CUE implementiert werden, was das traditionelle Dogma, dass die reine Codierung an der Spitze der Softwareentwicklung steht, in Frage stellt. Flamingo nimmt hier eine pragmatischere Haltung ein. Es vertritt die Idee, dass Code, der direkt auf Business-Probleme abzielt, im Vordergrund steht; alles andere ist zwar notwendig, aber zweitrangig und wird besser durch Konventionen, Konfiguration oder innerhalb des Ports und Adapter-Modells verwaltet.
Flamingo stützt sich auf die Architektur von Ports und Adaptern, kombiniert mit der Leistungsfähigkeit von Go, und macht es so einfach, "taktische" Lösungen zu erstellen. Es gibt Benutzer:innen, die, wenn sie Flamingo an einem Freitag kennengelernt haben, am Montag produktiv waren und funktionierende Microservices geschrieben haben, nachdem sie ein Wochenende damit verbracht hatten, sich mit der Software vertraut zu machen. Die Förderung der modularen Wiederverwendung und die Aufrechterhaltung eines sauberen und angemessen abstrahierten Codes begünstigen die schnelle Iteration, den heiligen Gral eines jeden Technologieanbieters.
Flamingo bringt zahlreiche Vorteile, die nicht von der Hand zu weisen sind, mit sich. Dennoch geht es uns in diesem Blog nicht darum, zu behaupten, dass Flamingo die beste Lösung auch für Dich und Dein Unternehmen ist. Vielmehr möchten wir Dir aufzeigen, an welcher Stelle und warum dies unter Umständen der Fall sein könnte.
Bist Du neugierig geworden? Du möchtest noch mehr Informationen über Flamingo und unser Framework einmal testen? Wende Dich gerne über diesen Link an unser AOE-Entwicklungsteam.
