In einem Tech-Unternehmen entsteht der Vorsprung längst nicht mehr allein aus dem Anwendungscode, sondern daraus, wie schnell und sicher dieser Code in die Produktion gelangt. Wenn sich Produktteams vervielfachen und die Zahl der Umgebungen und Dienste stetig wächst, bremsen manuelle Deployments und Ad-hoc-Infrastruktur die gesamte Engineering-Organisation. In diesem Moment hören Cloud-Plattform und CI/CD auf, ein Nebenthema zu sein, und werden zum Fundament der Delivery-Geschwindigkeit.
Aus unserer Erfahrung ist der schwierige Teil nicht die erste Pipeline, sondern eine stimmige Plattformschicht, in der Dutzende Teams nach denselben Regeln arbeiten. Genau solche Projekte haben wir für Technologieführer umgesetzt: Engineering von Cloud-Plattformkomponenten, DevOps-Automatisierung und Migrationen von Cloud zu Cloud. In diesem Artikel zeigen wir Schritt für Schritt, wie wir Plattform, Cloud und CI/CD angehen.
Warum braucht ein Tech-Unternehmen eine eigene Plattform- und Cloud-Schicht?
Weil ohne sie jedes Team dieselben Probleme von vorn löst. Eines konfiguriert Deployments auf seine Weise, ein zweites geht anders mit Secrets um, ein drittes erfindet einen eigenen Weg, eine Testumgebung hochzufahren, und das Sicherheitsteam kann das alles nicht zusammenbinden. Das Ergebnis ist weniger Chaos als vielmehr ein steigender Aufwand bei jeder weiteren Änderung.
Eine eigene Plattformschicht dreht diese Logik um. Wir behandeln sie als internes Produkt für Entwicklungsteams: Sie liefert fertige, wiederholbare Wege zum Bauen, Testen und Ausliefern, sodass eine Produktentwicklerin keine Cloud-Expertin sein muss, um eine Änderung sicher auszuliefern. Für eine Engineering-Leitung heißt das Planbarkeit, schnelleres Onboarding und weniger Vorfälle durch manuelle Konfiguration. Diese Schicht bauen wir in der Regel gemeinsam mit dem Team des Kunden, statt sie losgelöst von dessen Realität zu verordnen.
Wie automatisieren Sie Releases mit CI/CD?
Das Ziel ist einfach: Vom Commit bis in die Produktion soll es einen wiederholbaren, nachvollziehbaren Weg geben, ohne manuelle Schritte, bei denen etwas schiefgehen kann. So legen wir die Release-Pipeline an:
- automatische Builds und Tests bei jeder Änderung, damit ein Defekt in Minuten auffällt und nicht in der Produktion,
- einheitliche Pipelines (z. B. Jenkins, GitLab CI, GitHub Actions), die alle Teams teilen, statt Dutzender Varianten,
- Deployments über die Umgebungen hinweg (dev, staging, production) nach demselben Schema,
- sichere Rollout-Strategien (Blue-Green, Canary) mit einem schnellen Weg, eine Änderung zurückzunehmen,
- Qualitäts- und Sicherheitstore, in die Pipeline eingebaut und nicht nachträglich angeflanscht.
Gut automatisiertes CI/CD verkürzt den Weg einer Änderung von Tagen auf Stunden und nimmt den Teams den Stress des Deployments, weil jedes Release gleich aussieht.
Warum ist Infrastructure as Code das Fundament einer Plattform?
Weil Infrastruktur, die in einer Cloud-Konsole von Hand zusammengeklickt wurde, nicht reproduzierbar ist, und im Maßstab eines Tech-Unternehmens ist das ein echtes Risiko. Beschreiben wir die Umgebung als Code (Terraform, Ansible, Helm), hört sie auf, das Erfahrungswissen einer einzelnen Person zu sein, und wird zu einem versionierten, geprüften Artefakt wie jeder andere Teil des Systems.
Der praktische Unterschied ist groß. Eine neue Umgebung entsteht wiederholbar und nicht „aus dem Gedächtnis”. Eine Änderung an der Infrastruktur durchläuft Code Review und dieselbe Pipeline wie die Anwendung, sodass sichtbar ist, wer was warum geändert hat. Die Wiederherstellung des ganzen Stacks nach einem Ausfall hört auf, eine Heldentat zu sein, weil alles aufgeschrieben ist. Infrastructure as Code ist genau das, was eine Plattform planbar und nachvollziehbar macht, statt sie vom Vertrauen in einzelne Administratoren abhängig zu lassen.
Wie bringen Kubernetes und Containerisierung Ordnung in Umgebungen?
Die Containerisierung löst das alte Problem „läuft auf meinem Rechner”, denn die Anwendung reist zusammen mit ihrer Laufzeitumgebung. Kubernetes legt eine Orchestrierungsschicht darüber, die ab vielen Diensten den Unterschied macht. In Plattformprojekten nutzen wir sie, um:
- die Art, wie Dienste laufen, zu vereinheitlichen, unabhängig davon, welches Team sie geschrieben hat,
- die Last mit dem Verkehr hoch- und herunterzuskalieren, ohne Maschinen von Hand zu ergänzen,
- Teams und Umgebungen zu isolieren über Namespaces und Policies,
- Deployments zu standardisieren über Helm und wiederholbare Manifeste,
- die Widerstandsfähigkeit zu erhöhen durch automatische Neustarts und Health Checks.
Kubernetes ist für uns allerdings kein Selbstzweck. Es ist ein Werkzeug für einen bestimmten Maßstab, und wir greifen dort dazu, wo es die Arbeit der Teams wirklich vereinfacht, nicht überall aus Prinzip.
Wie führen Sie eine Cloud-Migration durch und optimieren Kosten beim Wechsel von AWS zu GCP?
Eine Cloud-Migration ist selten ein Eins-zu-eins-„Lift and Shift”. Wir beginnen mit einer Inventur dessen, was tatsächlich läuft: welche Dienste, welche Abhängigkeiten, wie viel Verkehr und welche Daten. Erst dann entscheiden wir, was unverändert umzieht, was um die Cloud-Dienste der Zielplattform herum neu gebaut wird und was abgeschaltet wird, weil es niemand mehr nutzt.
Beim Wechsel von AWS zu GCP achten wir besonders auf zweierlei: Kontinuität und Kosten. Wir führen die Migration in Etappen durch, damit das Geschäft keinen Ausfall spürt, und optimieren parallel die Cloud-Kosten über die Wahl der passenden Ressourcentypen, Autoscaling und eine Abschaltregel. Die Cloud wird nicht teuer, weil sie von Natur aus teuer wäre, sondern weil niemand nachhält, was läuft und wozu. Eine solche Migration von Cloud zu Cloud haben wir in der Praxis durchgeführt und wissen, wo die Fallstricke meist liegen.
Wie richten Sie Observability und Alerting für eine Plattform ein?
Eine Plattform, die Sie nicht sehen, reparieren Sie im Nachhinein und im Dunkeln. Deshalb behandeln wir Observability von Anfang an als Teil des Projekts und nicht als Zusatz am Ende. In der Praxis bauen wir:
- Metriken zu Leistung und Gesundheit der Dienste in einer stimmigen Sicht,
- zentrale Logs statt Durchsuchen einzelner Maschinen,
- Tracing von Anfragen über viele Dienste hinweg, um den Engpass zu finden,
- Alarme auf Basis realer, für Nutzer spürbarer Symptome und nicht jedes Ausschlags einer Kurve,
- Dashboards, die sowohl die Rufbereitschaft als auch eine Führungskraft lesen kann.
Gut eingestelltes Alerting weckt Menschen, wenn es soll, und bleibt still, wenn es keinen Grund gibt. Das ist der Unterschied zwischen einem Team, das Brände löscht, und einem, das Vorfälle verhindert.
Welche Plattform-Kompetenzen stellen wir für das Projekt?
Wir formen das Team um die konkrete Phase und den Maßstab der Plattform, nicht „auf Vorrat”. Am häufigsten besetzen wir Rollen wie:
- einen Platform- bzw. DevOps-Engineer, der Pipelines, IaC und Automatisierung baut,
- einen Cloud-Engineer, der Architektur und Migrationen verantwortet (AWS, GCP),
- einen Kubernetes- bzw. SRE-Spezialisten, der sich um Skalierung und Zuverlässigkeit kümmert,
- einen Architekten, der die Plattform mit dem übrigen System verbindet und die Standards setzt.
Diese Menschen prüfen wir vor dem Start, und als Nearshore-Partner aus Polen arbeiten wir in einer nahen Zeitzone, sodass sie ohne langen Anlauf in Code Reviews, Rufbereitschaft und Termine einsteigen.
Wie machen wir das bei RITS?
Wir tun das als Nearshore-Partner aus Polen, mit echter Erfahrung in Plattform- und Cloud-Projekten für Technologieführer. Für einen Marktführer aus dem Silicon Valley, der eine digitale Plattform aufbaut, haben wir DevOps-Kompetenzen gestellt und eine Cloud-Migration von AWS zu GCP umgesetzt, zusammen mit Arbeiten an Cloud-Plattformkomponenten. Für einen globalen Anbieter digitaler Dienstleistungen haben wir Cloud-Plattformprojekte und Migrationen von Cloud zu Cloud durchgeführt - genau die Art von Arbeit, die kein Experimentieren am laufenden System zulässt.
In beiden Fällen bringen wir dasselbe mit: Ingenieure, die es in der Produktion getan haben, wiederholbare Deployments auf Basis von CI/CD und Infrastructure as Code sowie ein Team, das um das Projekt geformt ist. Am häufigsten arbeiten wir hier als Team, das die Plattform baut und weiterentwickelt, und dort, wo Kompetenzen schnell aufgefüllt werden müssen, im Modell Team-Verstärkung.
Womit beginnen Sie bei Plattform, Cloud und CI/CD?
Beginnen Sie mit dem schmerzhaftesten einzelnen Weg: vom Commit bis in die Produktion für ein ausgewähltes Team. Dieser Weg zeigt, wo Sie tatsächlich Zeit verlieren, ob bei manuellen Deployments, beim Hochfahren von Umgebungen oder bei fehlender Sichtbarkeit. Von dort definieren wir den Umfang der ersten Plattformetappe, die Cloud-Architektur und die benötigten Rollen. Die Unterschiede zwischen den Kooperationsmodellen haben wir in unserem Artikel zu IT-Kooperationsmodellen beschrieben.
Bauen Sie Plattform, Cloud oder CI/CD für ein Tech-Unternehmen? Sprechen wir darüber - wir stimmen Team und Architektur auf Ihren Maßstab ab.