Mit dem Release 2.1 wurde ESC um eine Funktion erweitert, die es ermöglicht, eine Erklärung für einen Namensvergleich zu erhalten. Das bedeutet, dass man nicht nur das eigentliche Ergebnis erhält, sondern auch einzelnen Schritte nachvollziehen kann, die zu diesem Ergebnis geführt haben. Von besonderem Interesse dürfte dabei die Quelle des Vergleichswertes von einzelnen Namenselementen sein. Warum stimmt "Bill" zu 97 % mit "William" überein? Die neue Erklärungsfunktion gibt Auskunft darüber, woher die 97 % kommen.
Ich nehme diese neue Funktion zum Anlass, um zu zeigen, wie einfach es ist, mit Cloud Function der Google Cloud Platform (GCP) einen Rest-API Endpoint zu realisieren. Um ein einfaches Name-Matching Rest-API zu realisieren, benötigen wir nur wenig Programmcode:
 |
| Scala-Programm mit zwei Rest-API Endpoints |
Zum Erstellen des JAR-Files verwenden wir die folgenden SBT-Konfigurationen:
 |
| build.sbt File mit den Konfigurationen und Abhängigkeiten |
Nachdem wir das Programm mit dem Befehl sbt assembly erstellt haben, können wir den ersten Endpunkt bereits mit folgendem Befehl einfach als GCP Cloud Function bereitstellen:
 |
| Bash-Befehl um die erste Cloud Function mittels gcloud CLI bereit zu stellen |
Im Anschluss können wir analog die zweite Funktion, mit EscOrganisationNameExplanation und --entry-point example.OrganisationNameExplanation bereitstellen - fertig. gcloud CLI gibt uns jeweils die URL für unsere Funktion zurück und wir können diese direkt aufrufen:
 |
