Platform Building
ist der erste Schritt im

Platform Engineering

Eine leistungsstarke Software-Plattform zu entwickeln erfordert strategisches Denken und tiefes Fachwissen. Bei Platform Building stehen wir Ihnen zur Seite, um Ihren individuellen Masterplan für den Aufbau einer Software-Plattform zu entwickeln und umzusetzen.

  • Architecture: Wir entwerfen die Grundlagen Ihrer Plattform, so dass sie skalierbar, stabil und bereit für zukünftige Entwicklungen ist.
     
  • Cloud: Mit unserer Expertise in Cloud-Technologien helfen wir Ihnen dabei, die Flexibilität Ihrer Plattform zu steigern.
     
  • Automation: Wir optimieren Ihre Prozesse durch Automatisierung, um Effizienz zu steigern und manuelle Aufgaben zu minimieren.
     
  • Governance: Sicherheit und Compliance sind von entscheidender Bedeutung. Wir implementieren Governance-Modelle, um Ihre Plattform zu schützen und regulatorische Anforderungen zu erfüllen.
     
  • Maintenance: Der Aufbau einer Plattform endet nicht mit der Implementierung. Wir stellen sicher, dass Ihre Plattform immer optimal funktioniert.

Oliver Weise
Teamlead der Unit Platform Engineering bei ConSol

Starte ich ein Software-Projekt auf einer modernen Anwendungsplattform, so geht der erste Schritt zum Plattform-Portal. Dort kann ich mir im Self-Service alle notwendigen Projekt-Ressourcen selbst provisionieren: Workload-Kapazität, Rollout-Stages, Quellcode-Repositories usw. Viele Ressourcen sind dann sofort verfügbar, andere spätestens am nächsten Tag.

CI/CD-Pipelines auf Knopfdruck

Gleichzeitig wird für mich im zugehörigen CI/CD-Framework eine funktionale Standard-Pipeline für Build, Test und Rollout angelegt. Diese kann ich verwenden, anpassen, oder in Sonderfällen durch etwas in Eigenbau ersetzen. Oft bin ich schon nach wenigen Tagen in der Lage, erste Deployments von Prototypen durchzuführen und mich ganz auf die fachliche Seite meines Projektes zu konzentrieren.

Lebendes System: Observability, DevOps & SRE sind miteinander verbunden

Observability-Features wie Logging, Tracing, Monitoring mit vielen vorgefertigten Metriken und Alerts sind inbegriffen und "einfach da". Vieles davon funktioniert ohne mein Zutun. Für anderes muss ich mich lediglich um die Anbindung in meiner Software kümmern. Dazu gibt es aber für die im Unternehmen gängigen Entwicklungs-Frameworks fertige, gut dokumentierte Konzepte.

Ebenso wichtig: Observability ist nicht mehr nur etwas für Ops. Wir im Projekt haben selbst einen "First-Class"-Zugriff. So lernen wir viel darüber, wie unsere Software im Echtbetrieb performt und können auf dieser Basis mit unserem Site Reliability Engineer Zuverlässigkeit und Effizienz optimieren.

Weniger Plattform ist erstmal mehr

Wichtig zu betonen: Wieviel Plattform ich als Unternehmen will, das entscheide ich selbst. Entscheidend ist die Developer Experience. Die hat sich bei vielen ausufernd komplexen Plattformen als nicht gut erwiesen. Darum sollte das Prinzip lauten: vor allem im Aufbau lieber erst einmal das Nötigste. Dieses gilt es von Anfang an so zu gestalten, dass es den Entwickler wirklich unterstützt, nicht überfordert.

Sie wollen mehr zum Thema Platform Engineering erfahren?

Der Weg zur Plattform

Was ist eigentlich Platform Engineering?

Platform Engineering ist ein Bereich in der Softwareentwicklung, der sich auf die Entwicklung und Wartung von Plattformen oder Frameworks konzentriert, die von anderen Entwicklern genutzt werden, um Anwendungen zu erstellen. Diese Plattformen können verschiedene Formen annehmen, einschließlich Betriebssystemen, Cloud-Plattformen, Entwicklungsframeworks, APIs (Application Programming Interfaces) und mehr. Das Hauptziel des Platform Engineering ist es, eine solide Grundlage bereitzustellen, auf der andere Entwickler Anwendungen erstellen können, ohne sich um die zugrunde liegende Infrastruktur kümmern zu müssen.

Platform Engineering zielt also darauf ab, Werkzeugketten und Arbeitsabläufe als Self-Service-Komponenten zu entwerfen, an denen sich Software-Entwickler im Rahmen von Cloud-nativer Entwicklung bedienen können. Plattform Engineers stellen ein integriertes Produkt bereit, das häufig als "Interne Entwickler-Plattform" bezeichnet wird und die operativen Anforderungen des gesamten Lebenszyklus einer Anwendung abdeckt.

Warum Platform Engineering? Die Ausgangssituation

Back in the days: Wenn Entwickler ihre Applikationen zum Laufen bringen wollten, dann gab es nur einen Weg – und zwar den über den SysAdmin. Nicht nur dass hier Bottlenecks entstanden, auch machte es den großen Graben zwischen Dev und Ops sehr offensichtlich, was logischerweise auf beiden Seiten zu Unzufriedenheit führte.

Mit dem Erfolg der Cloud und des Cloud Computing setzte sich DevOps als DIE Methode der Zusammenarbeit durch: Das betraf nicht nur die räumliche Strukturierung von Teams (gemischte Teams in einem Büro), Feedbackschleifen und Arbeitsweise. DevOps wurde ein Mindset, mit dem Software-Entwickler von vornherein ganz anders an Aufgaben herangingen.

DevOps+Cloud: Paradigmenwechsel mit Cognitive Overload

„You build it, you run it.“ Funktioniert dieser Leitsatz tatsächlich für Unternehmen und deren IT-Units? Zählt man sich zu den großen Playern wie Google, Microsoft, Amazon etc. dann vielleicht ja – meine einer schier unendlichen Möglichkeit an Ressourcen, um Prozesse zu optimieren und dem Zugriff auf die weltweit besten Arbeitskräfte ist dieses Ideal durchaus umsetzbar.

Die meisten anderen Unternehmen erleben wohl eher folgendes, beispielhaftes Szenario:
Senior-Entwickler tragen die Verantwortung für die Verwaltung von Umgebungen & Infrastruktur und damit übernehmen sie plötzlich Aufgaben, die nichts mit ihrem eigentlichen Auftrag zu tun haben – nämlich ihre Ressourcen in Coding und Produkt(weiter-)entwicklung zu stecken. Dies kann zum vielzitierten Cognitive Overload führen. Infolgedessen entsteht eine Loose-Loose-Situation: Die erfahrenen Entwickler sind nun für die Konfiguration und die Lösung von Anfragen weniger erfahrener Kollegen verantwortlich, sodass die gesamte Organisation wertvolle Kapazitäten an den falschen Stellen einsetzt. Das Ergebnis dieser Situation sind schlechtere Ergebnisse: Software und Funktionen können nicht mehr so schnell, so zuverlässig und so qualitativ hochwertig ausgeliefert werden.

Ein sehr lesenswerter Beitrag zu „DevOps bad practices“ findet sich auf dem DevOps-Topologies-Blog: Matthew Skelton und Manuel Pais beschreiben darin sogenannte DevOps Anti Types und zeigen darin Gründe für nicht funktionierende DevOps-Prozesse auf.

Platform Engineering als Lösung: Golden Paths & Paved Roads

Wie also sorgen Teams dafür, dass ihre Entwickler Anwendungen und Dienste ausführen können, ohne ständig auf die Hilfe von erfahrenen Kollegen angewiesen zu sein und wiederum deren Ressourcen zu verschwenden? Die Antwort darauf lautet: Es gibt ein Plattformteam, das eine interne Entwicklerplattform (Internal Developer Platform „IDP“) aufbaut.

