Sie würden gerne wissen, wie Sie die Open Telekom Cloud von T-Systems (IaaS – Infrastructure as a Service) künftig für Ihre Workloads nutzen können? Und wie Sie Ihre bestehenden Workloads von einer anderen Infrastruktur wie AWS zur Open Telekom Cloud migrieren können?

Dieser Artikel ist Teil einer Serie und beschreibt die allgemeinen Grundlagen und Vorteile von Scale-out-Cloud-Infrastrukturen. Zudem erfahren Sie mehr über wichtige Unterscheidungsmerkmale (wie Service Level Agreements bzw. SLAs) von physischen und virtuellen Infrastrukturen („Legacy on Premise“ oder „Enterprise Cloud“). Wir gehen außerdem darauf ein, wie sich virtuelle Maschinen und Services in der Open Telekom Cloud nutzen lassen und welche Aspekte im Hinblick auf die Sicherheit und automatisierte Bereitstellung von Relevanz sind.

Wir werden jede Woche einen neuen Artikel in dieser Reihe auf unserem Blog veröffentlichen – schauen Sie einfach rein:

• Im nächsten Beitrag geht es darum, wie sich VMs in der Open Telekom Cloud nutzen lassen.
• Im dritten Teil gehen wir auf die Nutzung der Open Telekom Cloud in Test- und Entwicklungsumgebungen ein.
• Im vierten Teil zeigen wir Ihnen, wie ein Internetauftritt auf Basis der Open Telekom Cloud implementiert wird.
• Im (vorerst) letzten Teil erfahren Sie, wie sich Anwendungen erfolgreich von anderen Scale-out-Cloud-Plattformen migrieren lassen (z. B. Amazon AWS).

In dieser Beitragsserie geht es in erster Linie um allgemeine technische Überlegungen und die Vorteile der Open Telekom Cloud im Hinblick auf die effiziente Nutzung von Anwendungen. Projekte zur Umsetzung einer Cloud-Infrastruktur bestehen in der Regel aus mehreren Phasen und bringen verschiedene Herausforderungen mit sich. Beispielsweise müssen zunächst die Geschäftsanforderungen analysiert und Anwendungen ggf. so angepasst werden, dass diese sich gut in eine Public-Cloud-Lösung migrieren lassen. Zusätzlich dazu spielen auch organisatorische Änderungen und natürlich die Kosten eine wichtige Rolle. Da diese Aspekte von Fall zu Fall sehr unterschiedlich und komplex ausfallen können, werden wir auf diese im vorliegenden Blog nicht näher eingehen.

Bislang hatten Sie vermutlich eher mit privaten (unternehmensspezifischen) Cloud-Lösungen oder On-Premise-Lösungen zu tun. Vor der Einführung der Open Telekom Cloud sollten Sie sich daher zunächst mit Public-Cloud-Lösungen vertraut machen, die in der Regel auf „On-Demand“- oder „Pay-per-Use“-Modellen basieren. Sie müssen erst die grundlegende Architektur von Public-Cloud-Lösungen verstehen und welche Auswirkungen dies auf die verwendeten Anwendungen hat.

Die verschiedenen Anwendungsfälle der Open Telekom Cloud dienen als Orientierungshilfe für den nächsten Schritt – die Ermittlung der idealen Anwendungen für die Open Telekom Cloud. Sie sollten alle Anwendungen hinsichtlich ihrer Verfügbarkeitsanforderungen, Scale-out-Design, rechtlichen Vereinbarungen/SLAs sowie im Hinblick auf ihre Anpassungsfähigkeit bewerten.

Die folgende Grafik bietet eine Übersicht über diesen Bewertungsprozess:

Sobald die Anwendungen und zugehörigen Anwendungsfälle identifiziert wurden, geht es im nächsten Schritt darum, die Anwendungen entsprechend anzupassen. Bestimmte Funktionen können durch Plattformservices oder skalierbare Open-Source-Standardbausteine ersetzt werden. Die Plattformservices der Open Telekom Cloud müssen ausgewählt und perfekt auf die jeweilige Anwendung abgestimmt werden. Auf diese Weise stellen Sie die erforderliche Verfügbarkeit und Resilienz Ihrer Anwendungen sicher.

Im Anschluss an die Anpassung der Anwendung und die Einführung der Plattformservices folgt eine umfassende Prüfung. Diese Prüfung sollte weitestgehend automatisiert erfolgen (eventuell ist hier auch eine testgetriebene Entwicklung sinnvoll). Um die erforderliche Serviceverfügbarkeit der Anwendung sicherzustellen, sollten Sie in den Tests ein besonderes Augenmerk auf Ausfälle von Plattforminstanzen legen, da diese gerade bei Public-Cloud-Lösungen eine wichtige Rolle spielen („Chaos Monkey“ von Netflix ist ein gutes Beispiel hierfür). Das Monitoring der Serviceverfügbarkeit ist demzufolge wichtiger als die Zustandsüberwachung von virtuellen Maschinen. Um Ihre Anwendungen robuster zu machen, sollten Sie Ihren Schwerpunkt daher eher auf Ausfälle von Plattforminstanzen legen.

Neben dem Test der Anwendung muss auch die Übertragung der Anwendungsdaten auf die Open Telekom Cloud geplant werden, was je nach Datenmenge eine große Herausforderung darstellen kann. Zu diesem Zweck wurde zusammen mit der Open Telekom Cloud auch „Bandwidth as a Service“ eingeführt. Bei einem Wechsel hin zu einer Public Cloud müssen auch betriebliche Prozesse entsprechend angepasst werden. Dabei bleibt es Ihnen überlassen, ob Managed Services oder selbst entwickelte und betriebene DevOps besser zum Betriebsmodell der Anwendung und des Unternehmens passen.

Der nächste wichtige Schritt besteht darin, den Paradigmenwechsel zu verstehen, der sich im Bereich IT-Outsourcing immer stärker abzeichnet – lokal installierte Legacy-Anwendungen werden in zunehmendem Maße durch Cloud-Lösungen ersetzt, die sich durch flexible „Pay-as-you-Go“-, „On-Demand“-, „Scale-out“- und „Commodity“-Modelle auszeichnen.

Kurzum:

Flexible Cloud-Computing-Lösungen basieren auf einer kostengünstigeren Scale-out-Standardhardware. Allerdings ist dadurch die Verfügbarkeit auf Infrastrukturebene etwas geringer als bei Legacy-Ansätzen für IT-Outsourcing, die in der Regel auf eine kostenintensive Aufrüstung der IT-Infrastruktur setzen. Die Serviceverfügbarkeit wird somit zu einer Frage der Anwendung anstatt der Infrastrukturebene. Anstelle eines „Scale-up“ ist somit ein „Scale-out“ Ihrer Anwendung erforderlich, wenn größere Rechner-/Netzwerk-/Speicherkapazitäten benötigt und (üblichere) Infrastrukturausfälle überbrückt werden sollen.

Einige Hintergrundinfos:

Die Public Cloud oder auch Scale-out-Cloud-Architektur basiert auf anderen Paradigmen als derzeit eingesetzte Infrastrukturen. Kluge Köpfe haben Jahrzehnte damit verbracht, die Infrastruktur (Hardware, Hypervisors, Betriebssysteme etc.) zuverlässiger zu machen. Dem sind jedoch auch Grenzen gesetzt. Eine Steigerung der Verfügbarkeit auf über 99,999 % führt zu einer immer höheren Komplexität sowie zu immensen Kosten. Andererseits bringt die Erweiterung der Standardinfrastruktur enorme Skaleneffekte mit sich und Scale-out-Lösungen führen zu einem kompletten Perspektivenwechsel: Was wäre, wenn man zuverlässige Services auf einer nur mäßig zuverlässigen (d. h. standardmäßigen) Infrastruktur bereitstellen könnte? Die Antwort: Die Serviceverfügbarkeit ist das Einzige, was zählt!

In den letzten zehn Jahren ist kamen neue Paradigmen für Scale-out-Cloud-Architekturen auf, mit denen sich höchst zuverlässige und flexible Services viel kostengünstiger bereitstellen lassen.

In diesem Abschnitt werden die wichtigsten Konzepte für Scale-out-Cloud-Architekturen im Hinblick auf die Open Telekom Cloud vorgestellt. Diese Prinzipien sind nicht von der jeweiligen Cloud-Lösung abhängig, auf der sie basieren. Neben der Open Telekom Cloud gelten sie auch für andere Clouds auf OpenStack-Basis oder Scale-out-Cloud-Lösungen wie AWS.

