Rainer, war ein API früher noch eher die Seltenheit, ist es heute ein integraler Bestandteil eines Produkts. Was hat sich in den letzten Jahren geändert?

Rainer Stropek: Cloud und SaaS sind im Markt mittlerweile so richtig angekommen. Firmen haben erkannt, dass SaaS-Lösungen in vielen Bereichen wesentlich kostengünstiger und effizienter sein können als lokal installierte Programme. Natürlich hat man keine Lust auf Informationssilos ohne Datenaustausch. Man will die gewählten SaaS-Produkte so verbinden, dass die jeweiligen Geschäftsprozesse produktübergreifend automatisiert laufen. Dafür braucht es Integrationsmöglichkeiten. Ein SaaS-Anbieter, der diese Kundenanforderung nicht versteht, ist zum Scheitern verurteilt. Aus diesem Grund spielen Web APIs für Softwareprodukte heute eine so große Rolle. Für Kunden sind sie zu einem wichtigen Entscheidungskriterium geworden und Hersteller reagieren darauf.

Warum sollte man deiner Meinung nach überhaupt Wert darauf legen, ein API anzubieten? Wo liegen die Mehrwerte für das eigene Produkt?

Rainer Stropek: In der Vergangenheit haben viele Hersteller darauf gesetzt, sich durch fehlende APIs und proprietäre Datenformate abzuschotten. Man wollte gezielt einen Lock-in-Effekt erzeugen und Kunden monolithische Lösungen aus einer Hand verkaufen. Diese Strategie ist heute nicht mehr haltbar. Kunden akzeptieren eine solche Vorgehensweise heute nicht mehr. Ich bin davon überzeugt, dass man durch Offenheit die Loyalität der Kunden wirksamer fördern kann als durch Einsperren. APIs geben dem Kunden die Freiheit, andere Produkte anzubinden oder sogar einfach auf ein neues Produkt umzusteigen. Diese Flexibilität wird geschätzt und erzeugt Vertrauen.

Der zweite Vorteil von APIs ist die Möglichkeit, das eigene Produkt vom starren Monolithen zu einem Zusammenspiel kleiner, flexibler Bausteine weiterzuentwickeln. Dieser Ansatz ist unter dem Schlagwort Microservices bekannt. In vielen Projekten wurde mittlerweile gezeigt, dass Microservices die Softwareentwicklung in größeren Organisationen auf ein ganz neues Effizienzniveau heben können.

Vor welche besonderen Aufgaben stellt die Entwicklung eines API an Entwickler?

Rainer Stropek: HTTP, JSON & Co kennt jede Entwicklerin und jeder Entwickler. Wer allerdings meint, dass das genug ist, um eine professionelle RESTful Web API auf die Beine zu stellen, der wird sein blaues Wunder erleben. Web APIs richtig zu designen, Versionen zu verwalten, ausfallsicher zu betreiben etc. ist nicht einfach. Wenn in einer größeren Organisation viele APIs entsprechend dem Microservices-Konzept zusammenspielen sollen, kommt DevOps und Automatisierung dazu. Startet man in diese neue Welt, kann man eine Menge falsch machen. Produktmanager, Entwicklerinnen und Entwickler müssen die notwendigen Technologien und Techniken dafür erlernen und schrittweise verbessern.

Seit einiger Zeit ist das Thema „serverless“ in aller Munde. Welche Vorteile bietet ein PaaS-Angebot für API-Anbieter?

Rainer Stropek: Mein Lieblingsthema! Meine aktuelle Firma ist „born in the Cloud“. Wir haben vom ersten Tag an zu 100% auf PaaS in der Azure-Cloud gesetzt und mittlerweile jahrelange Erfahrung damit. Rückblickend muss ich sagen, dass das genau die richtige Entscheidung war. Unser Team ist klein, gerade mal fünf DevOps-Technikerinnen und -Techniker. Unsere Infrastruktur ist aber alles andere als simpel. Wir betreiben fast 200 DB-Cluster, dutzende Web-Farmen, eine Menge Storage-Cluster und vieles mehr. Vollzeitadministratoren? Haben wir keine. Das wäre in einem eigenen Rechenzentrum undenkbar. Selbst mit IaaS würde uns der Aufwand der Infrastrukturautomatisierung überfordern. Nur durch richtige Auswahl, Kombination und Verwendung von PaaS-Angeboten kann man als kleines Team SaaS in größerem Stil bewältigen.

