Im Serverless-Modell werden Anwendungskomponenten wie Datenbanken oder Komponenten zur Datenverarbeitung automatisch und bedarfsabhängig vom Cloud-Provider zur Verfügung gestellt und betrieben. Die Verantwortung des Cloud-Nutzers liegt darin, diese Ressourcen zu konfigurieren – etwa durch eigenen Code oder anwendungsspezifische Parameter – und sie zu kombinieren.
Kosten fallen nach verbrauchten Kapazitäten an und die Skalierung erfolgt automatisch auf Basis der Last. Bereitstellung, Skalierung, Wartung, Hochverfügbarkeit und Verwaltung von Ressourcen liegen in der Verantwortung des Cloud-Providers.
Serverless eignet sich besonders für schwer vorhersehbare oder kurzlebige Arbeitslasten, für Automatisierungsaufgaben oder Prototypen. Serverless ist weniger ideal für ressourcenintensive, langlebige und planbare Aufgaben, da in diesem Fall die Kosten signifikant höher sein können als bei selbstverwalteten Ausführungsumgebungen.
Building Blocks
Im Rahmen eines Serverless-Adventskalenders wurden die Cloud-Services von AWS und Azure gegenübergestellt. Die Türchen öffnen sich unter dem Hashtag #ZEISSDigitalInnovationGoesServerless.
| Kategorie | AWS | Azure |
|---|---|---|
| COMPUTE Serverless Function | AWS Lambda | Azure Functions |
| COMPUTE Serverless Containers | AWS Fargate Amazon ECS/EKS | Azure Container Instances / AKS |
| INTEGRATION API Management | Amazon API Gateway | Azure API Management |
| INTEGRATION Pub-/Sub-Messaging | Amazon SNS | Azure Event Grid |
| INTEGRATION Message Queues | Amazon SQS | Azure Service Bus |
| INTEGRATION Workflow Engine | AWS Step Functions | Azure Logic App |
| INTEGRATION GraphQL API | AWS AppSync | Azure Functions mit Apollo Server |
| STORAGE Object Storage | Amazon S3 | Azure Storage Account |
| DATA NoSQL-Datenbank | Amazon DynamoDB | Azure Table Storage |
| DATA Storage Query Service | Amazon Aurora Serverless | Azure SQL Database Serverless |
| SECURITY Identity Provider | Amazon Cognito | Azure Active Directory B2C |
| SECURITY Key Management | AWS KMS | Azure Key Vault |
| SECURITY Web Application Firewall | AWS WAF | Azure Web Application Firewall |
| NETWORK Content Delivery Network | Amazon CloudFront | Azure CDN |
| NETWORK Load Balancer | Application Load Balancer | Azure Application Gateway |
| NETWORK Domain Name Service | Amazon Route 53 | Azure DNS |
| ANALYTICS Data Stream | Amazon Kinesis | Analytics |
| ANALYTICS ETL Service | AWS Glue | Azure Data Factory |
| ANALYTICS Storage Query Service | Amazon Athena | Azure Data Lake Analytics |
Einen Überblick zu den genannten Services und ihren Eigenschaften sowie einige beispielhafte Architekturmuster haben wir in Form eines Posters zusammengetragen. Dieser Überblick ermöglicht einen leichten Einstieg in das Thema Serverless-Architektur.
Gerne senden wir Ihnen das Poster auch in Originalgröße (1000 x 700 mm) zu. Schreiben Sie uns dazu einfach eine E-Mail mit Ihrer Adresse an info.digitalinnovation@zeiss.com. Beachten Sie hierzu bitte unsere Datenschutzhinweise.
Best Practices für Serverless-Funktionen
Jede Funktion sollte nur eine Sache tun (Single Responsibility Principle). Dies verbessert Wartbarkeit und Wiederverwendbarkeit. Speicherkapazität, Zugriffsrechte und Timeout-Einstellung können gezielter konfiguriert werden.
Mit der Erhöhung des zugewiesenen Speichers einer Lambda-Funktion werden auch CPU‑ und Netzwerkkapazität erhöht. Ein optimales Verhältnis aus Ausführungszeit und Kosten sollte per Benchmarking gefunden werden.
Eine Funktion sollte keine weitere Funktion synchron aufrufen. Das Warten führt zu unnötigen Kosten und erhöhter Kopplung. Stattdessen ist asynchrone Verarbeitung, z. B. über Message Queues, einzusetzen.
Das Deployment-Paket einer Funktion sollte so klein wie möglich sein. Auf große externe Bibliotheken ist zu verzichten. Das verbessert die Kaltstartzeit. Wiederkehrende Initialisierungen von Abhängigkeiten sollten außerhalb der Handler-Funktion stattfinden, damit sie nur einmalig beim Kaltstart ausgeführt werden müssen. Es ist ratsam, betriebliche Parameter über Umgebungsvariablen einer Funktion abzubilden. Das verbessert die Wiederverwendbarkeit.
Die Zugriffsberechtigungen auf andere Cloud-Ressourcen sind für jede Funktion individuell und so restriktiv wie möglich zu definieren. Zustandsbehaftete Datenbankverbindungen sind zu vermeiden. Stattdessen sollten Service-APIs verwendet werden.
Dieser Beitrag wurde verfasst von:
