Die IONOS SE als Teil der United Internet Gruppe verfolgt den Ansatz, die eigenen Services der IONOS tiefer im Unternehmen zu verankern. Ein Aspekt dieses Ansatzes ist die Nutzung des eigenen Cloud-Anbieters “IONOS Cloud”. YOTRON unterstützt dabei die BI/BigDate-Abteilung bei der Nutzung der IONOS-Cloud für ihre Dienste. YOTRON unterstützt bei DevOps, Cloud und Kubernetes Ziel des Einsatzes von Kubernetes und IONOS-Cloud ist die nahtlose Integration in das IONOS Netzwerk als private Cloud ohne direkten Internet Zugang um die IONOS Cloud als “private Cloud” betreiben zu können.

Mit dem Projekt Access 4.0 der Deutschen Telekom AG (DTAG) wird ein neuer Weg beschritten um den Zugang der Kunden der DTAG zu deren Gigabit-Produkte wie Telefon, Internet oder MagentaTV zu ermöglichen. Statt wie bisher auf monolithische Systeme zu setzen wird die Zugangsplattform mit normalen Standardkomponenten wie Switches und Server sowie einem breiten Softwareeinsatz ermöglicht das ausschließlich auf OpenSource-Produkte setzt. Automation und hochmoderner Softwareeinsatz Ziel des Projektes ist es mehrere hundert Standorte automatisiert mit aller relevanten Software und fachlichen Informationen zu bestücken und auch den Aktualisierungsprozess über moderne CI/CD Prozesse zu steuern ohne manuell eingreifen zu müssen (“Zero-Touch-Provisioning”).

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.

Modernes DevOps ohne Infrastructure as Code (IaC) ist kaum möglich. In DevOps (Development und Operations) harmonisieren die beiden klassischen IT-Aufgaben Entwicklung der Software und Administration der Infrastruktur. In DevOps kann man beides nicht mehr voneinander trennen. Die alte klassische Vorgehen mit der klaren Trennung zwischen der IT-Administration, die Sie sich um den Kauf und den Betrieb der Infrastruktur kümmerte, und der Entwicklung, die für die Software oder Lösung (Solution) verantwortlich ist, verschmelzen.

Das Deployen neuer Releases war früher mit einem hohen zeitlichen Aufwand verbunden. Der Download, das Bauen, das Testen und das Ausliefern neuer Releases für die klasssichen Umgebungen Entwicklung, Staging (Abnahme) und Produktion hatte je nach System eine umfangreiche Anzahl an Schritten zur Folge. Schritte bei einem Releasewechsel Ein Releasewechsel bedeutet im allgemeinen Umbau der Releaseumgebung im lokalen System, d.h. Download der neuen Releases, Anpassung der Konfiguration, Update einer Datenbank, Anpassung ergänzender Module wie WebProxy (Apache, Nginx), Docker usw.