Thought Leadership
Serverless-Architekturen haben für Unternehmen enorme Vorteile – den passenden Anwendungsfall vorausgesetzt. Doch nicht für jede App eignet sich das Modell, wenn etwa das Projekt komplex und kostspielig wird.
Der größte Vorteil des Cloud-nativen Entwicklungsmodells, das unter dem Begriff „Serverless“ bekannt ist, ist seine zunächst einfache Einsatzmöglichkeit. Unternehmen müssen kein Personal für die oft mühselige Verwaltung von Server-Infrastrukturen bereitstellen, das übernimmt der jeweilige Cloud-Anbieter. Auch andere aufwendige Routineaufgaben wie Provisionierung und Skalierung liegen nicht mehr in der Verantwortung interner IT-Abteilungen.
Für die Bereitstellung von Funktionen einer Anwendung genügt es, wenn die Entwickler den entsprechenden Code in Container packen und via Cloud verfügbar machen. Nach dem Deployment werden die jeweiligen Funktionen nur nach Bedarf ausgeführt und verursachen konsequent auch nur dann Kosten. Ist die Nachfrage allerdings besonders groß, kann das rein Cloud-basierte Serverless-Modell recht schnell teuer werden. Dafür ist es besonders für Funktionen und Services günstig, die nur selten in Anspruch genommen werden.
Aller Anfang ist leicht
Serverless-Architekturen ermöglichen es Anwendungsentwicklern, skalierbare, flexible und effiziente Funktionen und Services initial kostengünstig in Business-Anwendungen zu implementieren. Ein Risiko bleibt allerdings, denn auch wenn der Einstieg in die Welt von Serverless recht einfach ist, nimmt die Komplexität sehr schnell zu, wenn Entwickler anspruchsvollere Ressourcen nutzen möchten, etwa API-Gateways, die zwischen Client und mehreren Backend-Services sitzen und die Aufrufe managen.
Je mehr das jeweilige Unternehmen auf Serverless-Architekturen baut, desto größer wird auch die Gefahr eines Vendor-Lock-ins. Das sollten Entscheidungsträger im Kopf behalten, wenn sie eine Serverless-Strategie festlegen wollen, mit der sie auch langfristig anbieterbezogene und sicherheitstechnische Risiken umgehen können. Herrscht im Unternehmen ein entsprechendes Bewusstsein, kann es die Vorteile von Serverless nutzen, ohne potenzielle Fallstricke fürchten zu müssen.
Serverless muss zur Anwendung passen
Nicht für alle Fälle ist eine Serverless-Architektur die richtige Wahl. Benötigt die designierte „serverlose“ Anwendung eine erhebliche Skalierung und erzeugt sehr hohen Traffic über längere Zeiträume, kann sie sehr teuer werden. Eine günstigere Alternative ist in dem Fall eine Compute-Cloud wie Amazon EC2, die Rechenkapazitäten in der Cloud bereitstellt. Auch für Anwendungen, die sehr niedrige Reaktionszeiten benötigen, beispielsweise Echtzeitanwendungen, sind Serverless-Szenarien eher ungeeignet.
Einen potentiellen Wechsel zu Serverless sollten Entscheidungsträger daher nur auf Grundlage einer ausführlichen Kosten-Nutzen-Analyse entscheiden. Tech-Teams initiieren Serverless-Projekte leider viel zu häufig, weil sie dem Shiny-Object-Syndrom verfallen sind, sich also unbedarft auf Trends stürzen und sie wieder fallen lassen, sobald eine neue Technologie Schlagzeilen macht. Die Risiken und Konsequenzen einer Implementierung von Serverless sind allerdings schwerwiegend, wenn zuvor nicht die Vorteile für einen spezifischen Anwendungsfall nachgewiesen sind und das Unternehmen eine genaue Abwägung der endgültigen Kosten und Ergebnisse durchgeführt hat.
Serverless-Architekturen sparen Unternehmen Zeit und Geld – vorausgesetzt das Paradigma passt zum Konzept der Business-Anwendung.
Auch das Mindset der Entwickler muss zu den speziellen Anforderungen von Serverless passen. Es ist zum Beispiel unabdingbar, dass sie ein tiefgreifendes Verständnis dafür haben, wie Serverless- und ereignisgetriebene Architekturen aufgebaut sind. Auch die Spezifikationen und Limitierungen der genutzten Plattform (etwa AWS oder Google Cloud) müssen Entwickler kennen und vor allem Anwendungs- und Datensicherheit im Blick haben. Die Lernkurve von Serverless ist sehr steil, weshalb insbesondere die Tech-Teams – nicht nur das Management – sicher sein müssen, dass es die richtige Wahl für die Business-Anwendung ist. Und das natürlich bevor das Unternehmen in diese Technologie investiert.
Gefahrenherd Vendor-Lock-in
Serverless-Architekturen gehen darüber hinaus leider oft mit einem Vendor-Lock-in einher, denn Serverless-Code ist in der Regel speziell auf die Plattform abgestimmt. Es kann daher später sehr aufwendig werden, Funktionen und Services einer Business-Anwendung auf eine andere Plattform zu portieren. Häufig müssen Entwickler bei einem Plattformwechsel die gesamte Anwendung neu schreiben.
Eine Möglichkeit, diesen teuren und arbeitsintensiven Umstand zu umgehen, ist die Nutzung von Open-Source-Frameworks wie Apache OpenWhisk oder Fission. Da es sich bei ihnen jedoch um relativ neue Lösungen handelt, müssen Entwickler unter Umständen sehr viel Arbeit in das Aufsetzen und Deployment des Serverless-Frameworks stecken. Leichter ist es in jedem Fall, wenn Unternehmen auf Anbieter von Managed Cloud Services zurückgreifen, die quelloffene Serverless-Frameworks unterstützen.
Sicherheit ist auch Eigenverantwortung
Ein potenziell großes Risiko ist die gefährliche Annahme, dass der Cloud-Anbieter sich vollständig für die Sicherheit der Serverless-Anwendung verantwortlich zeichnet. Natürlich ist in einem solchen Szenario der Plattformanbieter für die Sicherheit des Servers, des Betriebssystems, der Plattform selbst und der Infrastrukturebene zuständig. Die Verantwortung für den Code der Anwendung und dessen Sicherheit liegt jedoch beim entwickelnden Unternehmen. Die interne IT-Abteilung muss dafür sorgen, dass sie den Anwendungscode unter Einhaltung sicherer Programmierverfahren schreiben und sie alle verwendeten Daten absichern. Steht die Umstellung auf Serverless also im Raum, ist es an den Verantwortlichen im Unternehmen, ihre Teams intensiv im Hinblick auf diese Verantwortung des neuen Paradigmas zu schulen.
Unternehmen, die sich für Serverless entscheiden, könnten sich zudem mit einer deutlich erhöhten Anzahl an Bedrohungsbereichen und größeren Sicherheitsrisiken konfrontiert sehen. Auch einige „Blind Spots“ in der Sicherheitsstrategie zeigen sich dann oft. Da der Anwendungscode immer kleiner wird und autonom läuft, wird es für Entwickler immer schwerer, Zugriffskontrollen zu implementieren. Somit ist auch die Sicherheit der Daten bei ihrer Übertragung und im Ruhezustand sowie beim Austausch von Informationen mit Funktionen, Bibliotheken und Plug-ins von Drittanbietern durch immer kleinerer Code-Basen gefährdet.
Serverless-Anwendungen sind durch ihre ereignisgetriebene Natur überdies das perfekte Ziel für eine abgewandelte Version von Denial-of-Service-Attacken: Statt den Nutzern den Dienst zu verweigern, führen diese Angriffe zu einer unnötigen Skalierung des Ressourcenbedarfs auf der Serverless-Plattform. Für den Betreiber der Anwendung wird es dann teuer, denn die Ressourcen müssen sie bezahlen.
Die Risiken bei der Implementierung einer Serverless-Architektur sind zwar beträchtlich und müssen direkt angegangen werden. Doch in vielen Fällen wiegen die potenziellen Vorteile die möglichen Probleme durchaus auf. Eine sorgfältige und bewusste Herangehensweise an die Einführung von Serverless, bei der die Vermeidung von Vendor-Lock-ins und die Verringerung von Risiken im Fokus liegen, ist das A und O. Durch die Wahl der richtigen Tools und Partner können Unternehmen Serverless-Modernisierungsinitiativen mit Zuversicht umsetzen.
