In dieser Ausgabe unserer Tech-Radar-Reihe wollen wir uns mit der „Function-as-a-Service“-Technik beschäftigen. Diese Technologie wird beim MSH konkret eingesetzt, dennoch ist ein kritischer Blick darauf angebracht.
Die Architektur moderner Softwareanwendungen verändert sich rasant. Ein Trend, der immer mehr an Bedeutung gewinnt, ist Serverless Computing, insbesondere in Form von Functions-as-a-Service (FaaS). Unternehmen wie Amazon, Google und Microsoft bieten mit AWS Lambda, Google Cloud Functions und Azure Functions leistungsfähige Lösungen an. Doch ist dieser Ansatz wirklich die Zukunft der Softwareentwicklung? Oder gibt es versteckte Risiken, die man vor dem Umstieg bedenken sollte?
Was bedeutet „Serverless“ eigentlich?
Der Begriff „Serverless“ ist etwas irreführend – denn natürlich läuft auch Serverless-Software weiterhin auf Servern. Der Unterschied zur traditionellen Infrastruktur ist jedoch, dass Entwickler sich nicht mehr um deren Verwaltung kümmern müssen. Statt VMs oder Container bereitzustellen, schreiben sie einfach einen Code, der durch bestimmte Ereignisse ausgelöst wird. Diese sogenannten Functions-as-a-Service (FaaS) werden automatisch skaliert und abgerechnet – nur für die tatsächliche Nutzung. Typische Anwendungsfälle für Serverless-Architekturen sind Event-getriebene Datenverarbeitungen in Echtzeit. Fälle in denen schnell skaliert werden muss, in Reaktion auf auftretende Ereignisse.
Die Vorteile: Warum setzen viele Unternehmen auf Serverless?
- Automatische Skalierung: Funktionen werden nur dann ausgeführt, wenn sie gebraucht werden. Bei hoher Last skaliert das System automatisch – ohne Konfigurationsaufwand.
- Kosteneffizienz: Statt dauerhaft laufender Server zahlt man nur für die tatsächlich genutzte Rechenzeit. Das macht Serverless besonders attraktiv für Anwendungen mit schwankender Last.
- Entwicklerfokus auf Business-Logik: Teams müssen sich nicht mehr um Infrastruktur kümmern, sondern können sich vollständig auf die Entwicklung der eigentlichen Anwendung konzentrieren.
Die Schattenseiten: Wo liegen die Herausforderungen?
- Cold Starts & Performance-Probleme: Da Serverless-Funktionen nur bei Bedarf geladen werden, kommt es naturgemäss zu sogenannten „Cold Starts“ – einer Verzögerung von Sekunden. Für hochperformante Anwendungen ist das ein Problem.
- Lock-in-Gefahr bei Cloud-Anbietern: Die großen Cloud-Anbieter bieten unterschiedliche Serverless-Implementierungen, die nur proprietäre Lösungen nutzen (z. B. AWS Lambda mit API Gateway). Dadurch ist es unmöglich, die Anwendung auf eine andere Plattform zu portieren.
- Begrenzte Laufzeit & Ressourcen: Serverless-Funktionen sind für kurze, schnelle Berechnungen optimiert. Viele Anbieter begrenzen die Laufzeit einer Funktion (z. B. 15 Minuten bei AWS Lambda), was den Einsatz für langlaufende Prozesse verbietet.
- Komplexität in der Fehlerbehandlung & Debugging: Da Serverless-Anwendungen stark verteilt sind, ist Debugging deutlich schwieriger. Logging und Monitoring erfordern oft zusätzliche Tools die den Fokus der Entwickler wieder von der Business-Logik abziehen.
Fazit: „Serverless First“ oder doch lieber Hybrid?
Unser Tech-Radar-Fazit: Serverless ist eine Technologie, die in bestimmten Anwendungsfällen große Vorteile bietet – aber nicht jede Anwendung passt in dieses Modell.
Eine „Serverless-First“-Strategie ist nur dann sinnvoll, wenn man die technischen und wirtschaftlichen Rahmenbedingungen genau evaluiert.
Oftmals bietet sich ein Hybrid-Ansatz an: Kritische Kernsysteme laufen weiterhin in Containern oder auf dedizierten Servern, während skalierbare, event-getriebene Prozesse mit Serverless umgesetzt werden.
