Entwicklung und Betrieb einer Serverless E-Commerce-Lösung für die Verpackungsindustrie in der Google Cloud

In diesem Post beschreibe ich die Erfahrungen, welche ich bei der Entwicklung der E-Commerce-Lösung für “aXpel one for all” gesammelt habe. Es handelt sich um eine Applikation für die Verpackungsindustrie. Technologisch wurde eine Cloud Native-Lösung entwickelt, welche auch die Integration in ein externes ERP-System beinhaltet. Der Post soll Entscheidungsträgern helfen, sich eine Meinung darüber zu bilden, ob die Entwicklung einer Serverless-Lösung in der Google Cloud auch für sie in Betracht kommt.

Autor: Roberto De Simone
Datum: 04.01.2024
Aktualisiert: 03.11.2024

Auf dieser Seite

• Was bedeutet Serverless Computing
• Der Nutzen von Serverless Computing
• Die Motivation, die Google Cloud zu verwenden
• Google Cloud Services zum Betreiben der E-Commerce-Lösung
• Zusammenfassung

Was bedeutet Serverless Computing

Die Bezeichnung “Serverless” lässt zunächst vermuten, dass keine Server zum Einsatz kommen. Selbstverständlich braucht es aber auch für Serverless-Lösungen Servers. Es kommen - bei einer umfangreichen Anwendung - sogar eine Vielzahl von virtuellen Servern zum Einsatz. Nur muss man diese nicht unterhalten, und sie können je nach Bedarf skaliert werden. Wenn man zum Beispiel eine Datenbank verwenden möchte, so nutzt man den Cloud SQL Service und definiert je nach Workload die benötigten Systemressourcen. Als Benutzer kann man sich dann auf die Datenbank-Funktionalitäten konzentrieren und braucht sich nicht mit den darunter liegenden Servern oder um die Unterhaltung der Datenbank-Engine wie z.B. PostgreSQL, MySQL oder SQL Server zu kümmern.

Neben Cloud SQL gibt es eine Vielzahl von weiteren Services, die bei einer Cloud-Lösung verwendet werden können; und hinter jedem Service befinden sich Server. Auf einige dieser Services werde ich im Laufe dieses Posts noch zu sprechen kommen.

Der Nutzen von Serverless Computing

Der Nutzen des Serverless Computing ist aus meiner Erfahrung vielfältig:

• Die Systemressourcen können, wie bereits geschrieben, je nach Bedarf skaliert werden. Man bezahlt nur die Ressourcen und die Lizenzen, die man wirklich benötigt. Ob dies im Vergleich zu einer On-Premise (On-Site Hosting) Lösung wirklich günstiger ist, muss im Gesamtkontext betrachtet werden.
• Für den Betrieb braucht es nur beschränktes Systemadministratoren-Wissen (bei komplexeren Lösungen, v.a. wenn man virtuelle Netzwerke einsetzt, kommt man um solches Know-how allerdings nicht herum). Es braucht keinen Wartungsaufwand, um die Systemkomponenten auf dem neuesten Stand zu halten.
• Es stehen eine Vielzahl von Services zur Verfügung, die nach Belieben der Lösung bequem hinzugefügt werden können. Braucht man z.B. ein Content Delivery Network zum Cachen von Daten, kann der Cloud CDN Service hinzugefügt werden; oder sollen Daten automatisch übersetzt werden, kann der bekannte Google Translate Service in die Lösung integriert werden. Google macht es Kunden wirklich einfach, einen Service zu integrieren - alles kommt aus einer Hand -, aber es hat auch seinen Preis. Dazu am Ende mehr.
• Die Sicherheit dürfte im Vergleich zu einer selbst gemanagten Lösung höher sein, da durch die gemanagten Services bereits Best Practices angewendet werden, und es somit weniger Einfallsvektoren für Angriffe gibt. Zusätzlich schützt die Google Cloud bereits von Grund auf vor einer Reihe von Attacken. Mit dem Cloud Armor Service steht ein weiterer Service zur Verfügung, mit welchem der Traffic detailliert gefiltert werden kann. All dies vermeidet aber nicht, dass auch die eigentliche Softwarelösung selbst mit Best Practices implementiert werden muss.

