APIs sind zwar nicht neu, aber sie bringen nun alle Einzelkomponenten moderner Anwendungen zusammen. Dadurch hat sich auch die Art und Weise der Software-Entwicklung verändert. Per APIs verbundene Microservices ermöglichen einen modulareren Aufbau von Apps. Viele kleine Komponenten sorgen gemeinsam für eine einheitliche User Experience. Dabei ist entscheidend, dass die einzelnen Microservices je nach Roadmap und User-Feedback in ihrem eigenen Tempo weiterentwickelt werden. Dieses Maß an Freiheit geht weit über die Möglichkeiten hinaus, mit denen Software-Entwickler bislang die Funktionalität ihrer Services erweitert haben. Mit APIs können sie sich die Entwicklungsumgebung aussuchen sowie die verwendeten Instrumente und Sprachen frei wählen. Jede Anwendung lässt sich mit vielen unterschiedlichen Sprachen erstellen. Das ermöglicht schnellen Zugriff auf jeweils genau die Werkzeuge, die für eine bestimmte Aufgabe optimal sind.
Systematisch eingesetzt
Die Entscheidung für das auf Microservices basierende Entwicklungsmodell bedeutet jedoch, dass vorab eine Anwendungsstrategie festzulegen ist. Diese verhindert, dass die Lösung bereits in der Anfangsphase der Entwicklung mit Funktionalität überfrachtet wird. APIs ermöglichen vor allem schnelle, inkrementelle Verbesserungen, weil man nach und nach die Bedürfnisse der User besser versteht. Doch mit der Zahl der verwendeten APIs steigt der Bedarf, sie systematisch einzusetzen. Manche Microservices sind Teil der Kernanwendung, aber immer mehr werden Cloud-basiert sein. Damit stellt sich die Vertrauensfrage und es muss sichergestellt werden, dass sich Updates nicht negativ auf die Gesamtstabilität auswirken. API-Gateways können eine wichtige Rolle hierbei spielen, wenn sie als Drehscheibe für Integration, Monitoring und Sicherheit dienen.
Transparenz und Vertrauen
Ein positiver Nebeneffekt von per ’shared by design‘ entwickelten Anwendungen ist, dass die Programmierer oft gewissenhafter auf die Auskommentierung ihres Codes achten. Allen ist jetzt klar, wie wichtig es ist, dass andere nachvollziehen können, wozu einzelne Code-Teile gedacht sind. Derart transparente und kooperative Ansätze sind in traditionellen monolithischen Entwicklungsumgebungen keineswegs an der Tagesordnung. Aus Entwicklerperspektive gibt es jedoch einige neue Herausforderungen sowie eine veränderte Herangehensweise. Hierzu gehört insbesondere das Vertrauen, dass andere APIs stabil sind sowie zuverlässige und schnelle Ergebnisse liefern. Dieses Vertrauen muss man aufbauen. So ist es vielfach bewährte Praxis, die Authentifizierungs- und Zugangskontrolle ins Gateway auszulagern, statt sie in jeder API hart zu codieren. Dadurch wird das Gesamtsystem besser skalierbar: Wenn sich etwas in der Authentifizierungslogik ändert, muss es nicht in allen APIs einzeln nachgebildet werden. Doch diese Vorteile gibt es nicht umsonst. Während ein Funktionsaufruf in einer monolithischen Anwendung normalerweise in puncto Geschwindigkeit und Sicherheit davon profitiert, dass sich alles im Speicher derselben Hardware abspielt, gehen API-Aufrufe an das Netzwerk – meist an entfernte Systeme. Das bedeutet, dass ein neuer Sicherheitsansatz nötig ist, der auch außerhalb eines geschlossenen Systems funktioniert. Außerdem muss das Gateway so schnell wie möglich sein. Selbst geringfügige Latenzprobleme auf Gateway-Ebene steigern sich exponentiell und beeinträchtigen die Performance der Anwendung.
www.f5.com