Physische Server sind eine kostspielige und langwierige Anschaffung. Durch sorgfältige Konfiguration und Wartung sowie umfassende Änderungs- und Updatemanagementsysteme muss außerdem sichergestellt werden, dass der Server stets produktiv arbeitet. Bei einer großen Anzahl an Servern kommen hierfür in der Regel Enterprise-Management-Systeme zum Einsatz, die einen umfassenden Überblick über den Zustand und die Konfiguration der Maschinen bieten und gleichzeitig sicherstellen, dass die Server ordnungsgemäß arbeiten. Wenn Sie mit virtuellen Servern arbeiten, verwenden Sie vielleicht ein Enterprise Virtualization Management System (oder „Enterprise Cloud“). Die Betrachtungsweise der Server bleibt dabei grundlegend gleich. Randy Bias hat einmal treffend gesagt, dass Server bei dieser Art der Nutzung „wie Haustiere (Pets) behandelt werden“.
Was wäre jedoch, wenn es zahlreiche VMs gäbe, die quasi ohne Aufwand erstellt und gelöscht werden können? Würde sich dann etwas an der Nutzungsweise ändern? Durch Scale-out-Lösungen (Public Clouds) hat sich dieses Modell verändert. Es geht nicht mehr nur um einzelne VMs, sondern VMs werden ganz einfach nach Bedarf erstellt und entfernt. Hierbei handelt es sich um den so genannten „Cattle-Ansatz“ für die Verwaltung von VMs. Solange die Gesamtheit der Instanzen intakt und funktionsfähig ist, spielt die Funktionalität einer einzelnen Instanz nur eine untergeordnete Rolle.
Um dieses Paradigma verständlicher zu machen, bietet sich eine Betrachtung unter unterschiedlichen Gesichtspunkten an, wie z. B. modulares Scale-out-Design, Zustand und Zustandslosigkeit, automatisierte Konfiguration sowie Fehlerdomains. Diese schauen wir uns im Folgenden etwas genauer an.

Im Scale-out-Design werden Tasks und Jobs in der Regel in so genannte Mikroservices aufgeschlüsselt, die skalierfähig sind und von einer (häufig auf REST basierenden) API verwendet werden können. Wenn ein auf einer bestimmten VM laufender Service die Anforderungen nicht erfüllen kann, können weitere VMs gestartet werden und einen Teil der Last übernehmen. Hierbei handelt es sich um eine servicegesteuerte Architektur: Services kommunizieren mit zugrundeliegenden Services und bewältigen etwaige Ausfälle durch erneutes Verbinden nach einem kurzen Timeout. Durch eine Skalierungslogik für Anwendungen wird sichergestellt, dass der Zustand des betreffenden Service (und nicht der Maschinen!) überwacht wird und im Bedarfsfall weitere VMs hinzugeschaltet werden (Auto Scaling).

Wenn VMs kommen und gehen, sind sie nicht der geeignete Ort zum Speichern von Zuständen. Eine VM kann jederzeit das Zeitliche segnen, wie Netflix dies im berühmten Post „Chaos Monkey“ beschreibt: Instanzausfälle treten häufig auf. Die Stabilität einer Cloud-Anwendung kommt dadurch zustande, dass sie den Ausfall einer VM ohne jeglichen Datenverlust übersteht. Denn wenn die VM keinen beständigen Zustand hat, können auch keine Daten verloren gehen.
Bei ‚Amazon Web Services‘ sind die Root-Festplatten der meisten Instanztypen (Flavors) flüchtig. Bei einem Neustart sind sie wieder nicht zugeordnet. Dies spricht für ein Modell, bei dem keine Persistenzschichten in den Root-Dateisystemen einer VM angelegt werden. In der Open Telekom Cloud sind die Root-Festplatten zwar standardmäßig persistent, um den Wechsel von einem herkömmlichen System zu erleichtern, aber sie sollten eher wie nicht persistente Systeme behandelt werden. Bei einer langfristigen Speicherung der Daten einer VM müssen diese an einem Ort abgelegt werden, der nicht ausschließlich der VM gehört: eine Datenbank, ein Objekt in einem Objektspeicher oder (falls dies unvermeidlich ist) eine Daten-Festplatte, die zu diesem Zweck an die VM angeschlossen ist. Der große Vorteil einer zustandslosen VM ist, dass bei einem Ausfall, Absturz oder bei einer Migration im ausgeschalteten Zustand keine persistenten Daten verloren gehen können. Die Konfiguration einer zustandslosen VM muss im Image gespeichert oder besser noch beim Hochfahren von außen eingefügt werden. Damit werden wir uns im nächsten Abschnitt beschäftigen.

Anstatt ein Image zu erstellen, in dem alle erforderlichen Konfigurationen bereits enthalten sind (was außerdem eine Image-Verteilung notwendig macht), besteht eine bewährte Praxis in Scale-out-Lösungen darin, eine geringe Anzahl an generischen Images zu verwenden und die Konfiguration beim Start einzufügen.
Unter Linux hat sich Cloud-Init zum Standardtool für die Konfiguration und Anpassung beim Hochfahren entwickelt. Cloud-Init liest eine „YAML“-Konfigurationsdatei (in das Boot-System) ein und bezieht weitere Metadaten von externen Datenquellen in OpenStack-Umgebungen. Cloud-Init setzt sich aus Dutzenden Modulen zusammen, die beispielsweise dazu in der Lage sind, Hostnamen zu vergeben, Updates oder zusätzliche Pakete zu installieren, die Größe der Root-Partition und des Root-Dateisystems zu ändern (um die Platte zu füllen), Passwörter zu vergeben sowie autorisierte SSH-Schlüssel einzufügen. Zusätzlich dazu können diese Module auch eine Verbindung zu einem kompletten Konfigurationsmanagementsystem wie Chef, Puppet, Saltstack oder Ansible herstellen. Einfache Prozesse wie das Einfügen von Dateien oder die Ausführung von Skripts sind mit dem Tool ebenfalls möglich. Auf diese Weise wird das generische Image beim Start konfiguriert (bei kurzlebigen Root-Platten bei jedem Start, bei persistenten Root-Platten nur beim ersten Hochfahren), um eine maßgeschneiderte VM für den auszuführenden Task zu erstellen.

In der Regel ist es sehr aufwändig, Services so umzustrukturieren, dass sie Ausfälle skalieren und tolerieren. Glücklicherweise gab es die Open-Source-Bewegung bereits vor dem Aufkommen von Scale-out-Cloud-Lösungen. Es gibt zahlreiche gute Open-Source-Lösungen, die als Bausteine verwendet werden können. Genauso wie in den von der Cloud genutzten Standardinfrastrukturen sind auch hier Standardbausteine verfügbar, wie z. B. für Schlüsselwertspeicher, Nicht-SQL-Datenbanken, Konfigurationsmanagementsysteme, Systeme für Codemanagement und CI/CD-Systeme, Benachrichtigungsplattformen usw.

Wurde ein Service identifiziert, der Teil eines Anwendungsdesigns ist, werden folgende Schritte empfohlen:

• Gibt es einen Service auf der Plattform (wie z. B. Object Storage, RDS etc.), der die Anforderungen erfüllt?
• st das SLA umfassend genug und der Lock-in-Effekt gerechtfertigt? Falls ja, sollten Sie diesen nutzen.
• Gibt es ein Unternehmen, das Software mit ähnlichen Anforderungen zu entwickeln hatte und diese veröffentlicht hat? Vielleicht sogar als Open Source? Oder vielleicht lassen sich hier zumindest wertvolle Erkenntnisse ableiten?

Systeme lassen sich nicht auf die Schnelle skalieren und wiederherstellen, wenn hierfür manuelle Eingriffe erforderlich sind. In der Regel müssen manuelle Arbeitsprozesse nur selten zweimal ausgeführt werden. In der Cloud kommen Tools zum Einsatz, um Bereitstellungen, Wiederherstellungen und Skalierungen zu automatisieren. Einige Tools werden sehr oft für diese Zwecke eingesetzt. Scale-out-Cloud-Umgebungen sind mit einer API ausgestattet. Über diese APIs lassen sich virtuelle Netzwerke, virtuelle Speicher sowie virtuelle Maschinen erstellen. APIs sind in der Regel einfache REST-Schnittstellen, über die Sie mithilfe von einfachen Tools Anforderungen erstellen und die Antworten von einem Cloud-Service analysieren können. Wahrscheinlich haben Sie auch schon von übergeordneten Abstraktionstools wie „Terraform“ gehört (CloudFormation von AWS bzw. HEAT von OpenStack).
Zusätzlich zu den API-Tools kommen wahrscheinlich auch Konfigurationsmanagementsysteme wie Chef, Ansible, Puppet oder Saltstack zum Einsatz, um Deployments zu automatisieren und Ihre IT-Umgebung zu warten.