Die Motivation, die Google Cloud zu verwenden

Cloud Run, der Dienst für Serverless-Cloud-Lösungen

Der Service Cloud Run war für mich ausschlaggebend, um eine Serverless-Lösung in der Google Cloud zu entwickeln. Mit Cloud Run können Applikations-Container gemanagt ausgeführt werden. Bei einem solchen Container handelt es sich zum Beispiel um ein API, welches mit Java Spring Boot oder .NET Core entwickelt wurde. Auch das Benutzerinterface, welches mit Angular, React oder mit einem sonstigen Web Framework entwickelt wurde, wird in einem Container ausgeführt. Eine Lösung besteht somit aus verschiedenen Applikations-Containern. Die Container können untereinander kommunizieren, oder sie können auf weitere Services wie z.B. den bereits erwähnten Cloud SQL Service zugreifen. Diese Container können je nach Workload beliebig skaliert werden. Nimmt der Traffic zu, so wird automatisch ein weiterer Container hochgefahren. Bevor es Cloud Run gab, musste man Container-Lösungen selber mit einem Orchestrierungs-Tool wie Kubernetes unterhalten. Dies war und ist mit sehr viel Know-how verbunden. Kubernetes sind aber vermutlich immer noch die erste Wahl für wirklich grosse Anwendungen.

Mittlerweile besitzen auch Microsoft Azure und Amazon AWS einen ähnlichen Service wie dies die Google Cloud mit Cloud Run anbietet.

Google Cloud Services zum Betreiben der E-Commerce-Lösung

Für einfache Lösungen reicht Cloud Run alleine aus. So wird auch diese Website in der Google Cloud mit Cloud Run gehostet. In einem Container wird die mit Astro entwickelte Site ausgeführt.

Cloud Run übernimmt ebenfalls das Management des SSL Zertifikats. Es reicht, dass die DNS Einträge der verwendeten Domaine auf die Google Cloud zeigen. Man kann ebenfalls wählen, welches Rechenzentrum verwendet werden soll. Kurzum: einmal mit Cloud Run vertraut, eröffnet dieses auf einfachste Weise extrem flexible Hosting-Möglichkeiten.

Für komplexere Lösungen reicht Cloud Run alleine nicht aus. Sehr bald stellt man fest, dass ein Load Balancer benötigt wird. Dieser ermöglicht die Verwendung des bereits erwähnten Cloud CDN (Content Delivery Network). Gerade für E-Commerce-Lösungen (Shop), bei denen ein sehr schneller Seitenaufruf wichtig ist, kommt man nicht um ihn herum. Auch ermöglicht ein Load Balancer optimale Performance, wenn Kunden in mehreren Regionen oder gar weltweit erreicht werden sollen. Ebenso braucht es den Load Balancer, wenn der ebenfalls bereits erwähnte Service Cloud Armor eingesetzt werden soll, welcher es erlaubt den Traffic zu filtern. Cloud Armor besitzt zusätzlich die Option “Adaptive Protection”, mit welcher der Traffic mit Hilfe von Machine Learning (ML) analysiert wird und automatische Vorschläge für das Filtern von verdächtigen Requests gemacht werden. Allerdings sind die Kosten dafür bedauerlicherweise beträchtlich, so dass der Einsatz dieses Services nur für wirklich grosse Anwendungen in Frage kommt.

Für die Datenbank wird der bereits erwähnte Service Cloud SQL verwendet. Auf diesen werde ich nicht mehr weiter eingehen, da der Einsatz eigentlich selbsterklärend ist.

