Nach meinem Artikel "Cloud - Pizza as a Service: Was hat eigentlich "Pizza" mit Cloud Services zu tun?" gehe ich in diesem Beitrag auf die "Cloud Basics" ein. Hierbei handelt es sich um Werkzeuge und Methoden, welche vor einer möglichen Umsetzung / Einführung / Migration unbedingt bekannt sein sollten.
CI/CD (Continuous Integration/Continuous Delivery)
Release early, release often - Mit Hilfe der CI/CD-Pipelines, welche in einem agilen Softwareprojekt zwingend erforderlich sind, welche den Prozess des fortlaufenden Zusammenfügens von Komponenten hin zu einer Anwendung garantieren, müssen Änderungen am Quellcode bzw. neue Funktionen nicht mehr bis zum nächsten großen Release gesammelt werden. Siehe auch "Agile Softwareentwicklung - GitHub Flow notwendig?".
Änderungen am Quellcode, die in der Versionsverwaltung eingecheckt werden, können sofort automatisch von Skripten getestet (siehe auch Softwaretest bei agiler Entwicklung durch Testautomatisierung) und zu einem auslieferungsfähigen Paket verpackt werden.
Die Tools der Wahl sind hier zum Beispiel Jenkins (build, test, and deploy their software) oder GitHub Actions, GitLab (end-to-end software development platform with built-in version control, issue tracking, code review), Maven (build automation tool used primarily for Java projects) und Nexus (software repository manager).
Cloud-Native
Entwickler bezeichnen Software als Cloud-Native, welche die Vorteile der Cloud im eigenen Rechenzentrum (Flexibilität, Skalierbarkeit und Reproduzierbarkeit) bieten. Die Software ist daher in der Regel für den Betrieb in Containern (Raspberry Pi - Docker installieren) optimiert und kann somit auf eigenen oder auf gemieteten Servern laufen.
Container
Hier erfolgt eine Isolierung von Anwendungen mit Hilfe von Containervirtualisierung (siehe z.B. Raspberry Pi - Docker Compose installieren). Sie nutzen den Kernel des darunterliegenden Betriebssystems und blockieren somit keinen Arbeitsspeicher und haben nur eine sehr geringe Bootzeit. Alle Abhängigkeiten sind enthalten, dadurch lassen sich Container schnell starten, vervielfältigen, auf anderen Servern oder auch ganze Rechenzentren übertragen.
DevOps
Die Entwickler und der Betrieb / Service einer Software (Development und Operations) werden bei diesem Modell nicht hart getrennt, sondern arbeiten eng miteinander zusammen. Flexible Mietserver und Konzepte aus dem Cloudumfeld (zum Beispiel CI/CD) unterstützen dabei, die DevOps Methoden umzusetzen.
Hybrid
In der Regel wird nicht die komplette Serverinfrastruktur eines vorhandenen Rechenzentrums durch Cloud-Infrastruktur ersetzt. Dies ist vor allem der Fall, wenn es um besonders sensible Daten geht. Die lokale Software sollte aber idealerweise "Cloud-Native" sein, damit Hybride Strategien gut funktionieren. Die restliche Software kann dann in der flexiblen Public Cloud betrieben werden.
laaS (Infrastructure as a Service)
Hierbei handelt es sich eigentlich um Marketing Kreation der Cloud Anbieter. Hierbei kann man Angebote oder Dienste zum Minutenpreis mieten, oft auch Platform as a Service (PaaS) genannt.
Infrastructure as Code
Die Infrastruktur lässt sich immer wieder neu einrichten. Die jeweils gewünschte Konfiguration wird z.B. in Dateien mit YAML-Format beschrieben. Mit Hilfe von
Terraform oder
Ansible erfolgt dann die Umsetzung im Cloud-Umfeld.
Public Cloud & Private Cloud
Siehe hierzu auch "Hybrid" Beschreibung oben, Public Cloud sind Angebote für flexibel abgerechnete Server und weitere Dienstleistungen. Private Cloud sind eigene physische Server, welche zum Beispiel mit der Software
Open Stack verwaltet werden.
Unternehmen, die idealerweise mit cloud-nativen Tools arbeiten, haben sie die Möglichkeit ihre Dienste jederzeit aus der "Private Cloud" in eine "Pubilc Cloud" zu migrieren.
Semantic Versioning
Es handelt sich um eine Standardisierung der Software-Versionierung. Sie besteht aus drei Zahlen (1.3.08) besteht: Die major version (1), minor version (3) und patch version (08). Siehe auch
https://semver.org/lang/de/.
SaaS (Software as a Service)
Analog zu IaaS, Software wird zum Monatspreis an Kunden vermietet. Man muss sich nicht um die Administration, Updates oder Backups der Software kümmern. In der Regel laufen die Anwendungen auf Cloud-Infrastruktur wie zum Beispiel
Amazon (aws).
Vendor Lock-in
Beschreibt die Befürchtung, dass man mit der Entscheidung für eine Software oder Service im Dienstleisteruniversum eingesperrt ist. Dies kann man mit der Verwendung von Open-Source-Software aus dem Cloud-Native-Umfeld umgehen. Als Beispiel ist hier
Kubernetes als Plattform für seine Container und eigenen Betrieb von Open-Source-Software selbst genannt.