Einige Ereignisse wirken sich nicht nur auf einen einzigen Host oder ein Rack aus, sondern können im ungünstigsten Fall auch dazu führen, dass ein komplettes Rechenzentrum ausfällt oder in Rauch aufgeht. Obwohl native Cloud-Anwendungen im Allgemeinen gut mit Ausfällen umgehen können, stellt dies dennoch eine besondere Herausforderung dar: Sollten alle für einen Service erforderlichen Maschinen auf einmal ausfallen, kommt es zu einer hoffentlich nur kurzen Serviceunterbrechung, die solange andauert, bis neue VMs hochgefahren sind und den Service übernehmen. Durch das Konzept der Availability Zones kann diese Situation vermieden werden. Die Cloud ist über mehrere verschiedene Rechenzentren angelegt, die unabhängig voneinander versorgt werden und mit dem Netz verbunden sind. Auf diese Weise ist es relativ unwahrscheinlich, dass alle Rechenzentren gleichzeitig von einem schwerwiegenden Ereignis betroffen sind. Anwendungen sind auf die jeweilige Availability Zone ausgerichtet. Sehr resilient angelegte Anwendungen replizieren persistente Daten über mehrere AZs und überstehen auf diese Weise den Ausfall einer AZ ohne Serviceunterbrechung.
In diesem Zusammenhang spielt die Definition der Verfügbarkeit (gemäß SLA) einer Scale-out-Cloud-Lösung eine wichtige Rolle: Bei Standardkomponenten gelten nur eingeschränkte Garantien auf die betreffende Hardware. Die Steuerung der Cloud ist zwar redundant abgesichert, bei Rechen-Hosts ist das allerdings nicht der Fall. Von einem Ausfall sind damit auch alle VMs betroffen. In einer Scale-out-Cloud-Lösung ist es keine Seltenheit, dass VMs ausfallen und gelöscht werden. Wenn die Anwendung nicht darauf ausgelegt ist, ist eine Verfügbarkeit von mehr als 99 % nicht möglich. Anwendungen nach dem Scale-out-Prinzip starten die VM einfach wieder an anderer Stelle. Da sie zustandslos ist, gehen dabei auch keine Daten verloren.
Das SLA (bei der Open Telekom Cloud derzeit 99,95 %) garantiert, dass Funktionsstörungen nur in einer Availability Zone auftreten. Anwendungen, die Services mit einer Verfügbarkeit von 99,95 % bereitstellen sollen, müssen die erforderlichen Daten damit in zwei Zonen replizieren. 

Beim Monitoring sollte der Fokus nicht auf den VMs liegen. Denn wie bereits angesprochen, fallen VMs relativ häufig aus, was jedoch kein Grund zur Beunruhigung sein muss. Bei Cloud-Anwendungen liegt der Schwerpunkt auf den Services, also müssen diese überwacht werden. Bei guten Cloud-Anwendungen sind auf jeder Ebene entsprechende Werkzeuge integriert (zur Überwachung der Verfügbarkeit, Antwortzeit bzw. Auslastung), die die Skalierung und den Zustand der Anwendung direkt steuern. Letztendlich kommt es darauf an, dass der Service für den Endnutzer verfügbar ist – und um dies sicherzustellen, müssen unbedingt Services eingesetzt werden, die außerhalb der Cloud laufen. Im Netz sind solche Services verfügbar.

