Ein Plattform-Engineering-Ansatz spart Entwicklern Zeit und Teams können ganze Kategorien routinemäßiger Anfragen von Entwicklern eliminieren.
Übersetzt aus „Platform Engineering: What Does ‚Good‘ Look Like?“ , Autor Dormain Drewitz.
Um die Entwicklererfahrung zu verbessern, setzen immer mehr Unternehmen auf Plattform-Engineering, um mühsame Arbeit zu reduzieren und sich auf umsatzgenerierende Funktionen und Innovationen zu konzentrieren.
Plattform-Engineering bringt zwei Hauptvorteile mit sich. Das erste ist die Einführung von Self-Service-Funktionen, die es den Mitarbeitern im Unternehmen ermöglichen, neue Software auszuprobieren. Die zweite Möglichkeit besteht in der Einbindung automatisierter Infrastrukturabläufe, um sicherzustellen, dass Experimente in einer gut verwalteten Umgebung durchgeführt werden.
Die Vorteile sind so erheblich, dass Gartner schätzt, dass bis 2026 80 % der großen Software-Engineering-Organisationen über Plattform-Engineering- Teams verfügen werden . Doch was steckt hinter dem Hype?
Was ist Plattform-Engineering?
Ein Plattform-Engineering-Ansatz ergänzt DevOps . Die „Plattform“ ist eine interne Umgebung, die für Entwickler geschaffen wurde, um Software (wie Anwendungen, Tools und Workflows) in einer sicheren und konformen Umgebung zu erstellen und auszuführen.
Der Hauptzweck des Plattform-Engineerings besteht darin, die Arbeit der Entwickler effizient zu skalieren und gleichzeitig Sicherheits- und Verfügbarkeitsrisiken zu minimieren. Entwicklerplattformen bewältigen die enormen Kosten und Komplexitäten, die mit einer groß angelegten Entwicklung einhergehen können. Der häufigste Grund für diese Kosten ist, dass Entwickler für jedes Projekt (oder sogar einzelne Testfälle innerhalb eines Projekts) separate Umgebungen einrichten. Ein weiterer Vorteil ist die erhöhte Wahrscheinlichkeit, in großem Maßstab arbeiten zu können, da Betriebsprozesse innerhalb einer einheitlichen Plattform automatisiert werden können.
Damit dieser Ansatz erfolgreich ist, muss die Software auf derselben Plattform bereitgestellt werden. Oberflächlich betrachtet mag dies dazu führen, dass ein Plattform-Engineering-Ansatz wie eine Einschränkung der Produktivität erscheint, tatsächlich kann er jedoch die Kreativität der Entwickler freisetzen und die tägliche, mühsame Arbeit erheblich reduzieren.
Build vs. Buy: Wie setzen Unternehmen es um?
Damit ein Plattformprojekt erfolgreich ist, muss die Plattform korrekt implementiert werden. Da Unternehmen eine individuelle Anpassung ihrer Plattformen benötigen, ist es nicht möglich, einfach Produkte von der Stange zu kaufen. Gleichzeitig steht eine Vielzahl von Einzelprodukten und Open-Source-Projekten zur Verfügung, um die unzähligen Infrastruktur-, CI/CD-, Sicherheits- und anderen „zu erledigenden Aufgaben“ zu bewältigen, die bei der Bereitstellung und Ausführung von Software in der Produktion anfallen.
Dies bedeutet, dass Unternehmen stattdessen einige technische Arbeiten an den von ihnen gekauften Produkten oder der von ihnen eingeführten Open-Source-Software durchführen müssen. Aber die Frage ist: Wie viel vom eigenen Design ist angemessen? Plattform-Engineering kann von den Geschäftszielen ablenken, anstatt das zu fördern, was diese Organisationen auszeichnet.
Die Lösung für dieses Problem besteht darin, dass Unternehmen eine möglichst schlanke Plattform aufbauen. Plattformentwicklungsteams sollten nicht von Grund auf neu bauen; Plattformen sollten auf anderen Plattformen aufbauen. Unternehmen erwarten von ihren Software-Teams nicht, dass sie alles tun, vom Anschließen von Servern bis zur Bereitstellung von Produkten, und sie sollten schon gar nicht erwarten, dass Plattform-Engineering-Teams eine Plattform von Grund auf vollständig implementieren.
Stattdessen müssen diese Teams auf den Schultern von Giganten aufbauen. Um diesen Ansatz voranzutreiben, sollten Unternehmen so viele Platform-as-a-Service- (PaaS) und Software-as-a-Service- (SaaS) Tools wie möglich erwerben und diese bündeln, um eine fertige und funktionsfähige Plattform aufzubauen. Es gibt genug Arbeit, um die grundlegendste Plattformerfahrung zu pflegen, zu integrieren und zu aktualisieren. Dazu gehört die Erstellung von Schnittstellen und APIs, die von internen Ingenieuren verwendet werden, wodurch die Anbieterbindung gemindert werden kann.
In diesem Modell wird die Plattform jedes Unternehmens individuell entwickelt, sie basiert jedoch auf vorhandenen, unterstützten und käuflichen Tools. Mit diesem Ansatz können Unternehmen dem Dilemma „Bauen vs. Kaufen“ entkommen und sich auf die Feinabstimmung ihrer Plattform konzentrieren, um sie an die Anforderungen ihrer Organisation anzupassen.
Was muss passieren, damit es zur Norm wird?
Viele Unternehmen haben Schwierigkeiten bei der Einführung von DevOps, weil die Rollen und Verantwortlichkeiten überwältigend erscheinen können. Wenn Entwickler jeden Tag in der Produktion für alles in ihrem Stack verantwortlich sind, können sie sich in mühsamer Arbeit verzetteln, die keinen geschäftlichen Nutzen bringt. Doch traditionelle Architektur- und Betriebsteams messen die Entwicklereffektivität oft nicht, sodass Entwickler nur Tickets einreichen und warten müssen.
Damit das Plattform-Engineering erfolgreich ist, ist die volle Unterstützung der Organisation erforderlich. Um ein besseres Erlebnis für interne Benutzer zu schaffen, müssen Silos beseitigt werden. Plattform-Engineering erfordert für den Erfolg ein eigenes Team; es kann nicht einfach als Erweiterung der IT betrachtet werden.
Neben betrieblichen Änderungen erfordert das Plattform-Engineering einen kulturellen Wandel in den Entwicklungsteams, um neben einzelnen Funktionen auch nicht-funktionale Anforderungen wie Benutzerfreundlichkeit und Sicherheit zu priorisieren. Die Plattform sollte dabei helfen, das Richtige einfach zu machen, aber die Verantwortung sollte zwischen dem Lean-Plattform-Team und seinen Benutzern (dem Software-Entwicklungsteam) geteilt werden.
Wie immer, wenn ein Unternehmen seine Arbeitsprozesse überarbeitet, reicht es nicht aus, nur halbe Sachen zu machen. Unternehmen können das Plattform-Engineering nicht erfolgreich umsetzen, ohne die volle Unterstützung aller Entwickler im Unternehmen sowie die Zustimmung der leitenden Teammitglieder.
Warum sollten sich Entwickler darum kümmern?
Für große Softwareentwicklungsunternehmen ist es einfach, über große und komplexe Technologie-Stacks zu verfügen. Dies kann die Wartung zu einem Albtraum machen und zu langen, langsamen Release-Zyklen und stressigen Ausfällen führen. Durch die Einführung von Plattform-Engineering wird die Komplexität durch einen viel schlankeren Stack ersetzt, wodurch unwichtige oder umständliche Teile entfernt werden. Entscheidungsträger dürfen keine Angst davor haben, nicht benötigte Tools oder Umgebungen außer Betrieb zu nehmen – und diesen Prozess sogar zu automatisieren, sobald Entwickler der von ihnen verwendeten Plattform vertrauen. Tatsächlich kann die Außerbetriebnahme durch Automatisierung zu einem Teil des Plattformlebenszyklus werden und in bestehende Prozesse integriert werden, um Zeit und Geld zu sparen.
Ein Plattform-Engineering-Ansatz kann auch Entwicklern sowie Infrastruktur- und Betriebsteams erhebliche Zeiteinsparungen ermöglichen. Diese Teams können ganze Kategorien routinemäßiger Anfragen von Entwicklern eliminieren. Plattformteams automatisieren routinemäßige, sich wiederholende Aufgaben wie das Starten neuer Umgebungen, die Verwaltung der Infrastruktur, das Erstellen und Konfigurieren von Repositorys und die Handhabung von CI/CD-Pipelines, um Entwicklungszyklen zu glätten und mühsame Arbeit zu reduzieren.
Entwickler können Zeit und Aufwand sparen, indem sie die Arbeit auf die Plattform verlagern, was einen großen Anreiz für die Migration vorhandener Anwendungen auf die Plattform darstellen kann. Diese Vorteile können auch zu erheblichen Kosteneinsparungen für Unternehmen führen, da Entwickler produktiver werden und keine zusätzlichen Auftragnehmer und Mitarbeiter zur Erweiterung der Dienstleistungen erforderlich sind.
Plattform-Engineering für die Zukunft
Letztendlich besteht das Ziel des Plattform-Engineerings darin, Entwickler unabhängig von ihrem Team oder ihrer Funktion zu ermutigen, die Plattform zu nutzen, anstatt außerhalb davon zu experimentieren. Wenn Entwickler im Rahmen dieses Setups mit vollständig implementierten Toolchains und Workflows arbeiten, können sie sich auf die Programmierung konzentrieren, ohne sich Gedanken über die Infrastruktur machen zu müssen. Dies reduziert ihre tägliche Arbeitsbelastung erheblich und ermöglicht es ihnen, sich zu entfalten und nicht nur zu überleben.
Ein in den 1990er Jahren geborener Programmierer hat eine Videoportierungssoftware entwickelt und in weniger als einem Jahr über 7 Millionen verdient. Das Ende war sehr bestrafend! High-School-Schüler erstellen im Rahmen einer Coming-of-Age-Zeremonie ihre eigene Open-Source-Programmiersprache – scharfe Kommentare von Internetnutzern: Der inländische Dienst Taobao (taobao.com) verließ sich aufgrund des grassierenden Betrugs auf RustDesk und stellte die inländischen Dienste ein und startete die Arbeit zur Optimierung der Webversion von Java neu 17 ist die am häufigsten verwendete Java LTS-Version. Windows 11 erreicht weiterhin einen Rückgang. Open Source Daily unterstützt die Übernahme von Open Source Rabbit R1; Electric schließt die offene Plattform Apple veröffentlicht M4-Chip Google löscht Android Universal Kernel (ACK) Unterstützung für RISC-V-Architektur Yunfeng ist von Alibaba zurückgetreten und plant, in Zukunft unabhängige Spiele für Windows-Plattformen zu produzierenDieser Artikel wurde zuerst auf Yunyunzhongsheng ( https://yylives.cc/ ) veröffentlicht, jeder ist herzlich willkommen.