Gibt es auch Grenzen, die man beachten sollte?

Rainer Stropek: PaaS bedeutet weniger Verantwortung aber auch weniger Kontrolle. Wenn eine gewisse Funktion vom jeweiligen PaaS-Dienst nicht geboten ist, kann man sich nicht mal schnell zum Server verbinden und etwas nachinstallieren. Das bedeutet in der Praxis manchmal Einschränkungen, die man in Kauf nehmen muss. Für uns ist PaaS so wichtig, dass wir unsere Produktplanung bis zu einem gewissen Grad an den Möglichkeiten und Grenzen der gewählten PaaS-Dienste ausrichten. Dadurch können wir die Skaleneffekte von PaaS optimal nutzen und den erzielten Effizienzgewinn durch niedrige Kosten an unsere Kunden weitergeben.

Ist das API einmal veröffentlicht, ist die Arbeit nicht abgeschlossen. Es geht um die Präsentation bzw. den „Verkauf“ der Schnittstelle als Produkt. Gibt es hierfür Best Practices, oder befindet sich der Markt in einer Art Findungsphase?

Rainer Stropek: Meiner Ansicht nach sollten eine API Teil des Produkts sein. Ich bin kein Freund komplizierter Preismodelle, bei denen man für jede Kleinigkeit extra bezahlen muss. Verlangt man für eine API Geld, werden Kunden zögern, sie einzusetzen. Ich finde, jede API sollte ohne Zusatzkosten angeboten werden.

Ich halte es allerdings für sinnvoll, Nutzungsgrenzen vorzusehen. Wenn ein Kunde eine API sehr intensiv nutzen will, dann kann man dafür durchaus zusätzliches Geld verlangen. Es gibt PaaS Dienste wie zum Beispiel Azure API Management, die ein solches Throttling ermöglichen, ohne dass man dafür ein großes Entwicklungsprojekt starten muss.

Mal ein konkretes Beispiel angeführt: Wie geht man damit um, wenn man Breaking Changes ausliefern muss? Man kann manchmal schließlich ältere Versionen nicht einfach weiter laufen lassen

Rainer Stropek: Warum nicht? Genau das ist doch der Charme der Cloud. Ob wir ein paar Versionen mehr oder weniger betreiben, bedeutet für uns kaum einen Mehraufwand. Die führenden Cloud-Dienste bieten uns alle Preismodelle, die Pooling ermöglichen. Wir kaufen also Ressourcenpools und können darin nahezu beliebig viele Varianten unserer Software betreiben. Die Grenzkosten für eine weitere Version sind sehr niedrig. Man kann mit PaaS in der Cloud großzügiger mit dem Betrieb alter API-Versionen umgehen.

Trotzdem bleiben Breaking Changes und Versionsumstellungen nicht aus. Ich lege dabei in Kundenprojekten immer großen Wert auf klare Kommunikation. Kunden müssen wissen, wie lange sie sich auf welche API-Version verlassen können. Durch Telemetriedaten kann man prüfen, welche Kunden die alten API-Versionen noch verwenden und auf sie zugehen, wenn der Tag der Abschaltung näher rückt. Das ist Kundenservice, wie es im Jahr 2016 laufen sollte.

Abgesehen von den naheliegenden Aufgaben … was sind spannende APIs, die du hervorheben und als Positivbeispiel für eine gelungene Umsetzung anführen würdest?

Rainer Stropek: Zwei Beispiele, die ich immer wieder bei Workshops zeige, sind die APIs von Slack und die APIs, die Microsoft für Azure und Office 365 anbietet.