Wenn eine Anwendung so angelegt ist, dass die damit bereitgestellten Services überwacht werden können, so lassen sich damit automatisierte Aktionen realisieren. Wenn die Auslastung für einen Service zu groß wird, können neue virtuelle Maschinen gestartet werden, um zusätzliche Kapazitäten bereitzustellen (Scale-out). Analog können zusätzliche VMs wieder entfernt werden, wenn die Auslastung über einen gewissen Zeitraum niedrig bleibt (Scale-in). Dieser Mechanismus ist auch bei einem Ausfall von VMs hilfreich – auch hier werden ausgefallene VMs nach dem Scale-Out-Prinzip ersetzt. In Scale-out-Anwendungen spielt sich häufig folgendes Szenario ab: Es gibt einen Load Balancer, der Anfragen von einer anderen Ebene an einen Service weitergibt. Die Open-Telekom-Cloud-Plattform beinhaltet einen Mechanismus, bei dem Sie ein benutzerdefiniertes Image für die VMs zu einem Service erstellen. Die VMs werden in einer „Auto Scaling“-Gruppe zusammengefasst und hinsichtlich Antwortzeiten (http oder tcp) bzw. VM-Metriken (CPU-Auslastung usw.) überwacht. Der Nutzer kann Regeln festlegen, sodass automatische Maßnahmen getroffen werden, wenn bestimmte Schwellenwerte für einen gewissen Zeitraum überschritten werden. Werden neue VMs bereitgestellt (Scale-out), werden diese automatisch zum zugehörigen Load Balancer hinzugefügt. Beim Scale-in gilt dasselbe Prinzip. Diese „Auto Scaling“-Gruppen sind ein äußerst einfaches und praktisches Hilfsmittel für die Skalierung, da bei den meisten Webanwendungen hierfür keine grundlegenden Änderungen erforderlich sind.

Zusätzlich zu individuellen Anwendungstests müssen die folgenden beiden Funktionen validiert werden:

• automatische Skalierung
• Wiederherstellung von ausgefallenen VMs

Ein hervorragendes Tool zum Testen der Wiederherstellung von VMs ist der berühmte Chaos Monkey, der von Adrian Cockroft von Netflix ins Leben gerufen wurde. Netflix erkannte, dass man häufige Ausfälle von VMs in einer Public Cloud nur dann effizient handhaben kann, wenn man diese als ein normales Ereignis ansieht. Zu diesem Zweck wurde das Tool Chaos Monkey programmiert und (als Open Source) veröffentlicht. Das Tool entfernt VMs in einer Auto Scaling-Gruppe nach dem Zufallsprinzip. Bei Netflix läuft Chaos Monkey während der Geschäftszeiten (!) auf dem Produktivsystem (!!) und überwacht die geforderte Stabilität der Anwendung.

Die meisten Cloud-Anwendungen werden nach dem Prinzip der agilen Softwareentwicklung programmiert. Der Code wird kontinuierlich erstellt (CI – Continuous Integration) und sehr häufig in Testumgebungen bereitgestellt (CD – Continuous Deployment). Wöchentliche Bereitstellungen in der Produktivumgebung sind dabei auch keine Seltenheit. Der Bereitstellungsprozess an sich ist Teil der Entwicklung. Die Entwicklungs- und Betriebsteams sind beide daran beteiligt und tragen gemeinsam Sorge dafür, dass sowohl die Bereitstellung wie auch der Betrieb einwandfrei funktionieren. In diesem Zusammenhang erweist es sich als sehr vorteilhaft, die ursprüngliche Trennung zwischen Entwicklung und Betrieb über Bord zu werfen. Vielmehr müssen die beiden Bereiche im Rahmen von so genannten DevOps enger miteinander zusammenarbeiten. Schwerfällige Änderungsprozesse, bei denen Änderungen weitestgehend vermieden werden, sind heute einfach nicht mehr zeitgemäß. Softwaretests und Validierungsprozesse werden stattdessen zunehmend automatisiert, genauso wie Bereitstellungs- und Änderungsprozesse. Sollte sich doch einmal ein Fehler einschleichen, kann die vorherige Version mithilfe eines Rollbacks schnell wiederhergestellt werden.

Wie bereits zu Beginn dieses Artikels erwähnt, wird es im nächsten Beitrag darum gehen, wie sich VMs in der Open Telekom Cloud effizient nutzen lassen. Außerdem werden wir uns näher damit beschäftigen, was es mit den strukturellen Elementen der Open Telekom Cloud auf sich hat, wie diese funktionieren und wie sie miteinander verknüpft sind. Sie erfahren auch mehr über die Nutzung von Betriebssystem-Images – sowohl von bereits in der Cloud vorhandenen, öffentlichen Images als auch von Images, die Sie selbst angelegt und in die Cloud hochgeladen haben.

Open-Telekom-Cloud-Dokumentationszentrum: https://docs.otc.t-systems.com/
Weitere Artikel im Open-Telekom-Cloud-Blog: https://open-telekom-cloud.com/de/blog