Atlassian Expert / DevOps Engineer

Ziele des Kunden: Der bislang in Confluence gepflege Servicekatalog sollte in Jira mit Assets als Datenbasis implementiert werden.

Auswirkung des Projekts: Die Datenintegrität und - qualität wurde gesteigert. Service Daten konnten maschinell eingelesen werden, was anderen Projekten und vor allem technischen Deployments zu Gute kam. Ein Lifecycle Management sowie ein ans Unternehmen angepasster Approval Prozess konnten sauber im UI abgebildet werden.

Zusammenfassung:
Initial wurden alle Services und deren Bausteine zur Erbringung in eine neue Datenstruktur innerhalb Jira Assets übertragen.

In einem dedizierten Jira Project wurde dann das "UI" für das Management der Services angelegt. Services sollten nicht im wenig intuitiven Assets Backend sondern in einem Ticket bearbeitet werden.

Es wurden ScriptRunner Behaviours entwickelt, die Daten aus Assets direkt in Screens nachladen und auch wieder speichern konnten.

Ein eigens angepasster Approval Prozess wurde entwickelt und implementiert. So konnte eine Auswahl an Einzelpersonen aber auch kompletten Teams (mit der Möglichkeit, dass eine beliebige Anzahl an Personen des Teams approven können) getroffen werden, um einen Service z.B. im Lifecycle Prozess zu approven oder nicht.

Um die Approvals grafisch sichtbar zu machen, wurde mit ScriptRunner ein Custom Panel in die Ticketansicht gebaut auf dem zu erkennen war, wer bereits approved hat und wieviele sowie welche Approvals noch fehlen (in der Optik eines Ampelsystems).

Ein REST Endpoint wurde erstellt um Services programmatisch verfügbar zu machen. Dies wurde u.A. im HTTP Provider von Terraform benutzt, um Deployments für Monitoring und Billing zu taggen.

Ziele des Kunden: Die bislang in AWS aufgebauten Kundenplattformen sollten stabilisiert sowie das Deployment standartisiert werden. Komplexität sollte aus dem grundlegenden Setup genommen werden. Es sollte ein zentrales Log Management implementiert werden.

Auswirkung des Projekts: Durch eine aufgebrochene Komplexität und Migration aus AWS heraus, konnten gleichzeitig Stabilität gewährt als auch monatliche Kosten reduziert werden. Debugging fuer das Ops-Team wurde durch zentrale, aggregierte Logs vereinfacht. Ebenso konnte ein Großteil von neuen Deployments vollautomatisiert passieren, was weniger benötigte Zeit und weniger Fehleranfälligkeit zur Folge hatte.

Zusammenfassung:
Nach einer Bestandsanalyse der bestehenden Kunden Setups wurde ein neue zur Workload passende Infrastruktur- und Deployment-Strategie entwickelt.

Die Entscheidung wurde gemäß des KISS Prinzips getroffen und neue Plattformen sollten vollumfänglich vom Team selbst in klassischen VMs bei einem europäischen Hoster betrieben werden.

Terraform Meta-Module wurde entwickelt um das IaaS Deployment stark zu vereinfachen, einen Standard zu schaffen und die Deployment Zeit zu verringern.

Für alle benötigten Services wurden Ansible Rollen geschrieben und diese dann in Meta-Rollen gebündelt; ebenfalls um einen Standard zu schaffen und ein initiales Deployment stark zu vereinfachen.

Um die Terraform und Ansible Meta Rollen wurden Plattform Templates gebaut. Ein Kunden Repository konnte so mit wenig User Input statt vormals dem Schreiben langer Vars Files angelegt werden.

Um dynamisch auf Kundenanforderungen zu reagieren, wurde Consul als "Config Store" eingesetzt und in viele Ansible Rollen integriert. Ansible Defaults konnten per Lookup direkt aus Consul befüllt werden, weiterhin hatten viele Config Templates einen generischen Fallback dessen Inhalt ebenfalls aus Consul bezogen werden konnte.

Ziele des Kunden: Die Online Buchungsplattform stand in der Peak Season unter Volllast, was zu Ausfällen führte die der bisherige Hoster nicht lösen konnte. Die Plattform sollte in einem sehr kurzen Zeitfenster ad hoc zu einem neuen Hoster umgezogen werden. Primäres Ziel war die Peak Season über online zu bleiben um das Geschäft nicht weiter zu gefährden und danach die komplette Plattform neu zu designen und zu bauen.

Auswirkung des Projekts: Der Geschäftsbetrieb in der Peak Season konnte aufrecht erhalten werden. Die Plattform konnte in den Folgemonaten weiterentwickelt und technologisch auf den neusten Stand gebracht werden. Dies resultierte in höherer Stabiltät, Verfügbarkeit und Performance. Folgende Peak Seasons waren kein betriebliches Risiko mehr.

Zusammenfassung:
Die gesamte Plattform wurde im laufenden Betrieb mit kurzen Downtimes von einem Hoster zum Anderen migriert. Da ein Teil der Configs nicht oder nicht schnell genug verfügbar war, musste ein Reverse Engineering der App- und Datenbankserver stattfinden.

Nach dem "Überstehen" der Peak Season wurde in intensiven Workshops mit dem Kunden ein neues Architekturbild entworfen um die Plattform stabiler und ausfallsicherer zu machen sowie schneller bereit stellen zu können. Ebenso sollte sowohl Scale up als auch Scale out ohne große Vorlaufzeit möglich sein.

Die Appserver wurden stateless entwickelt und hinter einen großen Pacemaker/Corosync HAProxy Cluster gebaut. Der Application Code wurde aus einem hochverfügbaren DRBD Cluster bezogen, während die Datenbanken in einen Multi Primary Cluster (MariaDB + Galera) ausgelagert wurden.

Bis auf den Application Code wurden alle Bestandteile der Plattform mit Ansible und Terraform automatisiert. Es wurden drei feste Stages aufgebaut und betrieben. Durch den Automatisierungs Code konnte der Kunde jederzeit kleine Entwicklungsumgebungen beauftragen, die per Knopfdruck in kurzer Zeit zur Verfügung gestellt werden konnten.
Es wurde eine an DevOps angelehnte Arbeitsmethodik zwischen Kunde (bzw. Softwarehersteller) und Hoster entwickelt, woraus viele neue Features der Plattform entstanden sind.

In Peak Seasons konnte bzw. wurde die Plattform in die Breite gezogen, in eher ruhigen Zeiten wurde sie verkleinert um die Kosten so effizient wie möglich zu halten.

Ziele des Kunden: Ein schnell wachsendes Startup brauchte ein dediziertes Team um Linux Services für Kunden entwickeln, bereitstellen und betreiben zu können.

Auswirkung des Projekts: Neukunden konnten gewonnen werden und Bestandskunden konnten weitere Services erbracht werden. Das Produktportfolio des Unternehmen konnte vergrössert und weitere Talente für die Firma gewonnen werden.

Zusammenfassung:
Das initiale Team wurde durch drei Mitarbeitende aufgestellt, die bereits für das Unternehmen tätig waren.

In Eigeninitiative und teilweise mit Hilfe von Recruitment Partnern wurden insgesamt vier neue Talente für das Team gesucht und gefunden.

Das Team wurde hin zu einer Scrum entsprechenden Arbeitsmethodik transformiert.

Drei Senior und vier Junior Engineers bildeten das finale Team. Periodischer Wissenaustausch wurde gefördert, so dass sich jedes Team Mitglied weiterentwickeln konnte.

Ziele des Kunden: Es sollte eine alternative Shared Private Cloud zur bestehenden VMware Plattform implementiert werden.

Auswirkung des Projekts: Kosteneffizientere IaaS Services konnten für Kunden angeboten werden. Weiterhin konnte Kunden die Möglichkeit gegeben werden ihre eigenen IaaS Ressourcen zu verwalten und zu skalieren. Das Produktportfolio des Unternehmes konnte erweitert werden.

Zusammenfassung:
Initial wurde eine Ziel Architektur entwickelt und beschlossen. Die OpenStack Control Plane sollte hochverfügbar über drei Lokationen aufgebaut werden.

Als Deployment Ansatz wurde OpenStack Vanilla gewählt und mittels Ansible - welches so generisch entwickelt wurde, dass es für weitere Stacks benutzt werden konnte - automatisiert.

Storageseitig wurden zwei Tiers aufgebaut: Ein Full Flash Tier unter Zuhilfenahme von Enterprise Storage und ein Hybrid Tier was initial durch einen 11 Node Ceph Cluster gebildet wurde.

Während Keystone und der Datenbank Cluster über die drei Lokationen gestretched wurden, kamen die anderen OpenStack Komponenten unabhängig voneinander zum Einsatz und waren innerhalb der einzelnen Lokationen in sich geclustert.

Per Design stand den Kunden schlussendlich eine Region mit drei Availability Zones zur Verfügung.

Durch das ausfallsichere Design der Plattform konnten Wartungsarbeiten an Einzelkomponenten aber auch OpenStack Major Upgrades mit besonders kurzen Downtimes realisiert werden.

Ziele des Kunden: Als einer der ersten Provider für einen innovativen Cloud Ressourcen Marktplatz sollte das Unternehmen technisch in diesen Marktplatz integriert werden.

Auswirkung des Projekts: Das Unternehmen war einer der ersten Provider für den Marktplatz und konnte gekaufte Resource Contracts zuverlässig aus deutschen Rechenzentren bereitstellen. Ein weiterer Sales Channel konnte so eröffnet und ausgebaut werden, was positiv zum Umsatz und der Reputation beigetragen hat. OpenStack Know-How im Unternehmen konnte auf- und ausgebaut werden.

Zusammenfassung:
Initial wurde eine OpenStack Plattform mit einer zentralen, hochverfügbaren Control Plane und zwei Availability Zones für Compute in zwei deutschen Rechenzentren entworfen und aufgebaut.

Gemeinsam mit dem Marktplatz Betreiber wurde die Middleware zwischen OpenStack und Marktplatz integriert, ausgiebig getestet und auch weiterentwickelt.

Es wurden klassische Cattle Workloads erwartet, weswegen die Hardware und der Grad an Hochverfügbarkeit bewusst effizient ausgelegt wurden. Der Fokus lag auf schnellem Kommissionieren und Dekommissionieren von Cloud Instanzen.

Parallel zur Marktplatz Integration wurde ein PoC durchgeführt um HPC Workloads auf speziellen Hypervisoren die mit Infiniband angebunden waren auszuführen.