Eine der heute in den Hallen eines Infrastrukturanbieters am häufigsten gestellten Fragen ist, wie man der Entwickler-Community den Wert dieser Infrastruktur erklärt. Das Problem besteht darin, dass die meisten Vorteile der Infrastruktur erst nach der Inbetriebnahme zum Tragen kommen. Nichts davon bietet dem Entwickler einen direkten Mehrwert, zumindest nicht in einer sinnvollen Weise, die sich auf seinen Arbeitsalltag auswirkt.
Die zusätzlichen Entwicklungsvorteile sind den Entwicklern durchaus bewusst. In unserem „State of Application Delivery“ 2018 war ein kleiner Prozentsatz an Entwicklern vertreten. Dieser Prozentsatz sprach jedoch Bände über die Anwendungsdienste, die sie bereitstellen wollten. Einige dieser Anwendungsdienste – Lastausgleich, Caching und Beschleunigung – werden ebenso häufig als Teil der Anwendung selbst wie als Infrastruktur bereitgestellt. TCP-Optimierungen und WAF sind fast immer Infrastrukturdienste, die upstream (im Datenpfad) vor Anwendungen (egal ob Monolith oder Microservices) bereitgestellt werden.
Alle diese Anwendungsdienste sind wertvoll. Risikominderung, verbesserte Leistung, Skalierbarkeit. Dabei handelt es sich jedoch um Anwendungs- und Geschäftsvorteile; sie kommen den Entwicklern auch nach der Übergabe der Anwendung an die Produktion zugute. Es ist schwierig, die Vorteile einer Infrastruktur vor der Bereitstellung, also als Teil des Entwicklungslebenszyklus, zu erkennen – und erst recht zu artikulieren.
Doch je mehr wir auf Container und Mikroservices setzen, desto offensichtlicher wird der Wert der Infrastruktur vor und nach der Bereitstellung.
Wie bei den meisten neuen Technologien ist in der Anfangszeit einer neuen Anwendungsarchitektur nur eine sehr unzureichende Infrastruktur vorhanden. Für Entwickler mag es überraschend sein, dass die Anwendungsarchitektur die Infrastruktur der Anwendungsdienste maßgeblich prägt. Durch die Umstellung auf dreistufige, webbasierte Apps wurde die Skalierbarkeit (Lastausgleich) erhöht. Durch die Einführung von Web 2.0 mit seiner reaktionsfähigen Präsentationsschicht entstand eine Infrastruktur zur Front-End-Beschleunigung. Mit dem Aufkommen mobiler Endgeräte und der zunehmenden Digitalisierung aller Branchen reagierte die Infrastruktur mit Sicherheitsdiensten wie WAF, DDoS und Bot-Abwehr.
Was wir derzeit beobachten ist, dass Entwickler die Funktionen der Infrastrukturdienste in ihren Anwendungen kodifizieren. Entwickler fassen in Code zusammen, was traditionell in der Verantwortung der Upstream-Dienste lag. Wiederholungsversuche von Load Balancern. mTLS von den Plattformen oder Proxys. Zugriffskontrolle, um die Kommunikation auf legitime Clients zu beschränken.
Hierbei handelt es sich um Infrastrukturaufgaben, die aufgrund der frühen Natur von Container-Frameworks und der schnellen Akzeptanz von Entwicklern übernommen wurden.
Aber wie schon immer ändert sich auch das. So wie frühere App-Architekturen Reaktionen in der Netzwerkinfrastruktur vorangetrieben haben, tun dies nun Container und Microservices. Nur kommen die Änderungen dieses Mal nicht in Form einer neuen Box. Was jetzt passiert, ist der Schritt, die von Entwicklern benötigten Anwendungsdienste in die Containerumgebung zu integrieren. Hier kommt Service Mesh ins Spiel und bietet Entwicklern einen echten, messbaren Mehrwert.
Andrew Jenkins, leitender Architekt bei Aspen Mesh , erklärte in einem Interview mit Linux.com :
„Es ist bemerkenswert, wie einfach es heute ist, mit der Erstellung eines Webdienstes zu beginnen. Sie können den Code in einen Tweet einfügen. Dies ist jedoch kein echter Webdienst. Um es belastbar und skalierbar zu machen, müssen Sie der Datenebene der App einige Dinge hinzufügen. Sie muss TLS ausführen, Fehler wiederholen, nur Anfragen von diesem Dienst akzeptieren und nicht von jenem, die Authentifizierung des Benutzers überprüfen usw. Mithilfe eines Service Mesh können Sie diese Datenebenenfunktionalität erhalten, ohne der App Code hinzufügen zu müssen.“
Der Wert vor der Auslieferung liegt in der Reduzierung des Umfangs und der Beseitigung von sich wiederholendem, aber notwendigem Code, um die grundlegende Sicherheit und Skalierung innerhalb einer Containerumgebung zu handhaben. Ein Service Mesh verfügt über eine Vielzahl interessanter Funktionen, seine Vorteile sind jedoch größtenteils betrieblicher Natur – Beobachtbarkeit, Verantwortlichkeit, Skalierbarkeit. Der größte Mehrwert für einen Entwickler liegt in der Eliminierung von Code (und damit in der Reduzierung technischer und architektonischer Schulden).
Der Einsatz eines Service Mesh zum Skalieren, Sichern und Beobachten von in Containerumgebungen bereitgestellten Apps entlastet Sie vom Schreiben von Code, der eigentlich von der Infrastruktur übernommen werden sollte – bis vor Kurzem jedoch an Entwickler delegiert wurde. Ein Service Mesh ist eine Möglichkeit, Entwickler von ihrer Verantwortung zu entlasten und ihnen wertvolle Zeit zurückzugeben, die sie für die Entwicklung von Diensten und Apps nutzen könnten, die wiederum einen Mehrwert für das Unternehmen schaffen.