{"id":23412,"date":"2022-08-22T14:28:35","date_gmt":"2022-08-22T12:28:35","guid":{"rendered":"https:\/\/blog.mi.hdm-stuttgart.de\/?p=23412"},"modified":"2025-02-25T22:04:08","modified_gmt":"2025-02-25T21:04:08","slug":"migration-einer-rest-api-in-die-cloud","status":"publish","type":"post","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/08\/22\/migration-einer-rest-api-in-die-cloud\/","title":{"rendered":"Migration einer REST API in die Cloud"},"content":{"rendered":"\n

Artikel von Cedric Gottschalk und Raphael Kienh\u00f6fer<\/em><\/p>\n\n\n\n

Im Rahmen der Endabgabe der Vorlesung “Software Development f\u00fcr Cloud Computing” haben wir uns zum Ziel gesetzt, eine bereits bestehende REST API eines vorherigen Projektes in die Cloud zu migrieren. Dabei haben wir uns daf\u00fcr entschieden, die Google Cloud zu verwenden. Im Zuge dieses Projektes haben wir uns auch mit Infrastructure as Code mittels Terraform besch\u00e4ftigt.<\/p>\n\n\n\n

Architektur<\/h2>\n\n\n\n

Vor dem Umzug in die Cloud lebte die API als Container auf einem einzelnen Server, der mittels Docker Compose verwaltet wurde. Hier wurde nginx als Reverse-Proxy eingesetzt, um die \u00dcbertragung mittels TLS zu sichern. MariaDB wurde als SQL-Datenbank eingesetzt. Die Verkn\u00fcpfung der einzelnen Dienste gestaltete sich hier durch den gemeinsamen technischen Unterbau (Docker) sehr simpel.<\/p>\n\n\n\n\n\n\n\n

\"Schaubild<\/a>
On Premises Architektur<\/figcaption><\/figure>\n\n\n\n

Cloud SQL<\/h3>\n\n\n\n

Das Produkt “Cloud SQL” der Google Cloud bietet lediglich Microsoft SQL Server, PostgreSQL und MySQL an. Da MariaDB und MySQL bin\u00e4rkompatibel sind, konnte hier ohne \u00c4nderung von Anwendungscode migriert werden. Aufgrund der Konzeption von relationalen Datenbankmanagementsystemen sind verteilte, redundante Datenbanken nur schwer umsetzbar. Google verwendet hier einen Failover-Ansatz, wobei Anwendungsdaten regelm\u00e4\u00dfig auf einen Klon der Datenbank gespiegelt werden. Im Falle eines Ausfalls der Hauptdatenbank werden Anfragen automatisch an den Klon weitergeleitet. Der Cloud SQL Service erm\u00f6glicht au\u00dferdem einen relativ einfachen Zugriff auf eine Datenbank von anderen Google Cloud Services aus, wie z.B. GKE.<\/p>\n\n\n\n

Google Kubernetes Engine (GKE)<\/h3>\n\n\n\n

Um die Vorteile einer Cloudinfrastruktur zu nutzen, wurde Docker Compose durch Kubernetes (von Google unter dem Produktnamen “Google Kubernetes Engine” (GKE) angeboten) ersetzt. Hier wird das Backend in mehreren sogenannten Pods ausgef\u00fchrt, die auf verschiedenen Nodes (Servern) verteilt gestartet werden und somit Redundanz bieten. Kubernetes \u00fcbernimmt hierbei auch die Aufgabe des Load Balancing, also der gleichm\u00e4\u00dfigen Verteilung der Anfragen auf die einzelnen Pods, um jeweils bessere Performance zu erzielen.<\/p>\n\n\n\n

Google Container Registry (GCR)<\/h3>\n\n\n\n

Da Kubernetes auf Containerisierten Anwendungen basiert, musste das Image des API-Servers f\u00fcr GKE zug\u00e4nglich gemacht werden. Hierf\u00fcr wurde die Google Container Registry verwendet, die wiederum ein Interface f\u00fcr Googles Cloud Storage ist.<\/p>\n\n\n\n

IAM<\/h3>\n\n\n\n

Die einzelnen Dienste in der Cloudumgebung unterscheiden sich in der technischen Umsetzung und sind auch alle auf eigenen VMs\/Servern bereitgestellt. Daher ergibt sich hier ein neuer Sicherheitsaspekt. W\u00e4hrend in der On Premises Architektur ein internes Netzwerk innerhalb des Docker-Hosts verwendet werden kann, muss die Kommunikation der einzelnen Komponenten mindestens zwischen Servern in einem Rechenzentrum, teilweise auch \u00fcber das Internet, erfolgen.<\/p>\n\n\n\n

Die dadurch notwendig werdende Berechtigungsverwaltung wird in der Google Cloud mittels “Identity and Access Management” (IAM) bereitgestellt. Hier kann man zum Beispiel weiteren Benutzern Zugriff auf die Infrastruktur bzw. deren Verwaltungstools geben. Au\u00dferdem k\u00f6nnen hier die Berechtigungen f\u00fcr sogenannte Service Accounts angepasst werden. Service Accounts werden von den Diensten der Google Cloud verwendet, um auf andere Dienste zuzugreifen. So verwendet beispielsweise GKE (beziehungsweise die Google Compute Engine, auf deren VMs GKE bereitgestellt wird) ihren Service Account, um sich gegen\u00fcber der Container Registry f\u00fcr den Download der Container-Images zu authentifizieren.<\/p>\n\n\n\n

Durch die gro\u00dfe Anzahl an Diensten und damit verbundenen Berechtigungen in der Google Cloud ist es durchaus herausfordernd, Probleme, die durch Berechtigungen (oder deren Abwesenheit) entstehen, zu l\u00f6sen (dazu mehr im Abschnitt Probleme).<\/p>\n\n\n\n

\"Schaubild<\/a>
Cloud Architektur<\/figcaption><\/figure>\n\n\n\n

API<\/h2>\n\n\n\n

Bei der API handelt es sich um eine mit Express in Node.js realisierte REST API. Ihre Aufgabe ist die Verwaltung von Highscores f\u00fcr das Spiel “Squid Game” (hat trotz des gleichen Namens nichts mit der Serie des bekannten Streamingdienstes zu tun), das im Rahmen eines Projektes in fr\u00fcheren Semestern produziert wurde. Die API ist nicht spezifisch auf das Spiel ausgelegt und kann f\u00fcr allgemeines Score-Tracking f\u00fcr Zeit- oder Punktbasierte Minispiele verwendet werden. Auf einen Authentifizierungsmechanismus wurde w\u00e4hrend der Entwicklung verzichtet, um die Komplexit\u00e4t gering zu halten.<\/p>\n\n\n\n

Die API realisiert (auch aufgrund der fehlenden Authentifizierung) kein vollst\u00e4ndiges CRUD-Pattern. Um beispielsweise ein neues Minispiel zu erstellen, ist ein manueller Eingriff in die Datenbank notwendig. Da dieser Fall als \u00fcblicherweise einmaliger Ablauf beim initialen Aufsetzen der Datenbank angesehen wurde, wurde diese Funktion nicht implementiert.<\/p>\n\n\n\n

Folgende Endpunkte sind in der API verf\u00fcgbar:<\/p>\n\n\n\n

GET \/minigames<\/h3>\n\n\n\n

Gibt eine Liste aller existierenden Minispiele zur\u00fcck.<\/p>\n\n\n\n

GET \/minigames\/{id}<\/h3>\n\n\n\n

Gibt Details zu einem Minispiel zur\u00fcck. <\/p>\n\n\n\n

GET \/minigames\/{id}\/scores<\/h3>\n\n\n\n

Gibt eine Liste von Punktzahlen eines Minispiels zur\u00fcck.<\/p>\n\n\n\n

POST \/minigames\/{id}\/scores<\/h3>\n\n\n\n

Hinzuf\u00fcgen einer neuen Punktzahl zu einem Minispiel.<\/p>\n\n\n\n

PATCH \/minigames\/{id}\/scores<\/h3>\n\n\n\n

Ver\u00e4ndern einer Punktzahl.<\/p>\n\n\n\n

Infrastructure as Code<\/h2>\n\n\n\n

Die manuelle Konfiguration von Infrastruktur stellt eine potenzielle Fehlerquelle dar. Aus dieser Motivation hat sich das Konzept der “Infrastructure as Code” etabliert, bei der Infrastruktur in strukturierten Dokumenten formal definiert wird. Die konkrete Umsetzung dieses “Codes” in tats\u00e4chlich bereitgestellte VMs, Datenbanken, usw. wird anschlie\u00dfend von entsprechenden Tools \u00fcbernommen.<\/p>\n\n\n\n

Wir haben uns f\u00fcr das Tool Terraform entschieden, da Terraform einen besonderen Fokus auf Infrastruktur in der Cloud legt. Mit Terraform lie\u00df sich die ben\u00f6tigte Infrastruktur einfach bereitstellen.<\/p>\n\n\n\n

Die Terraform Konfiguration wurde f\u00fcr bessere \u00dcbersicht \u00fcber mehrere Dateien verteilt:<\/p>\n\n\n\n

main.tf<\/h3>\n\n\n\n

Hier ist die Version des Google Provider festgelegt. Au\u00dferdem werden hier Variablen und “Locals” deklariert. Locals unterscheiden sich von Variablen insofern, dass sie w\u00e4hrend der Ausf\u00fchrung von Terraform berechnet werden und nicht von au\u00dfen vorgegeben werden oder Standardwerte haben.<\/p>\n\n\n\n

google.tf<\/h3>\n\n\n\n

Hier befindet sich die Konfiguration f\u00fcr den Google Provider.<\/p>\n\n\n\n

terraform.tfvars<\/h3>\n\n\n\n

Diese Datei erm\u00f6glicht es, Werte f\u00fcr Variablen festzulegen. Die Datei wird automatisch bei Ausf\u00fchrung von Terraform eingelesen. Dadurch spart man sich, alle Variablen \u00fcber die Kommandozeile zu \u00fcbergeben.<\/p>\n\n\n\n

gke.tf<\/h3>\n\n\n\n

Die gr\u00f6\u00dfte Datei enth\u00e4lt die Konfiguration f\u00fcr GKE. Hier wird zum einen das Cluster angelegt, zum anderen ein Node Pool hinzugef\u00fcgt. Der Node Pool legt unter anderem die Art der VM, die f\u00fcr die Nodes verwendet wird, fest.<\/p>\n\n\n\n

cloud_sql.tf<\/h3>\n\n\n\n

Cloud SQL wird mittels dieser Datei provisioniert. Hier werden auch Einstellungen f\u00fcr das Backup und die Redundanz festgelegt.<\/p>\n\n\n\n

vpc.tf<\/h3>\n\n\n\n

Das VPC (Virtual Private Cloud) Netzwerk wird f\u00fcr die interne Kommunikation zwischen den Diensten verwendet. Es wird f\u00fcr die Provisionierung von Compute Ressourcen ben\u00f6tigt.<\/p>\n\n\n\n

outputs.tf<\/h3>\n\n\n\n

In dieser Datei werden die Outputs des Terraform-State angegeben. Diese Outputs k\u00f6nnen dann von anderen Programmen und\/oder weiteren Terraform Konfigurationen verwendet werden. Wir verwenden die Outputs haupts\u00e4chlich f\u00fcr das Shell-Skript. Ausgegeben werden von uns hier zum Beispiel die Projekt ID, die Namen der SQL Instanz und Datenbank, sowie der Name des Clusters. Falls ben\u00f6tigt (das Skript nutzt dies zur Zeit allerdings nicht) werden noch relevante IP Adressen (beispielsweise die der SQL Instanz) ausgegeben.<\/p>\n\n\n\n

Shell Skript<\/h3>\n\n\n\n

F\u00fcr die Konfiguration der Datenbank und das Anwenden der Kubernetes Deployments haben wir ein Shell-Skript verwendet, das mit dem gcloud-CLI und kubectl die ben\u00f6tigten Einstellungen vornimmt. Wir verwenden auf unseren PCs Windows. Eine m\u00f6gliche CI\/CD Pipeline, die die \u00c4nderungen an der Infrastruktur automatisiert anst\u00f6\u00dft, w\u00fcrde jedoch auf Linux basieren. Daher wurde das Skript sowohl f\u00fcr die PowerShell als auch f\u00fcr Bash geschrieben. Die Konfiguration der Datenbank findet hierbei durch das Hochladen eines SQL-Skriptes und einen anschlie\u00dfenden Import in die Cloud SQL Instanz statt.<\/p>\n\n\n\n

Kubernetes Deployment<\/h3>\n\n\n\n

Um die REST API auf unserem Kubernetes Cluster bereitzustellen, verwenden wir ein Kubernetes Deployment. Dieses ist in der Datei “squid-server.k8s.yaml” definiert. <\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Die Felder .metadata.name<\/code>, .metadata.namespace<\/code> und .metadata.labels<\/code> definieren den Namen, den Namespace und Labels f\u00fcr das Deployment.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Im .spec.replicas<\/code> Feld wird angegeben, wie viele Pods das Deployment erzeugen soll. In unserem Fall haben wir angegeben, dass die gew\u00fcnschte Anzahl an Pods 3 sein soll.<\/p>\n\n\n\n

Mit dem .spec.selector<\/code> Feld wird mithilfe von Labels definiert, welche Pods das Deployment managen soll. Das .spec.template<\/code> Feld enth\u00e4lt das Template f\u00fcr die Pods, die erzeugt werden sollen. Dabei m\u00fcssen in dem Template dieselben Labels wie im Selector angegeben werden, damit das Deployment die Pods auch finden kann.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Damit die erzeugten Pods eine Verbindung zu der Cloud SQL Instanz aufbauen d\u00fcrfen, ist im Feld .spec.template.spec.serviceAccountName<\/code> ein von uns erstellter Kubernetes Service Account angegeben, den die Pods verwenden sollen. Im .spec.template.spec.containers<\/code> Feld des Templates werden die Container, die in den Pods laufen sollen, definiert. In unserem Fall sind das zwei Container. Der erste ist das Backend und der zweite ein Cloud SQL Proxy, \u00fcber den sich das Backend mit der Cloud SQL Instanz verbindet.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

F\u00fcr den Backend Container werden au\u00dferdem auch noch vier Umgebungsvariablen gesetzt. Bei der Definition der Umgebungsvariablen m\u00fcssen ein Name und ein Wert angegeben werden. Der Wert f\u00fcr die Umgebungsvariable kann direkt angegeben werden, wie bei der DB_HOST<\/code> Variablen zu sehen ist. Andere M\u00f6glichkeiten, den Wert f\u00fcr eine Umgebungsvariable zu definieren, sind eine ConfigMap oder ein Secret. Dabei werden die Werte als separate Objekte im Kubernetes Cluster verwaltet und k\u00f6nnen dadurch unabh\u00e4ngig vom Deployment ge\u00e4ndert werden.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Die ConfigMap “squid-server-config<\/code>” und das Secret “db-prod-credentials<\/code>” f\u00fcr unser Deployment werden \u00fcber unser Shell-Skript erstellt, bevor das Deployment gemacht wird. Dabei werden in der ConfigMap der Wert f\u00fcr die Variable DB_NAME<\/code> und in dem Secret die Werte f\u00fcr die Variablen DB_USER<\/code> und DB_PWD<\/code> gespeichert.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

In der Definition des Cloud SQL Proxys wird \u00fcber den Befehl, der beim Starten des Containers ausgef\u00fchrt wird, festgelegt, f\u00fcr welche Cloud SQL Instanzen der Proxy sein soll.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

In der Datei “squid-server.k8s.yaml<\/code>” wird au\u00dferdem ein Load Balancer definiert, der Anfragen von au\u00dfen entgegen nimmt und diese an die Pods verteilt.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

In der Datei “service-account.k8s.yaml<\/code>” wird der schon erw\u00e4hnte Kubernetes Service Account definiert. Dieser wird mit der E-Mail Adresse des IAM Service Accounts annotiert. Wenn die im Abschnitt Probleme beschriebenen Schritte zur Einrichtung von Workload Identity durchlaufen wurden, haben die Pods, die den Service Account nutzen, die Berechtigung, auf die Cloud SQL Instanz zuzugreifen.<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n
\"\"<\/a><\/figure>\n\n\n\n

Separat von unserem Deployment wird mit dem Shell-Skript auch noch ein Kubernetes Dashboard auf dem Cluster deployed. Die yaml-Datei f\u00fcr das Deployment kommt dabei von dem GitHub Repository des Kubernetes Dashboards. Um sich bei diesem anmelden zu k\u00f6nnen, muss au\u00dferdem noch ein Admin-Account erstellt werden. Dieser ist in der Datei “admin-account.k8s.yaml<\/code>” definiert.<\/p>\n\n\n\n

Probleme<\/h2>\n\n\n\n

Nach der Erstellung der Terraform-Dateien f\u00fcr die Infrastruktur stellten wir fest, dass die Ersteinrichtung der SQL Datenbank und ein Deployment auf ein Kubernetes Cluster nicht mit  dem Terraform Provider f\u00fcr die Google Cloud m\u00f6glich ist. Als L\u00f6sung hierf\u00fcr haben wir das oben beschriebene Shell-Skript geschrieben.<\/p>\n\n\n\n

Ein weiteres Problem bestand darin, dass die Pods (des Backends) nicht mit der Datenbank kommunizieren durften. Um dieses Problem zu l\u00f6sen, haben wir dem Kubernetes Deployment einen weiteren Container, den Cloud SQL Proxy, hinzugef\u00fcgt, \u00fcber den das Backend auf die Cloud SQL Instanz zugreifen kann. Wir stellten jedoch schnell fest, dass das blo\u00dfe Verwenden des Proxies das zugrundeliegende Berechtigungsproblem nicht l\u00f6st. Um dieses Problem zu l\u00f6sen, mussten wir Workload Identity<\/a> einrichten. Dies wird mit den folgenden drei Befehlen, mit denen ein IAM Service Account erstellt und mit einem Kubernetes Service Account verbunden wird, erreicht.<\/p>\n\n\n\n

\"\"<\/a>
Erstellen des IAM Service Accounts<\/figcaption><\/figure>\n\n\n\n
\"\"<\/a>
Hinzuf\u00fcgen der Cloud SQL Client Rolle zu dem zuvor erstellten IAM Service Account. Hierbei ist der Platzhalter <PROJECT_ID> <\/code>durch die Projekt-ID des Google Cloud Projektes zu ersetzen<\/figcaption><\/figure>\n\n\n\n
\"\"<\/a>
Aktivieren der Verbindung zwischen dem IAM Service Account und dem Kubernetes Service Account<\/figcaption><\/figure>\n\n\n\n

Au\u00dferdem muss die Verwendung von Workload Identity in der Konfiguration des GKE Clusters aktiviert werden. Hierzu haben wir unsere Terraform-Definition des Clusters um folgenden Abschnitt erg\u00e4nzt:<\/p>\n\n\n\n

\"\"<\/a><\/figure>\n\n\n\n

Alternativen<\/h2>\n\n\n\n

Alternativ zu unserem Ansatz, ein Kubernetes Cluster bzw. die Google Kubernetes Engine zu verwenden, h\u00e4tten wir auch eine Serverless-Architektur verwenden k\u00f6nnen. Dabei muss man sich nicht selbst um Infrastruktur k\u00fcmmern und kann sich auf seine Anwendung konzentrieren. Au\u00dferdem bezahlt man hier lediglich pro Anfrage (beziehungsweise f\u00fcr deren Laufzeit) und muss die einzelnen Infrastrukturkomponenten nicht unterhalten. Dazu kann in der Google Cloud z.B. der Cloud Run oder der Cloud Functions Service verwendet werden.<\/p>\n\n\n\n

Eine Alternative zur Google Container Registry (GCR) w\u00e4re die Google Artifact Registry gewesen, welche einige Vorteile gegen\u00fcber der GCR bietet. Zu diesen geh\u00f6rt z.B. dass Berechtigungen nicht nur auf Registry Host Ebene, sondern auch f\u00fcr einzelne Repositories vergeben werden k\u00f6nnen. Au\u00dferdem hat die Artifact Registry eigene IAM Rollen, um Zugriffsberechtigungen zu verwalten. <\/p>\n\n\n\n

Trotz der vielen Vorteile der Artifact Registry haben wir uns dazu entschieden, die Container Registry zu verwenden. Dazu haben wir uns entschieden, da wir die Vorteile der Artifact Registry f\u00fcr unser Projekt nicht ben\u00f6tigt haben und die Container Registry nur minimalen Konfigurationsaufwand ben\u00f6tigt. Au\u00dferdem wollten wir nur ein einziges eigenes Docker Image in der Google Cloud verwenden, weshalb es nicht n\u00f6tig war, Berechtigungen auf Repository Ebene vergeben zu k\u00f6nnen.<\/p>\n\n\n\n

Anstatt mithilfe unseres Shell-Skripts h\u00e4tten wir auch Terraform f\u00fcr die Kubernetes Deployments verwenden k\u00f6nnen. Dies war uns zu Beginn jedoch nicht bewusst, weshalb wir daf\u00fcr auf ein Shell-Skript umgestiegen sind. Da wir allerdings auch lernen wollten, wie man die kubectl-CLI verwendet, um Kubernetes Deployments zu machen, h\u00e4tten wir uns auch mit dem Wissen, dass es mit Terraform doch m\u00f6glich ist, f\u00fcr ein Shell-Skript entschieden.<\/p>\n\n\n\n

Erweiterungen<\/h2>\n\n\n\n

Um das volle Potenzial der Cloudinfrastruktur nutzen zu k\u00f6nnen, sind Erweiterungen und umfangreiche Anpassungen m\u00f6glich.<\/p>\n\n\n\n

Im Moment ist das Backend nur durch HTTP (nicht TLS gesichert) erreichbar. Da das Backend keinerlei Authentifizierung verwendet und lediglich \u00f6ffentlich zug\u00e4ngliche Daten speichert, ist eine Sicherung der \u00dcbertragung mittels TLS auch nicht zwangsl\u00e4ufig notwendig. Da jedoch in manchen Systemen (zum Beispiel f\u00fcr Android Apps) nur Verbindungen \u00fcber HTTPS erlaubt sind, ist eine Verschl\u00fcsselung der Verbindung w\u00fcnschenswert. Durch eine umfangreichere Konfiguration des GKE Clusters kann die Kommunikation mittels HTTPS erm\u00f6glicht werden.<\/p>\n\n\n\n

Da die Verwendung einer klassischen relationalen Datenbank nicht vollst\u00e4ndig mit dem (global) verteilten Modell der Cloud vereinbar ist, kann die Datenbasis des Backends beispielsweise in eine NoSQL-Datenbank oder eine auf verteilte Infrastruktur spezialisierte relationale Datenbank (zum Beispiel Google Spanner) \u00fcberf\u00fchrt werden.<\/p>\n\n\n\n

Lessons Learned<\/h2>\n\n\n\n

W\u00e4hrend unseres Projektes haben wir viel Erfahrung mit Cloud-Diensten der Google Cloud gesammelt. Zu diesen geh\u00f6ren Cloud SQL, Google Kubernetes Engine (GKE), Google Container Registry und Identity and Access Management (IAM). Um unsere Cloudinfrastrukur mittels Infrastruktur als Code zu konfigurieren, haben wir uns au\u00dferdem viel mit Terraform und der Verwendung des Google Cloud SDK (bzw. dem gcloud-CLI) und kubectl-CLI in einem Shell-Skript besch\u00e4ftigt.<\/p>\n","protected":false},"excerpt":{"rendered":"

Im Rahmen der Vorlesung “Software Development f\u00fcr Cloud Computing” haben wir uns zum Ziel gesetzt, eine bereits bestehende REST API in die Cloud zu migrieren.<\/p>\n","protected":false},"author":1092,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[120,262,650],"tags":[7,280,576,154],"ppma_author":[876,1083],"class_list":["post-23412","post","type-post","status-publish","format-standard","hentry","category-cloud-technologies","category-rich-media-systems","category-scalable-systems","tag-cloud","tag-google-cloud","tag-infrastructure-as-code","tag-kubernetes"],"aioseo_notices":[],"jetpack_featured_media_url":"","jetpack-related-posts":[{"id":21163,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/09\/15\/cloud-basierter-password-manager\/","url_meta":{"origin":23412,"position":0},"title":"Cloud basierter Password Manager","author":"bs103","date":"15. September 2021","format":false,"excerpt":"von Benjamin Schweizer (bs103) und Max Eichinger (me110) Abstract K\u00f6nnen Passwort Manager Anbieter meine Passw\u00f6rter lesen? Wir wollten auf Nummer sichergehen und haben unseren Eigenen entwickelt. Dieser Artikel zeigt auf welche Schritte wir hierf\u00fcr unternehmen mussten.Dabei haben wir unser Frontend mittels Flutter und unser Backend in AWS umgesetzt. Au\u00dferdem gehen\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image0-4-150x150.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image0-4-150x150.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image0-4-150x150.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image0-4-150x150.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/image0-4-150x150.png?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":23579,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2022\/08\/30\/google-geodata-visualizer\/","url_meta":{"origin":23412,"position":1},"title":"Google Geodata Visualizer","author":"sk331","date":"30. August 2022","format":false,"excerpt":"Ein Projekt von Kai Kustermann, Michael Litschko, Sarah Mauff und Sebastian K\u00f6pp Einleitung Im Sommersemester 2022 haben wir uns als 4-k\u00f6pfige Gruppe dazu entschlossen, einen Google Geodata Visualizer zu erstellen. Das Projekt ist aus der Idee einer McDonald\u2019s-Achievement-Card entstanden. Die Idee war eine Website, die dem Benutzer anzeigt, welche McDonald\u2019s\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2022\/08\/16.png?resize=350%2C200&ssl=1","width":350,"height":200},"classes":[]},{"id":21683,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2021\/09\/18\/ynstagram-cloud-computing-mit-aws-serverless\/","url_meta":{"origin":23412,"position":2},"title":"Ynstagram – Cloud Computing mit AWS & Serverless","author":"ns144","date":"18. September 2021","format":false,"excerpt":"Im Rahmen der Vorlesung \u201cSoftware Development for Cloud Computing\u201d haben wir uns hinsichtlich des dortigen Semesterprojektes zum Ziel gesetzt einen einfachen Instagram Klon zu entwerfen um uns die Grundkenntnisse des Cloud Computings anzueignen. Grundkonzeption \/ Ziele des Projektes Da wir bereits einige Erfahrung mit React aufgrund anderer studentischer Projekte sammeln\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2021\/09\/Prasentation_CC_01.png?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":28011,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2025\/09\/11\/cloud-native-security-scanner\/","url_meta":{"origin":23412,"position":3},"title":"Cloud-native Security Scanner","author":"Tim Ruff","date":"11. September 2025","format":false,"excerpt":"Dieses Projekt wurde im Rahmen der Vorlesung \u201eSoftware Development for Cloud Computing\u201c umgesetzt. Ausgangslage und Projektidee Unser bisheriger Fokus im Studium lag haupts\u00e4chlich auf Themen der IT-Security und Machine Learning, weshalb wir beide bis auf die grundlegenden Vorlesungen zum Thema Software Entwicklung kaum Erfahrungen in diesem Bereich gesammelt haben. Aus\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image.jpeg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image.jpeg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image.jpeg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image.jpeg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2025\/09\/image.jpeg?resize=1050%2C600&ssl=1 3x"},"classes":[]},{"id":25800,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2023\/09\/14\/splid-2-0-die-zukunft-des-gemeinsamen-ausgabenmanagements\/","url_meta":{"origin":23412,"position":4},"title":"Splid 2.0 – Die Zukunft des gemeinsamen Ausgabenmanagements","author":"David Christoph Scheifers","date":"14. September 2023","format":false,"excerpt":"Im Rahmen der Vorlesung \u201cSoftware Development for Cloud Computing\u201d haben wir uns daf\u00fcr entschieden, einen Klon der App Splid auf Basis unterschiedlicher Cloud Technologien als Web App zu entwickeln, um uns so die Grundkenntnisse des Cloud Computings anzueignen. Projektidee Bei gemeinsamen Aktivit\u00e4ten und Gruppenausgaben ist es sehr hilfreich, einfache und\u2026","rel":"","context":"In "Allgemein"","block_context":{"text":"Allgemein","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/allgemein\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=350%2C200&ssl=1","width":350,"height":200,"srcset":"https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=350%2C200&ssl=1 1x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=525%2C300&ssl=1 1.5x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=700%2C400&ssl=1 2x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=1050%2C600&ssl=1 3x, https:\/\/i0.wp.com\/blog.mi.hdm-stuttgart.de\/wp-content\/uploads\/2023\/09\/image6.jpg?resize=1400%2C800&ssl=1 4x"},"classes":[]},{"id":12032,"url":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/2020\/09\/30\/admin-panel-web-app-in-der-aws-cloud\/","url_meta":{"origin":23412,"position":5},"title":"Admin Panel (Web App) in der AWS Cloud","author":"ss447","date":"30. September 2020","format":false,"excerpt":"1. Einleitung Im Rahmen der Vorlesung \u201eSoftware Development for Cloud Computing\u201c haben wir uns als Gruppe dazu entschieden aufbauend auf teilweise bereits vorhandener Codebasis an einem Startup-Projekt weiterzuarbeiten. Der Hauptfokus lag bei uns auf dem Ausbau von DevOps-Aspekten und auf dem eines stabilen und sicheren Systems, welches auch in der\u2026","rel":"","context":"In "Cloud Technologies"","block_context":{"text":"Cloud Technologies","link":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/category\/scalable-systems\/cloud-technologies\/"},"img":{"alt_text":"","src":"https:\/\/i0.wp.com\/img.youtube.com\/vi\/qw9ZkWnvR4M\/0.jpg?resize=350%2C200","width":350,"height":200},"classes":[]}],"jetpack_sharing_enabled":true,"authors":[{"term_id":876,"user_id":1092,"is_guest":0,"slug":"rk085","display_name":"Raphael Kienh\u00f6fer","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/c690eaca707792cf8b7ef56302990385c4d9f683ae3530f135107134a00f89ab?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""},{"term_id":1083,"user_id":1247,"is_guest":0,"slug":"cedric_gottschalk","display_name":"Cedric Gottschalk","avatar_url":"https:\/\/secure.gravatar.com\/avatar\/472d26ded7606fb8380c1f434241072814d874082d94097668be7def3acbce3b?s=96&d=mm&r=g","0":null,"1":"","2":"","3":"","4":"","5":"","6":"","7":"","8":""}],"_links":{"self":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/23412","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/users\/1092"}],"replies":[{"embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/comments?post=23412"}],"version-history":[{"count":18,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/23412\/revisions"}],"predecessor-version":[{"id":23527,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/posts\/23412\/revisions\/23527"}],"wp:attachment":[{"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/media?parent=23412"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/categories?post=23412"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/tags?post=23412"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/blog.mi.hdm-stuttgart.de\/index.php\/wp-json\/wp\/v2\/ppma_author?post=23412"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}