Beim Web Talk zu unserer Infrastruktur, die uns erlaubte, spontan auf 100% Remote-Arbeit umzustellen, blieben einige Fragen offen, die auch unser vorangegangener Blogartikel nicht beantwortet hatte. Auf diese gehen wir an dieser Stelle ein.
Was waren die größten Herausforderungen für euch, diesen Remote-First- bzw. Beyond-Corp-Ansatz technisch und organisatorisch aufzubauen? Was hat euch dabei ggf. überrascht?
Wir haben viel Vorarbeit geleistet, um eine moderne Infrastruktur auf die Beine zu stellen. Eines der größten Projekte war die Entwicklung eines eigenen Identity Management Systems als Basis für die Account- und Stammdatenpflege, das in der Lage ist, sämtliche angrenzenden internen und externen Systeme zu befüllen und zu überprüfen. Mittlerweile verwalten wir in dem System auch die automatische Provisionierung und das Mapping von Lizenzen (z.B. für die G Suite oder Office 365) und können User sehr einfach und struktutriert On- und Offboarden. Irgendwann sind wir da angekommen, dass die Dinge alle ineinander griffen und viele Mammutprojekte wie die SSO-Umstellung von Microsoft oder Google sich im nachhinein als sehr einfach erwiesen haben – das hat uns überrascht. Und bestätigt.
Was sind Best Practices für die Meeting-Moderationen in dezentralen Teams?
Es gibt klare und einfache Regeln für alle! Z.B. sind alle Teilnehmer:innen per default gemutet, alle haben die Kamera an, man fällt anderen nicht ins Wort, man signalisiert Wortmeldungen. Meine Kolleg:innen haben ein paar sehr schöne Blogartikel geschrieben, die sich viel umfassender mit diesem Themenkomplex befassen:
Wie sichert ihr den SSH-Zugriff auf Maschinen ab?
Grundsätzlich durch Keys an Stelle von Passwörtern. Die meisten Systeme sind nicht direkt via SSH erreichbar – nur wenn es notwendig ist, ist der SSH Port nach außen geöffnet. Grundsätzlich verliert der Zugriff via SSH auf Produktionssysteme bei uns mehr und mehr an Stellenwert und ist für den normalen Regelbetrieb und Updateprozesse nicht notwendig, da diese Abläufe in der Regel komplett über Deployment Pipelines automatisiert sind.
Benutzt ihr für 2FA Hardware (Tokengenerator, YubiKey etc) oder eine mobile App?
Wir nutzen an einigen Stellen U2F Token, am häufigsten kommen bei uns aber TOTP Tokens in Kombination mit entsprechenden Apps wie etwa Google Authenticator zum Einsatz. Unser 2FA-System ist allerdings modular und wir planen zukünftig weitere Mechanismen zu ergänzen und das System ggf. adaptiv zu gestalten – je nach Plausibilität der Anfrage.
Wie viele Mitarbeiter:innen warten die beschriebene Infrastruktur?
Unser IT & Cloud Team besteht aktuell aus acht Vollzeitkräften und zwei Azubis. Deren Aufgaben umfassen allerdings alle Bereiche der Unternehmens-IT, von der eigenen und der Public-Cloud-Infrastruktur über das Cloud Management, den Betrieb der inovex-Systemlandschaft und aller Services, dem IT Engineering bis hin zu IT Einkauf, Standort-IT und Medientechnik.
Grundsätzlich verfolgen wir hier den Ansatz Eat your own Dogfood. Was wir unseren Kunden empfehlen, nutzen wir auch selbst – moderne, skalierbare und hoch automatisierte Lösungen.
Welche Datenschutzbedenken habt ihr?
Wir prüfen alle Systeme und Services und bewerten in unserem crossfunktionalen Datenschutzteam jeden neuen Service hinsichtlich unserer TOMs, einer DSGVO-konformen Verarbeitung von Daten und natürlich hinsichtlich strategischer Aspekte wie Vendor Lock-in oder auch der Einsetzbarkeit von Services z.B. im besonders sensiblen Kundenkontext. Grundsätzlich empfehlen wir die Etablierung eines transparenten Prozesses für die Bewertung neuer Tools. Dieser Prozess sollte VOR der Nutzung eines Tools konsequent eingehalten werden.
Gibt es bei euch SSO über ADFS oder müsst ihr euch mehrfach am Tag bei den einzelnen Services authentifizieren?
Wir haben einen echten SSO und man muss sich nur neu anmelden, wenn die Session abläuft. Des Weiteren ist man direkt bei allen Services angemeldet – sowohl bei allen unseren eigenen Diensten als auch bei Microsoft, Google oder Slack. Wir haben eine sehr gute UX, was zu einer hohen Akzeptanz von starken Passwörtern und 2FA-Mechanismen führt.
As Code-Infrastruktur hat natürlich den großen Vorteil, dass ihr von überall aus das System warten könnt. Gibt es weitere, eher versteckte Vorteile gegenüber Selfhosting und welche Nachteile gibt es?
Grundsätzlich hat as Code erstmal relativ wenig mit dem Ort zu tun, man kann auch klassische, manuelle Administration aus der Ferne erledigen. Der große Vorteil von deklarativen Ansätzen wie Infrastructure as Code ist vielmehr Nachvollziehbarkeit, Automatisierung und Geschwindigkeit. Wir sind in der Lage, Umgebungen mit verteilten Systemen in wenigen Minuten komplett zu provisionieren – sowohl bei Änderungen als auch im Desasterfall.
Ein weiterer Vorteil ist, dass man den Code, der in einer Umgebung wie der inovex Cloud funktioniert, recht einfach für Umgebungen wie Microsoft Azure, AWS oder Google Cloud portieren kann.
Eine potentielle Herausforderung ist natürlich der Wissensaufbau, da hier natürlich gegenüber der klassischen Administration Fähigkeiten im Bereich der Softwareentwicklung gefragt sind.
Welche Software nutzt ihr überwiegend?
Wir nutzen für Infrastructure as Code Terraform und als Deployment- and Configuration-Management-System Ansible – beides in Kombination mit GitLab zur Versionskontrolle und gitlab-ci als CI-System. Unsere Anwendungen laufen in der Regel in Docker-Containern auf der auf OpenStack basierenden inovex Cloud in unserem Rechenzentrum in Frankfurt oder in unserem VPC bei Microsoft Azure.
Warum geht die Administration weiterhin über VPN? Habt ihr Erfahrungen mit Cloudflare Access für SSH und RDP? Das nutzt SAML …
Wir nutzen den SSH-Zugriff sehr selten, da die Systeme in der Regel komplett automatisiert verwaltet und aktualisiert werden. Wenn es ernste, unbekannte Probleme gibt nutzen wir ein lokales VPN.
Für CI/CD: Benutzt ihr da bevorzugt Container?
Unsere Anwendungen laufen in der Regeln in Containern, auch Builds laufen zum Großteil in Containern.
Nutzen eure Teams auch Infrastrukturen direkt in der Public Cloud oder geht das immer über den zentralen IaC-Ansatz?
Wir nutzen den Infrastructure as Code Ansatz sowohl für unsere eigene Cloud als auch für unsere Umgebung bei Microsoft Azure.
Welche Client-Geräte nutzt ihr?
Ein Aspekt für unseren SSO-Ansatz und die überwiegend webbasierten Services ist unsere heterogene Client-Landschaft. Unsere User nutzen Windows 10, Linux oder macOS – je nachdem, womit die Kolleg:innen sich am wohlsten fühlen und effizient arbeiten können.
Wie läuft bei euch ein typisches Kundenprojekt ab?
Der Einstieg ist bei uns in der Regel ein gemeinsamer Architektur-Workshop, in dem wir mit dem Kunden zusammen ein umfassendes Bild der Systemlandschaft und des Rahmens, in dem sich ein Vorhaben bewegen wird, skizzieren, und dann gemeinsam agil ein Backlog mit konkreten Stories erstellen. Nach dem Workshop hat der Kunde einen guten Überblick über den Umfang, die Risiken und mögliche Kostentreiber und kann entscheiden ob, in welchem Umfang und mit wem er das Projekt realisieren möchte – hier freuen wir uns natürlich darüber, wenn sich der Kunde für uns entscheidet! Die Projekte selbst sind sehr individuell, teils vor Ort, teils remote, mit kompletten Teams von inovex oder mit gemischten Teams – je nach Situation. Wir empfehlen unseren Kunden eine agile Methodik für die Durchführung des Projektes, da sich das in einer Vielzahl von erfolgreichen Projekten immer wieder bewährt hat.
Welche Whiteboard-Dienste verwendet ihr zum gemeinsamen Brainstormen & Workshop-Formaten?
Wir nutzen das Google Jamboard aus der GSuite oder Services wie miro.
