Suche
APIs are eating the World!

APIs – die Zukunft der Softwareentwicklung?!

Niko Köbler

„Software is eating the World“, so schrieb Marc Andreessen vor mittlerweile sieben Jahren – eine Erkenntnis, die treffender nicht hätte formuliert werden können. Doch obwohl dies auch allgemein heute noch gilt, steht uns eine neue Revolution ins Haus, wie Niko Köbler, Freelancer, Consultant und Co-Lead der JUG Darmstadt, in diesem Artikel darlegt: „APIs are eating the World!“

Fast jeder von uns kennt Marc Andreessens Artikel „Why Software is eating the world“ aus dem Jahr 2011. Dass Software unser Leben verändert und sich längst darin etabliert hat, sei es privat oder geschäftlich, streitet wohl kaum noch jemand ab. Doch die Zeit bleibt nicht stehen, sie entwickelt sich stetig weiter. Die Prozesse in unserem Leben werden nicht mehr nur durch in sich autarke Software-Umgebungen abgebildet. Moderne Systeme wollen – oder müssen sogar – heute miteinander reden, Daten austauschen und Dienste untereinander teilen. Ganze Geschäftsmodelle basieren heute, und vor allem morgen, darauf, sich über wohldefinierte Schnittstellen, auch (Application Programming) Interfaces (API) genannt, auszutauschen. Nachdem unsere Welt also von Software umgekrempelt worden ist, ist es an der Zeit, diese als Grundlage für eine weitere Veränderung zu verwenden und den APIs die nächste Revolution zu ermöglichen: APIs are eating the World!

Nehmen wir ein Unternehmen wie Uber als Beispiel. Das Kerngeschäft von Uber ist es, Menschen zusammen zu bringen, die einerseits von A nach B kommen wollen und andererseits Fahrer, die diese Dienstleistung erbringen können. Also sehr ähnlich dem Taxigewerbe, nur dass Uber keine eigenen Taxen besitzt und Fahrer nicht bei dem Unternehmen angestellt sind. So wie Uber hier also nur auf Dritte Personen zugreift, welche die Dienste anbieten und konsumieren, so arbeitet Uber auch hinsichtlich ihrer unternehmensinternen IT-Systeme.

Uber konzentriert sich darauf, das für sie Wichtigste selbst zu realisieren (Mobile App mit hohem UX-Faktor), setzt aber für alle anderen Prozesse auf externe Serviceanbieter und Dienste, die sie über ein API miteinander verbinden können. So werden etwa die Fahrer- und Fahrgast-Verwaltung oder Zahlungsdienstleistungen nicht von Uber selbst entwickelt oder betrieben, sondern nur die APIs der Serviceanbieter mit den Daten von Uber gespeist. Die Implementierung und das Management der eigentlichen Software obliegt Dritten. Uber kann so deutlich schneller auf Anforderungen und Änderungen des Marktes reagieren und spart dabei zusätzlich zur Zeit noch Kosten, kann aber wertvolle Marktanteile gewinnen.

APIs verändern also die Geschäftswelt, wie sie heute existiert. Dies hat auch auf uns Software-Entwickler, gerne auch „Techies“ genannt, ganz bestimmte Auswirkungen und Anforderungen. Zu aller Erst müssen wir, wenn wir im API-Business mitmischen und diese entwickeln, anbieten und/oder in unsere System integrieren wollen, das jeweilige Business, für das wir arbeiten, in einem hohen Detailgrad auch fachlich verstehen. Es reicht nicht mehr, nur noch der Experte für JPA oder JSF zu sein und zu wissen, welche Parameter man wie konfigurieren muss. APIs haben einen klaren fachlichen Bezug, und diesen müssen wir verstehen.

APIs: Nicht nur alter Wein in neuen Schläuchen

Die Technologien, die APIs mitbringen, sind oftmals nicht komplett neu. Viele Konzepte kennen wir bereits aus der Vergangenheit und haben schon damit gearbeitet. Nur die Spezifikationen ändern sich, wie wir diese Technologien anwenden können und sollen. So ist z.B. die Serialisierung von Daten, um diese zwischen zwei Systemen übertragen zu können, nichts Neues. Mit XML machen wir das seit Jahrzehnten, in den letzten Jahren kam JSON als Alternative auf und in Zukunft werden wir verstärkt auch mit weiteren Formaten wie etwa Afro (und anderen) zu tun haben. Dabei bleibt das Thema Serialisierung als solches bestehen, nur die Art und Weise, wie wir die Daten serialisieren, ändert sich. SOAP als API-Protokoll ist, in der IT-Zeitrechnung gedacht, schon uralt. Übertragung per HTTP auch, selbst REST ist als Prinzip nichts Neues. Und doch rückt es durch APIs viel mehr in den Mittelpunkt unseres Denkens. Ein Ausruhen auf diesen Protokollen ist aber nicht möglich, da sich auch die Welt weiterdreht und beispielsweise mit GraphQL eine neue Art eines Datenabfrageprotokolls vor der Tür steht, die sich auf die Lösung von ganz speziellen Anforderung konzentriert.

Auch im Bereich der Sicherheit gibt es neue Spezifikationen zu bereits bekannten Konzepten und Technologien. Die Authentifizierung und Autorisierung von Zugriffen auf und Abfragen von unterschiedlichen Systemen über APIs per Token ist nichts Neues. SAML als XML-basierter Standard wurde bereits in den frühen 2000er Jahren standardisiert. SAML ist mächtig, konzentriert sich aber eher auf die Lösung von unternehmensinternen Umgebungen. Für die Kommunikation über Netzgrenzen hinweg und zwischen heterogenen Systemen haben sich aus den geänderten Anforderungen Spezifikationen wie OAuth und OpenID Connect entwickelt, die aber auch noch Token-basiert arbeiten.