Wenn es darum geht, Daten mit externen Systemen auszutauschen, braucht es weitere Services, die einen verlässlichen Datenaustausch gewährleisten. Der Cloud Task Service ermöglicht zum Beispiel die Synchronisierung von Aufträgen des Shops mit dem ERP System. Wenn im Shop eine neue Bestellung eintrifft, wird dafür ein Task erstellt, welcher die Shop-Bestellung mit dem ERP System synchronisiert. Der Task ruft Befehle (Endpoints) in einem Cloud Run Container auf, welche wiederum die Schnittstelle des ERP Systems aufrufen, um die Daten im ERP System zu erfassen. Diese Aufgabe gelangt in eine Queue, die abgearbeitet wird. Erst wenn die Daten erfolgreich im ERP System erfasst wurden, gilt die Aufgabe als erledigt und wird aus der Queue entfernt. Sollte das ERP System z.B. aufgrund eines Netzwerkfehlers nicht erreicht werden können, wird der Task in selbst definierten Intervallen erneut ausgeführt. Als Alternative zu Cloud Task kann auch Cloud Pub/Sub verwendet werden.

Wenn ein externer Service aus Sicherheitsgründen eine fixe IP-Adresse verlangt, so braucht es ein VPC Network. Ein Cloud Run Container besitzt standardmässig keine fixe ausgehende IP Adresse. Wenn man alle Abfragen über ein VPC Network leitet, kann man diesen eine fixe IP Adresse zuordnen.

Cloud Scheduler ist ein Service, mit welchem Aufgaben zu bestimmten Zeitpunkten ausgeführt werden können, zum Beispiel die Synchronisierung von Artikeln zwischen dem ERP System und dem Shop. Auf einem Linux Server würde man dafür einen Cron Job erstellen.

Weitere nützliche Services sind der Google Translate Service und Cloud Storage. Mit ersterem werden fehlende Lokalisierungen in den Artikeln des ERP Systems automatisch für den Shop lokalisiert. Im Cloud Storage werden sämtliche Artikel-Bilder abgelegt, welche mit Hilfe des Load Balancers im Cloud CDN gecacht werden, um einen schnellen Zugriff auf diese zu gewährleisten.

Die Google Cloud besitzt natürlich noch eine Vielzahl von weiteren Services, die je nach Anwendung eingesetzt werden können.

Es gibt aber auch Dinge, die fehlen: so gibt es erstaunlicherweise keinen E-Mail Service für den Versand von Transaktions-E-Mails (Bestellbestätigungen). Zum Vergleich: Amazon AWS besitzt dafür den Amazon SES Service. In unserem Fall verwenden wir SendGrid von Twillo.

Zusammenfassung

Es ist faszinierend, welche Möglichkeiten durch das Angebot der zahlreichen Cloud Services für die Entwicklung einer Cloud Native-Anwendung entstehen. Der Einsatz ähnlicher Produkte bei einer selbst gehosteten Lösung ist im Gegensatz dazu mit hohem Wartungs- und auch Entwicklungs-Know-how verbunden.

Auch gibt es immer mehr Services, v.a. im Machine Learning-Bereich, die nur noch von den grossen Cloud Providern angeboten werden können.

Immer raffiniertere Hacker-Angriffe stellen On Premise-Lösungen vor grosse Herausforderungen. Die Cloud bietet durch ihre Best Practices bereits von Grund auf mehr Schutz.

Eine Cloud Lösung hat aber auch ihren Preis: Wenn man sich eine Monatsabrechnung der Google Cloud anschaut, so ist die grösste Rechnungsposition “Compute Engine”, welche den Kosten der verschiedensten gemanagten Virtuellen Servern entspricht. Wie schon zu Beginn geschrieben: hinter den Services liegen eben auch Server, die Rechenleistung verbrauchen.

Unter dem Strich summieren sich die Kosten der einzelnen Services.

Eine ähnliche On Premise-Lösung mit selbst gemanagten virtuellen Servern und Open Source-Produkten wäre deutlich günstiger. Trotzdem überwiegen meiner Meinung nach die zu Beginn beschriebenen Nutzen der Google Cloud-Lösung immer noch deutlich.

Ob dies so bleiben wird, hängt auch davon ab, ob Google oder auch die anderen Cloud-Anbieter ihre Position nicht verstärkt anfangen werden auszunutzen. Es gibt bereits die ersten Kunden, die sich wieder aus der Cloud verabschieden. Wenn die Kosten zu hoch werden, könnte ein neuer Markt für lokale Lösungen entstehen. Die Geschichte würde sich dann wiederholen, wie dies der Wechsel vom Mainframe zu lokalen Servern in den 90er Jahren gezeigt hat.