Bei Begegnungen mit neuen Pentacornesen oder Kollegen aus anderen Unternehmen landen wir oft bei dem Thema, wie wir bei neuen Projekten eigentlich vorgehen. Wir vertreten dann gern unseren “bunten Strauß an Templates für die schnelle und sichere Lieferung neuer Applikationen”. Daraus entsteht häufig eine – mal mehr, mal weniger – hitzige Diskussion über die Sinnhaftigkeit solcher Templates.
Photo by Noupload on Pixabay
Um unseren Template-Ansatz zu verdeutlichen und euch einen Einblick in diese spannenden Diskurse zu geben, haben wir solch ein Gespräch hier konstruiert. In diesem Fall haben wir das Gespräch mit einem zufälligen Diskussionspartner – nennen wir ihn “John Doe” – auf einem imaginären Meetup geführt. So habt ihr die Möglichkeit, euch eure eigene Meinung zu diesem Thema zu bilden.
Photo by InspiredImages on Pixabay
John Doe: “ Hallo Penty, wir haben ein schönes neues Kundenprojekt gewonnen. Der Kunde braucht eine neue API-Fassade in seiner bestehenden Systemlandschaft. Leider will er schnell einen MVP (Minimum Viable Product) vollautomatisiert im DevOps-Ansatz auf seiner Laufzeitumgebung installiert bekommen. Dabei geht es ihm weniger um Funktionalität als darum, das Ganze schon mal in seiner Infrastruktur eingebettet zu sehen. Sprich: Die klassischen Fallstricke wie Netzwerkfirewall-Freischaltungen, Zugriffe und so weiter sind damit geklärt. Das heißt für uns mal wieder Überstunden, um das so kurzfristig hinzubekommen.“
Penty: „Hi John, das ist toll, dass ihr ein neues Kundenprojekt habt. Allerdings braucht ihr dafür doch keine Überstunden zu machen. Nutzt doch einfach Templates, dann seid ihr im Handumdrehen fertig.“
John Doe: „Hä, Templates? Wie meinst du das? Sowas haben wir nicht.“
Penty: „Also wir haben sehr viele Templates bei uns, die genau diese Problematik adressieren. Zum Beispiel haben wir ein Spring Boot Template, das vollautomatisiert in unserem Development Cluster installiert ist. Diese Template-Fassade deckt alle minimal notwendigen Features einer API-Fassade ab, wie zum Beispiel einen Standard-Controller, einen Standard-Adapter, Monitoring und Logging. Der Aspekt der Laufzeitumgebung ist ebenso als Template standardisiert. Dabei haben wir alle Laufzeitumgebungen integriert, die bisher für uns relevant waren, wie zum Beispiel Kubernetes, OpenShift oder PCF (Pivotal Cloud Foundry). Wenn wir neue Projekte mit neuen Laufzeitumgebungen angehen, dann nehmen wir diese Konfigurationen auch mit in unser Template auf.“
John Doe: „Hm, das klingt interessant. Heißt das, dass ihr ein neues Projekt immer mit dem gleichen Softwarestack zu lösen versucht?“
Penty: „Das kann man so pauschal nicht sagen. Natürlich möchten wir unserem Kunden Qualität und Stabilität garantieren. Deshalb setzen wir gern auf bewährte Praktiken, Technologien und Frameworks. Aber natürlich analysieren wir auch das zu lösende Problem. Und wenn ein anderes Werkzeug besser dazu passt, dann scheuen wir uns nicht, es zu verwenden. Und wenn es sich dann noch lohnt, aus dieser Problemlösung wieder eine Vorlage zu erstellen, dann generieren wir eben ein neues Template.“
John Doe: „Ok. Wie ist das genau? Fangen wir beim DevOps an: Problem API-Fassade. Was müsst ihr tun, um ein neues Projekt bei euch zum Laufen zu bringen? Der Entwickler geht zum Beispiel zu start.spring.io und klickt sich da was zusammen?
Penty: „Nein, natürlich nicht. Wir pflegen unsere Templates in unseren eigenen Repositories. Dort forkt man sich das benötigte Template und passt gegebenenfalls noch die Konfigurationen an, wie zum Beispiel Artefaktnamen oder Packages.“
John Doe: „Ah ja, und damit kann der Entwickler starten und hat anschließend im Prinzip eine lokal lauffähige Spring-Boot-Anwendung?“
Penty: „Ja genau, so funktioniert das.“
John Doe: „Verstanden. Nun will ich das Ganze auf Kubernetes bringen und zwar bitte nicht bei euch, sondern in der Laufzeitumgebung beim Kunden. Mal vorausgesetzt das Netzwerk ist frei und die Credentials sind da. Wie geht’s da weiter?“
Penty: „Dann nutzt du die Template-Konfiguration der Laufzeitumgebung. Dort sind die entsprechenden Parameter für die CI und CD schon gesetzt. Diese erweiterst du dann um die entsprechenden Konfigurationen der Integrations- und Produktionsumgebungen deines Kunden.“
John Doe: „Das klingt spannend. Seid ihr auch flexibel, was die Lage der Repositories angeht, die Art der Credentials und die Anzahl der Laufzeit-Umgebungen? Könntet ihr prinzipiell in eurer Umgebung Kubernetes nutzen und in der Zielumgebung OpenShift oder was anderes?“
Penty: „Diese Konfiguration ist bei uns sehr generisch gehalten. Deshalb ist uns die Art der Zielumgebung an dieser Stelle egal. Repositories und Credentials liegen in einer ausgelagerten Systemkonfiguration – das ist bei uns ein separates Git Repository. Die Laufzeitumgebungen werden bei uns über Profile gesteuert, das heißt, der Deployment-Prozess weiß anhand der Zielumgebung, welches Profil dieser zugewiesen ist und greift die passenden Konfigurationen ab.“
John Doe: „Verstehe ich das richtig, dass ihr auch einen standardisierten Deployment-Prozess habt? Wie macht ihr das und aus welchen Schritten besteht dieser?“
Penty: „Ja, wir haben einen standardisierten Deployment-Prozess. Dieser besteht im Allgemeinen aus: Checkout des Codes, Kompilieren, Unit- und Module-Tests, Package, System-Integrationstests / End-to-End-Tests, API-Smoke-Tests und Deployment auf die verschiedenen Zielumgebungen. Logischerweise bricht das Deployment sofort ab, sollte einer der Schritte fehlschlagen.“
John Doe: „Klasse. Das klingt alles zu gut für mich. Lauft ihr mit dem Ansatz aber nicht Gefahr, dass euer Softwarestack veraltet? Wie ist das, wenn ein Team was Neues ausprobieren will – Stichwort Innovation?“
Penty: „Die Gefahr besteht natürlich. Wir haben versucht, das Problem folgendermaßen anzugehen: Bei uns in der pentacor gibt es eine Gruppe von Interessierten, die sich regelmäßig treffen. Diese Gruppe prüft mögliche und notwendige Software-Updates.
Um das Stichwort Innovation aufzugreifen: Die Templates-Gruppe lässt Anregungen von anderen Gruppen in der pentacor mit einfließen, die eventuell Erweiterungen, Neuerungen oder Trends betrachten. Diese anderen Gruppen sind thematisch organisiert. Wir haben zum Beispiel eine DevOps-Gruppe oder eine Architektur-Gruppe, um nur zwei von vielen zu nennen.“
John Doe: „Ok, ich verstehe, aber wie dokumentiert ihr, was ihr da tut?“
Penty: „Zum einen verwenden wir ein Tickettracking-Tool, um unsere Aufgaben und Reviews zu strukturieren und zu pflegen. Zum anderen haben wir eine umfangreiche Dokumentation in unserem Firmen-Wiki, um die Architektur und die Verwendung zu beschreiben. Zum Beispiel haben wir in unserem Onboarding ein Hands-On dokumentiert, das beschreibt, wie man den Template-Service verwenden und auch erweitern kann. Jeder neue Pentacornese durchläuft beim Onboarding diesen Abschnitt mit.“
John Doe: „Onboarding klingt erstmal ganz gut, aber danach ist es doch vergessen! Wie fördert ihr die Kommunikation in eurer täglichen Arbeit? Und wie erfahren die anderen Teams davon, wenn ihr etwas Neues evaluiert habt?“
Penty: „Es gibt bei uns jede Woche einen Regeltermin, zu dem unsere Projektteams zusammenkommen. Dort unterhalten wir uns unter anderem über neue Template-Ansätze, Ergebnisse oder ähnliches. Des Weiteren kommunizieren wir auch Änderungen in unserem dedizierten Chat Channel oder per E-Mail. Und wenn wir ein Thema gern fokussiert mit verschiedenen Leuten und unterschiedlichen Skills diskutieren wollen, dann halten wir eine Besprechung zu diesem Thema ab. Gegebenenfalls fallen dabei wieder Aufgaben für die Template-Gruppe ab.“
John Doe: „Oje, das klingt alles nach ziemlich viel Arbeit: Templates anlegen, pflegen, Regelmeetings, zusätzliche Meetings, Trends verfolgen und so weiter. Da hat man doch gar keine Zeit mehr für Projektarbeit.“
Penty: „Natürlich muss man in solche Aufgaben investieren – zeitlich sowie finanziell. Wir haben aber erkannt, dass wir dadurch vor allem im Projektgeschäft viel schneller agieren können und uns auch viel detaillierter auskennen. Daher ist dieser Invest auch schnell wieder ausgeglichen.“
John Doe: „Ich muss sagen, eigentlich klingt das gar nicht so uninteressant. Ich würde mir den ein oder anderen Aspekt mal mitnehmen und mit meinen Kollegen bewerten. Vielen Dank für den Einblick in eure Vorgehensweise.“
Penty: „Sehr gern. Kontaktiert uns einfach, wenn ihr noch mehr wissen möchtet.“
So oder so ähnlich könnte tatsächlich eine Diskussion stattgefunden haben. Auch intern haben wir solche Gespräche durchaus schon geführt. Natürlich ist uns bewusst, dass so ein Template-Ansatz kein Allheilmittel ist. Jedes Projekt bei uns muss verschiedene Kriterien beleuchten, wie zum Beispiel:
-
Ist es das richtige Werkzeug für das Problem?
-
Gibt es dedizierte Anforderungen vom Kunden, die dagegen sprechen?
-
Haben wir genügend Zeit und Kapazität, um etwas Neues auszuprobieren?
Anhand solcher Fragen muss ganz klar bewertet werden, ob ein Template hier passt oder nicht. Am Ende darf jedes Projektteam selbst entscheiden, mit welchem Softwarestack es arbeiten möchte – ganz nach dem Motto: “Tailor your Template.”
Wir sind auch immer daran interessiert, wie andere Unternehmen mit diesem Thema umgehen. Vielleicht seid ihr unsere nächsten Gesprächspartner? Wir freuen uns schon darauf!