| Printscreen einer API-Abfrage via Browser |
Wir sehen in der markierten Zeile die Ähnlichkeit von 97 % zwischen "William" und "Bill" und darunter die Quelle: libDb. Das bedeutet, dass die Ähnlichkeit aus der internen Datenbank der ESC-Bibliothek stammt. Bill ist eine bekannte Kurzform von William.
Theorie und Praxis
Wie sagte es einst Albert Einsteint:
«Man soll die Dinge so einfach wie möglich machen, aber nicht einfacher»
Die gezeigte Umsetzung funktioniert soweit technisch einwandfrei. In der Praxis ist sie aber vielleicht etwas zu einfach. Es gibt noch das eine oder andere Detail zu beachten, das ich hier nicht vorenthalten möchte. Schauen wir uns also noch 2-3 wichtige Themen an, die oben aus Gründen der Übersichtlichkeit weggelassen wurden.
Scala-Applikation
Ist für eine echte produktive Anwendung etwas kurz geraten. Allgemein wurde das Error-Handling weggelassen und spezifisch zum Use Case wäre es hilfreich, wenn man eine aussagekräftige Fehlermeldung erhalten würde, wenn man bspw. nicht alle notwendigen Parameter sendet. Im Beispiel wird in dem Fall einfach "Unknown" als Name verwendet. Werfe dazu unbedingt auch einen Blick auf Cloud Logging, um aussagekräftige Log-Einträge in Cloud Logging von GCP zu erhalten.
URL & Co.
Jede Cloud Function bekommt eine Standard Google-URL zugewiesen. In der Regel möchte man die Function aber über eine eigene Domain und ggf. mit einem anderen Pfad aufrufen können. Für die Realisierung empfiehlt sich die Umsetzung mittels eines Load Balancers. Dort kann man die Cloud Function als Backend angeben und Domain, Pfad, Zertifikate etc. festlegen.
Security & Co.
Das Beispiel ist als öffentliche API ausgelegt. Selbstverständlich möchte man nicht jede API öffentlich zugänglich machen. Es ist daher wichtig, bei Bedarf die Cloud Function entsprechend zu berechtigen und zu schützen. In Abhängigkeit der Bedürfnisse gibt es dazu verschiedene Optionen. Eine Möglichkeit wäre ein API Gateway zu verwenden. Dieses GCP-Produkt basiert auf Envoy (als Managed Service), welches verschiedene Möglichkeiten für die Sicherheit bietet. Als nächste Stufe, eine komplette API Management-Plattform, bietet sich mit Apigee eine Lösung an, die im Gartner Magic Quadrant regelmässig oben rechts zu finden ist. Einverstanden, der Preis befindet sich auch eher dort.
Weiter empfiehlt sich allenfalls die Sicherheit zusätzlich mit einer WAF zu verstärken. Naheliegend für Cloud Function wäre Cloud Armor zu verwenden.
GCP Landingzone
Voraussetzung um die Cloud Function wie eingangs beschrieben bereit zu stellen, ist eine eingerichtete Landingzone auf der GCP. Dazu gehört es, dass ein Rechnungs-Account aufgesetzt, ein Projekt erstellt und die notwendigen APIs aktiviert sind. Mit allen notwendigen Accounts und Berechtigungen versteht sich. Dies kann man manuell via Konsole machen. Für produktive Umgebungen lohnt es sich aber bereits bei kleineren Infrastrukturen, diese als IaC zu betrachten und entsprechend mittels Tools wie Terraform, Ansible, Puppet und wie sie alle heissen, zu automatisieren. Für grössere Infrastrukturen und vor allem wenn grössere, resp. viele Teams, involviert sind, lohnt sich wahrscheinlich einen Ansatz wie TACOS zu verwenden.
Deployment
Es gibt natürliche verschiedene Bereitstellungsmöglichkeiten. Die hier gezeigte ist die einfachste manuelle Art. Gerade bei grösseren Infrastrukturen/Projekten lohnt es sich solche Deplyoments automatisiert inkl. Build-, Test- und Security-Prozesse durchzuführen. Auf GCP bietet sich dafür Cloud Build an. Je nach Setup und Anforderungen direkt integriert mit den IaC-Tools von vorhin.
Achtung Kostenfalle
Insbesondere wenn die Cloud Function öffentlich zugänglich ist, besteht ein Kostenrisiko, wenn die Cloud Function millionfach aufgerufen wird. Es ist daher dringend empfohlen, auf dem GCP Projekt oder der Cloud Function selber, ein Budget einzurichten, um die Kostenkontrolle zu behalten. Bei den Budgets ist wichtig zu wissen, dass diese nur eine Alarmierung zur Folge haben. Die Services, und damit Kosten, laufen normal weiter. Man muss selber entsprechende Massnahmen ergreifen nach einem Alert. Es gibt allerdings bei gewissen Services die Möglichkeit, Quoten zu definieren/reduzieren, so dass nach Erreichung dieser, der Service nicht mehr zur Verfügung steht und entsprechend auch keine weiteren Kosten entstehen. Bei Cloud Function kann man dies bspw. für die Anzahl Request pro Minute definieren. Default sind 3'000 Request pro Minute. Man kann diese Limite selber reduzieren. Eine Erhöhung über 3'000 muss manuell bewilligt werden. Die Konfiguration kann man wie bereits bekannt, direkt via Konsole vornehmen oder indirekt via diverser IaC-Tools. Eine Doku dazu findet man hier. Die Kosten für Cloud Function können bequem mit dem Preisrechner von Google kalkuliert werden: GCP Preisrechnen.Also doch nicht so einfach?
Manch ein Leser ist vielleicht dazu geneigt zu denken: Einen plakativen einfachen Start beschreiben, um dann im Anschluss mit den komplexen Themen der Praxis wieder alles zu relativieren? Ist es also doch nicht so einfach, eine Cloud Function zu erstellen?
Meine Antwort ist: doch. Das ist die schöne Seite der Cloud. Man kann klein und einfach beginnen und dann skalieren, ohne dass man die gesamte Architektur bei jeder Iteration der Skalierung über den Haufen werfen muss. Man kann also so einfach anfangen wie gezeigt - ja, mit Fehlerhandling und Logs - und loslegen. Sobald es richtig public sein soll, kann man einen Load Balancer voranstellen und die Domain-Sachen definieren. Plötzlich muss man die Function trotzdem schützen? Dann kann man einen API Gateway konfigurieren und die gewünschte Security einrichten. IaC oder gar TACOS einführen ist etwas aufwändiger. Umso früher man damit beginnt, desto einfacher ist es (klein zu gross). Aber auch IaC lässt sich später Schritt für Schritt einführen. Wichtig ist, dass man bereits zu Beginn ein stimmiges Zielbild hat an dem man die Schritte dorthin ausrichten kann.
Die Herausforderung bei Hyperscalern ist nach meiner Erfahrung häufig die grosse Menge an möglichen Tools und Services und die schnellen Änderungszyklen. Welcher Service löst welches Problem am besten? Wie sieht es mit den Kosten aus? Es ist (zeitlich) kaum möglich, dass man für jedes Problem jeweils alle Varianten eines Hyperscalers zuerst sauber selber evaluiert und ausprobiert. Bei der Wahl von geeigneten Services und Architekturen gibt es aber zum Glück verschiedene (unabhängige) Spezialisten, die man beiziehen kann. Scheuen Sie sich nicht, dafür temporär externe Unterstützung in Anspruch zu nehmen.
Weitere nützliche Weblinks:
Keine Kommentare:
Kommentar veröffentlichen