Die Vorteile bei der Nutzung der Cloud hat inzwischen viele Unternehmen überzeugt diesen strategischen Weg einzuschlagen. Trotz der Vorteile, die die Cloud mitbringt, sind für wichtige Bereiche in einem Unternehmen eine eigene Datenhaltung in einer selbst gehosteten Infrastruktur aus Sicherheitsgründen sehr wichtig. Bei der strategischen Entscheidung bzgl. der Nutzung eines öffentlichen Cloudanbieters (Public Cloud) wie AWS, GoogleCloud, OpenTelekomCloud oder Azure stellt sich zudem die Frage infwiefern man sich von einem Cloudanbieter zu sehr abhängig macht.

Die Klarna AB ist ein 2005 gegründetes Finanzstartup mit Hauptsitz in Stockholm (Schweden). Deren Dienstleistung liegt vor allem in der Online-Zahlungsabwicklung zwischen Händler und Endkunden und ist inzwischen einer der führenden Zahlungsanbieter in Europa. Klarna betreibt eine Vielzahl an Plattformen um Finanztransaktionen gesichert durchzuführen. Die Entwicklung der Plattformen erfolgt durch über tausend Softwareentwickler und -architekten in verschiedenen Entwicklerteams mit einer Vielzahl an Programmiersprachen und Tools. Durch die CloudOnly-Strategie wird der Betrieb ausschließlich in der AWS-Cloud organisiert.

In der Serie für die Loadbalancer für Artifactory hatten wir ja schon den OnTheFly-Switch vom ClassicELB zum Network Loadbalancer beschrieben (NLB) sowie die Änderungen an der Anzahl der konkurriernden Verbindungen dargestellt, die uns direkt nach der Umstellung auf den NLB aufgefallen sind (AWS - Reverse Proxy mit dem NLB in AWS). Kurz zum Setup Das Setup von Artifactory umfasst drei Instanzen mit einem davor geschaltetem Loadbalancer von AWS. Jede Instanz von Artifactory selbst ist eine Tomcatanwendung und einem NGINX Reverse Proxy davor.

In einem vorherigen Blogbeitrag (AWS - Migrieren eines ELB zum NLB on-the-fly) haben wir geziegt, wie man in AWS einen HA cluster mit Artifactory von einem “deprecated” ELB auf einen modernen NLB ohne Downtime umswitcht. Kurz zum Setup Das Setup von Artifactory umfasst drei Instanzen mit einem davor geschaltetem Loadbalancer von AWS. Jede Instanz von Artifactory selbst ist eine Tomcatanwendung und einem NGINX Reverse Proxy davor. Vorherige Bedenken Bedenken zum Switch von ELB zu NLB, die im Vorfeld vorhanden waren, bewahrheiteten sich nicht.

Das Projekt Aufgabe des DevOps Teams war es Artifact Management auf Basis von jFrog Artifactory (https://jfrog.com/artifactory/) zu betreiben. Das Team war die zentrale Schaltstelle für das Artifact Management innerhalb der Firma. Das System hatte einen 24/7 SLA und sollte wegen ihrer zentralen Bedeutung mit einem Minimum an Downtime, am besten gar keiner Downtime, laufen. Dafür lief Artifactory in einem Cluster mit drei Knoten, einer PostgreSQL Datenbank im Hintergrund und einem davor geschaltenen Reverseproxy auf Basis von NGINX.