Unter anderem der State of DevOps Report 2020 von Puppet zeigt deutlich den Zusammenhang zwischen der Nutzung interner Plattformen und dem Grad der DevOps-Entwicklung von Organisationen.
 

Golden Paths & Paved Roads

Unter dem Terminus „Golden Path“ verstehen wir einen vorgegebenen, gut definierten und auf Aufgaben bezogenen Weg, um Software zu erstellen. Golden Paths ermöglichen es Organisationen, bessere Software schneller, mit höherer Qualität und größerer Kontrolle in Produktion zu bringen. Verschiedene Teams innerhalb eines Unternehmens verwenden oft eine Vielzahl von Tools, Frameworks und Programmiersprachen, sodass Entwickler zu viel Zeit damit verbringen, sich mit der richtigen Technologie vertraut zu machen, anstatt einfach Software zu entwickeln.

Golden Paths basieren meist auf Best Practices, Industriestandards & dem kumulierten Wissen von Software Engineers in einer Organisation. Um den Software-Entwicklungsprozess zu optimieren werden Rahmenbedingungen, Werkzeuge & Verfahren definiert und auch dokumentiert.

Die Paved Roads stellen den nächsten Schritt dar, bei dem Internal Developer Platforms fertige Lösungen anbieten: IDPs beinhalten eine umfassende Palette an Tools, Services und Infrastruktur, die in einer einzigen Plattform summiert sind. Platform Engineering hält somit toolchains an Workflows und Arbeitsabläufen bereit, an denen sich Entwickler in Self-Service-Manier bedienen können. Die IDP verringert den cognitive (over)load von Entwicklern, da sie Infrastruktur abstrahiert, Projekt-Ressourcen provisioniert, standardisierte Arbeitsabläufe bereitstellt und sich wiederholende Aufgaben automatisiert, z.B.:

  • Hinzufügen von Umgebungsvariablen
  • Konfig-Änderungen
  • Hinzufügen von Services und Abhängigkeiten
  • Roll back und Debugging
  • Bereitstellen einer neuen Umgebung
  • Refactoring
  • Hinzufügen/Ändern von Ressourcen
  • RBAC (Rollenbasierte Zugriffskontrolle)

Warum Sie Platform Engineering brauchen? Wir beraten Sie!

Platform Building: Ihre Plattform, Ihre Vision

Platform Building zielt darauf ab, eine stabile, effiziente und gut verwaltete technologische Plattform zu schaffen, die die Grundlage für die Entwicklung und Bereitstellung von Anwendungen und Diensten bildet. Dies ist entscheidend für Unternehmen, die in der heutigen digitalen Welt wettbewerbsfähig sein wollen, da eine solide Plattform die Grundlage für Innovation und Geschäftserfolg bildet.

Neben den oben genannten Schlüsselbereichen zählen zum Platform-Building-Prozess noch diese weiteren Komponenten:

developer_23.svg

Entwicklung und Erweiterbarkeit

Die Schaffung von Schnittstellen und Tools, die Entwicklern ermöglichen, Anwendungen und Dienste auf der Plattform zu erstellen und zu erweitern.

projektmanagement_23.svg

Dokumentation und Schulung

Die Erstellung von Dokumentationen und Schulungsmaterialien, um Entwicklern und Administratoren die Arbeit mit der Plattform zu erleichtern.

openshift_02_23.svg

Integration


Die Integration der Plattform in bestehende Systeme und Prozesse, um eine nahtlose Zusammenarbeit mit anderen Teilen der IT-Infrastruktur sicherzustellen.

Ihr Ansprechpartner

Oliver Weise

Jetzt Kontakt aufnehmen

Durch Absenden des Formulars stimmen Sie unserer Datenschutzerklärung zu.