Kunden zögern beim Thema Serverless
Unreif
Serverless Computing ist der neue große Infrastrukturtrend. Unternehmen versprechen sich vor allem weniger Aufwand für ihre IT. Große Player wie Amazon, Google oder IBM wollen als Anbieter mitmischen. Doch ist der Markt schon reif dafür?
Sich als Entwickler nicht mehr mit dem Betrieb von IT-Infrastrukturen auseinandersetzen zu müssen, hat etwas Verlockendes: Serverless! Tatsächlich sind nach wie vor Server im Einsatz – allerdings aufseiten der Anbieter, in deren Cloud Entwickler ihre Anwendungen laufen lassen. Prominentester Provider ist Amazon. Seit der Release von dessen Dienst Lambda haben auch andere Firmen mit einem ähnlichen Ansatz nachgezogen – teilweise noch in Betaversionen. Dazu gehören Microsoft mit Azure Functions, Google mit seinen Cloud Functions und IBM mit Bluemix Open Whisk.
Im Grunde verschieben sich bei Serverless lediglich die Verantwortlichkeiten. Entwickler nutzen Cloud-Ressourcen, um bestimmte Funktionen einer Anwendung als reinen Code auszuführen und ohne dafür vorher Kapazitäten wie eine virtuelle Maschine zu reservieren. Vorteil für die Entwickler: Sie brauchen sich nicht damit auseinanderzusetzen, wie sie die Infrastruktur ihrer Anwendung bei zunehmender Last skalieren – das ist Aufgabe des Providers.
Kunden zahlen nur für abgewickelte Transaktionen oder durchgeführte Requests sowie für die Codeausführungszeit. Dabei nutzen Unternehmen den Vorteil der großen Cloud-Provider, nahezu beliebig Infrastrukturressourcen zur Verfügung zu haben.
Gleichzeitig kommt Entwicklern deutlich mehr Betriebsverantwortung zu, als es heute oft der Fall ist. Wenn die Applikation lahmt, gibt es keinen Ops-Ansprechpartner. Entwickler müssen das Anwendungsdesign verbessern. Das ganze System basiert auf Triggern und Funktionen. Der Provider ist dafür zuständig, dass die Funktionen ausgeführt werden, sobald der entsprechende Trigger ausgelöst wurde. Er stellt sicher, dass die dafür notwendige Rechenleistung bereitsteht. Das klingt zunächst verlockend, entfällt doch der ganze Ops-Teil eines DevOps-Betriebes. Dahinter steckt also eine Art NoOps-Ansatz.
Kontrollverlust befürchtet
Doch hier ist der Haken: Während Entwickler einerseits entlastet werden, fürchten Unternehmen andererseits einen Kontrollverlust. Sie wollen oder müssen aus Compliance-Gründen die Hoheit über einzelne Vorgänge behalten. Das bedeutet, genau zu wissen, wann was passiert und welche Aktionen ausgelöst werden. Insbesondere, wenn es sich um geschäftskritische Anwendungen handelt. Je mehr Aufgaben und Verantwortung der Cloud-Provider übernimmt, desto abhängiger sind Cloud-Nutzer von dessen Kompetenzen, Diensten und Verfügbarkeiten. Deshalb lohnt sich ein kritischer Blick auf die Service Level Agreements der Cloud-Provider. Aufschlussreich sind dabei auch veröffentlichte Ausfallmeldungen. Darüber hinaus setzt diese Technik oft ein Redesign einer bestehenden Anwendungsarchitektur voraus.
Um Serverless zu realisieren, sind also zum einen klare Verantwortlichkeiten zwischen Unternehmen und Provider festzulegen und zum anderen sind die Applikationen als Cloud-native Anwendung anzupassen. Unternehmen sollten sich zudem Gedanken machen, wie sie mit Incidents umgehen. Oft sind dafür ITIL-Prozesse hinterlegt, die so nicht mehr umsetzbar sind. Daher sind angepasste Prozesse nötig, die beispielsweise genügend Ressourcen für die Überwachung von Applikationen umfassen.
Ein weiterer Punkt, der Serverless derzeit noch ausbremst, ist der proprietäre Ansatz. Wenn sich Unternehmen auf das Ökosystem des Cloud-Providers einlassen und dessen Dienste wie AWS DynamoDB für Datenbanken oder Kinesis für Streamings einsetzen, steigt die Abhängigkeit vom Provider und macht einen Anbieterwechsel schwierig. Ein weiterer Grund, warum Entwickler noch zögern, Serverless-Dienste zu nutzen: Die Angebote der Provider verwenden meist verschiedene Ansätze zur Definition von Triggern und bieten ein unterschiedliches Spektrum an Programmiersprachen. Google beispielsweise versteht derzeit nur Node.js.
Unterm Strich ist Serverless Computing oder FaaS ein vielversprechendes Konzept, das mehr Tempo und einen höheren Automatisierungsgrad in Anwendungsentwicklung und Betrieb sowie nahezu beliebiges Skalieren ermöglicht. Doch noch steckt es in den Kinderschuhen. Um daraus herauszuwachsen, müssen Anbieter ein praktikables und zuverlässiges Servicemodell aufbauen und Standards bei der Trigger-Definition etablieren.
Auf der anderen Seite sollten Unternehmen diesen NoOps-Ansatz nicht unterschätzen und ihre Prozesse gerade im Hinblick auf Incidents anpassen sowie auf klare Verantwortlichkeiten in den SLAs achten. Auf lange Sicht wird sich Serverless aufgrund seiner starken Vorteile in der Breite insbesondere für von Grund auf dafür designte Anwendungen oder Anwendungsteile sowie Microservices bewähren. Dass einerseits der Softwareanteil in Unternehmen stark wächst und Cloud bereits heute schon Commodity ist, spielt Serverless zusätzlich die Hände. (jab)