Lesen Sie auch: „GraphQL ist gut, aber keine Alternative zu echten REST-Services“

Es ist dennoch nicht nur „alter Wein in neuen Schläuchen“. Zusätzlich zu den neuen Spezifikationen von bekannten Konzepten, entwickeln sich auch neue Technologien, Programmiersprachen und gesamte Ökosysteme, die sich auf die Lösung von ganz bestimmten Anforderungen konzentrieren und dafür besonders geeignet sind (oder zumindest besser als mit den bisher bekannten Möglichkeiten). Wir dürfen uns also nicht auf dem, was wir bisher gemacht haben, ausruhen. Neue Technologien, und erscheinen sie zunächst auch als noch so klein und unwesentlich, entstehen heute schneller als je zuvor. Viele von diesen verschwinden ebenso schnell wieder wie sie gekommen sind, aber das ein oder andere Werkzeug bleibt. Und genau dieses Werkzeug kann die Lösung für eine unserer zukünftigen Herausforderungen sein. Das Werkzeug bereits zu kennen, kann uns den notwendigen Vorsprung in der Geschäftswelt sichern. Wir müssen keine Experten in jeder neuen Technologie sein, sobald sie erscheint. Aber wir sollten mit offenen Augen durch unsere Welt gehen und uns für viele neue Dinge interessieren, sie uns anschauen und uns nicht davor verschließen.

API Design & API Management

Um andere APIs zu konsumieren, müssen wir erst einmal einen Überblick über die verschiedenen Dienste auf vielen unterschiedlichen Leveln bekommen. APIs decken teils komplette Geschäftsvorgänge ab, teils aber auch nur einen technischen Aspekt. Nicht alle APIs arbeiten gleich und auf identischen Leveln. Wir müssen uns fragen, welche angebotenen APIs für unseren Anwendungsfall überhaupt relevant sind. Zusätzlich müssen wir lernen und verstehen, dass wir mit der Nutzung von fremden APIs einen Kompromiss und eine Abhängigkeit eingehen, die sich jetzt evtl. stärker auf unsere Geschäftsprozesse auswirken, als das bislang der Fall war. Einen Vorteil von einem API zu haben, kann bedeuten, dass wir uns mit anderen Nachteilen auseinandersetzen müssen. Möchten wir (öffentliche) APIs anbieten, müssen wir uns mit noch zwei weiteren, neuen Themen beschäftigen: dem API Design und API Management.

Beim API Design geht es hauptsächlich darum, ein einfach zu erlernendes und zu verwendendes API zu entwerfen, das von möglichst vielen Konsumenten genutzt werden wird. Neben der ganzen Einfachheit, muss dieses aber gleichzeitig auch schwer falsch zu verwenden sein. Dabei hat man ziemlich genau einen Versuch, denn sobald ein API öffentlich ist und es genutzt wird, kann es nur noch schwer geändert werden, da dies Auswirkungen auf die Konsumenten hat. Ein API muss erweiterbar sein und somit eine Kompatibilität über mehrere (alle?) Änderungszyklen gewährleisten. Und auch wenn am Ende Maschinen (Systeme) über ein API kommunizieren, so wird dieses zunächst von anderen Entwicklern „gelesen“. Themen wie Dokumentation und Namensfindung (für Objekte, Methoden, Attribute, etc.) rücken damit plötzlich in den Mittelpunkt. Keine einfache Aufgabe, an ihr hängt viel Verantwortung.

Lesen Sie auch: Die IT der zwei Geschwindigkeiten & API-Managementlösungen vs. Legacy-IT

Doch nicht nur für das Design des APIs am Anfang des Lebenszyklus tragen wir eine Verantwortung. Ein API muss über den gesamten Lebenszyklus und in vielerlei Hinsicht verwaltet werden. Hierbei geht es um Themen wie Sicherheit (Zugriffskontrolle, aber auch abgeschottete Test-Umgebungen/Sandboxen), Performance, Caching und nicht zuletzt SLAs, die wir als Anbieter unseren Konsumenten zusichern. Das, was bislang lediglich ein oder mehrere Aspekte unserer täglichen Arbeit war, rückt jetzt in den Fokus unserer Tätigkeit.

Als API-Entwickler stehen wir hinsichtlich der Qualität und der Benutzbarkeit der API und damit dem direkt verknüpften Geschäftserfolg des Unternehmens im Fokus der Verantwortung. Wir verwalten nicht mehr nur noch einen internen Prozess in einem kleinen Teil des Unternehmens, wir repräsentieren mit unserer API das Unternehmen nach außen.

Verwandte Themen:

Geschrieben von
Niko Köbler
Niko Köbler
Niko Köbler ist freiberuflicher Software-Architekt, Developer & Trainer für Java & JavaScript-(Enterprise-)Lösungen, Integrationen und Webdevelopment. Er ist Co-Lead der JUG Darmstadt, schreibt Artikel für Fachmagazine und ist regelmäßig als Sprecher auf internationalen Fachkonferenzen anzutreffen. Niko twittert @dasniko.
Kommentare

Hinterlasse einen Kommentar

2 Kommentare auf "APIs – die Zukunft der Softwareentwicklung?!"

avatar
400
  Subscribe  
Benachrichtige mich zu:
Thomas
Gast

Hi,

ist mit „Afro“ nicht eher Avro gemeint?

Jack
Gast

Bei dem verlinkten Text, muss man seine E-Mail hinterlegen, um den ganzen Text zu lesen. HIer das originale vom Autor: https://a16z.com/2016/08/20/why-software-is-eating-the-world/