Platform Engineering: Open-Source vs. kommerzielle Tools

Wo sind kommerzielle Tools unverzichtbar?

Es ist durchaus möglich, eine interne Entwicklungsplattform ausschließlich mit Open-Source-Komponenten aufzubauen. Genau das tun viele Organisationen bereits.

Die häufigsten Bereiche, in denen dennoch kommerzielle Tools eingesetzt werden, sind:

• Cloud-Infrastruktur und Managed Services: Sofern man nicht über eine eigene Bare-Metal-Infrastruktur verfügt oder selbst Cloud-Anbieter ist, ist es sehr wahrscheinlich, dass man kommerzielle Cloud-Angebote nutzt. Warum? Weil es für die meisten Organisationen einfach günstiger ist, bedarfsgerechte Cloud-Dienste zu nutzen, als physische Infrastruktur zu kaufen.
• Da Software häufig mit Cloud-Angeboten gebündelt ist (z. B. das gesamte AWS-Universum an Tools), ist es auch sehr üblich, zumindest einige kommerzielle Softwareangebote von Cloud-Anbietern zu verwenden – zum Beispiel Container-Registries oder Managed-Git-Dienste. Warum? Vor allem aus Gründen der Bequemlichkeit: Da diese Softwareangebote eng mit dem Cloud-Service integriert sind, ist ihre Nutzung meist sehr einfach.
• IDEs und andere Entwickler-Tools (die zum Teil lokal verwendet werden und daher streng genommen nicht zur Platform-Engineering-Toolkette gehören) werden auch sehr häufig in ihrer kommerziellen Variante in großen Engineering-Organisationen eingesetzt. Warum? Weil sie häufig eine bessere Nutzererfahrung bieten als Open-Source-Alternativen.

Darüber hinaus sind Open-Source-Tools die gängigsten Lösungen für Container-Orchestrierung, CI/CD, Secret Management, Logging usw. Aber in all diesen Kategorien gibt es auch kommerzielle Tools – und in vielen Fällen ergibt es absolut Sinn, ein kommerzielles Tool anstelle einer Open-Source-Lösung oder ergänzend dazu zu verwenden.

Mehr erfahren:

• 3 Platform Orchestration Tools vorgestellt
• 5 Internal Developer Portale (…und was Software Engineers über sie sagen)
• Platform Engineering Tools zum Aufbau einer IDP

Wann sollte man kommerzielle Tools in Betracht ziehen?

Kommerzielle und Open-Source-Tools, die dieselben Probleme lösen, unterscheiden sich typischerweise in folgenden Punkten:

• User Experience (UX): Open-Source-Tools sind oft hervorragend darin, ein spezifisches Problem zu lösen. Ihre Entwicklung ist jedoch häufig nicht auf eine gute Nutzererfahrung ausgerichtet. UX ist oft der Punkt, an dem sich Open-Source- und kommerzielle Tools am deutlichsten unterscheiden. Ob sich eine gute UX lohnt, hängt stark von der Nutzergruppe und ihren Präferenzen ab. Tools, die nur von einem kleinen, hochqualifizierten Platform-Engineering-Team verwendet werden, benötigen eine weniger ausgefeilte UX als Tools, die von allen Engineers im Unternehmen genutzt werden sollen.
• Ein Tool statt viele: Ein Grund, warum Platform Engineering ein so komplexes Thema ist, liegt in der Vielzahl an Tools im Stack. Open-Source-Tools neigen dazu, jeweils ein sehr spezifisches Problem zu lösen. Das bedeutet, dass man viele einzelne Tools einsetzt, die jeweils nur einen kleinen Bereich abdecken. Diese miteinander zu kombinieren, kann herausfordernd sein. Zwar bieten viele Open-Source-Tools APIs zur Integration, diese müssen aber eingerichtet, gewartet und verstanden werden – zusätzlich zum Wissen über jedes einzelne Tool. Ein großer Vorteil vieler kommerzieller Tools ist, dass sie eine breite, gut integrierte Feature-Palette bieten, wodurch sich die Anzahl der benötigten Tools und die Komplexität des gesamten Stacks erheblich reduzieren lässt. Besonders bei kleinen Teams kann der Einsatz eines einzigen kommerziellen Tools anstelle von zehn, fünf oder auch nur zwei Open-Source-Komponenten den Alltag deutlich vereinfachen.
• Einzigartige Funktionen: Viele kommerzielle Tools bieten sogenannte „Killer-Features“, die in Open-Source-Lösungen schlicht nicht vorhanden sind.
• SLAs, Support und Services: Dies ist eines der häufigsten Argumente für kommerzielle Tools. Es ist aber nicht mehr uneingeschränkt gültig, da es mittlerweile auch Dienstleister gibt, die Managed Services, Support und SLAs für viele beliebte Open-Source-Tools anbieten. Zudem bieten viele kommerzielle Anbieter eine Open-Source-Variante ihrer Software an. Wenn man aber ohnehin Dienstleistungen und Support für ein Open-Source-Tool einkauft, kann man auch gleich ein kommerzielles Tool wählen und erhält direkten Herstellersupport dazu.

Was bedeutet das für dich?

Open-Source-Tools sind eine gute Wahl, wenn du:

• ein hochqualifiziertes und gut aufgestelltes Platform-Engineering-Team mit tiefer Open-Source-Expertise hast und die Zeit hast, dieses Wissen aufzubauen,
• mehr Budget für Personal und weniger für Softwarelizenzen zur Verfügung steht.

Kommerzielle Tools sind die bessere Wahl, wenn du:

• ein kleines Platform-Team und/oder viele Junior Engineers hast,
• weniger Budget für Personal (oder schlicht weniger Personal) und mehr Budget für Softwarelizenzen zur Verfügung steht.

Der Gesamtaufwand ist bei Open-Source-lastigen Stacks oft höher, weil mehr (teures) Fachpersonal benötigt wird, um sie aufzubauen und zu betreiben. Auch wenn das allgemein bekannt ist, entscheiden sich viele Organisationen dennoch für Open-Source-Tools mit dem Argument, sie seien „kostenlos“. Open-Source-Tools sind definitiv günstiger als Lösungen von IBM, Oracle oder Broadcom – doch bei spezialisierten DevOps- oder Platform-Engineering-Tools kleinerer oder mittelgroßer Anbieter liegt die Kosten-Nutzen-Rechnung oft klar bei der kommerziellen Lösung.

Eigenwerbung: Wann sollte man Cloudomation in Betracht ziehen? 😉

Cloudomation ist ein Python-Framework für Platform Engineering. Es ist dafür gedacht, im Zentrum deiner internen Entwicklungsplattform (IDPs) zu stehen – wir nennen es gerne das „Platform-Backend“ oder den „Platform-Orchestrator“. Für diesen Typ von Komponente gibt es bislang nur sehr wenige Open-Source-Tools.

Stattdessen setzen viele IDPs entweder:

• auf einen einzigen Infrastruktur-Typ, z. B. nur Kubernetes und entwickeln Services für die IDP direkt innerhalb dieser Infrastruktur – was weniger Orchestrierung und Integration erfordert, oder
• auf viel manuell geskripteten Glue Code, der über verschiedene Tools verteilt ist (z. B. Custom Resource Definitions in Kubernetes, zahlreiche Terraform-Templates, manuell gepflegte Bash-Skripte, etwas Automatisierung in Jenkins usw.), und/oder vollständig individuell aufgebaut wurde – d. h. eine Art benutzerdefinierte Orchestrierungskomponente wurde von Grund auf geskriptet (häufig angefangen mit einem cronjob 😅), ständig erweitert und muss typischerweise intensiv gewartet werden.

Es ist vollkommen normal, so zu starten. Besonders der Fokus auf einen bestimmten Infrastruktur-Typ zu Beginn ist sinnvoll. Aber es kommt der Punkt, an dem die zu orchestrierenden Abhängigkeiten so komplex werden, dass:

• Die meisten Probleme mit IDP-Services nicht innerhalb einer Komponente auftreten, sondern zwischen ihnen: Falsche Konfigurationen werden als Input übergeben, Abhängigkeiten fehlen oder sind inkompatibel, Services, die voneinander abhängen, werden nicht in der richtigen Reihenfolge deployed usw.
• Die Ursache solcher Probleme zu finden, kostet viel Zeit. Sie zu beheben ist noch schwieriger – häufig bedeutet es, eine ohnehin schon komplexe Logik um einen weiteren Spezialfall zu erweitern. Wenn sich diese Logik über verschiedene Tools und Dateien verteilt, wird die Wartung extrem aufwendig.
• Ein Großteil der Arbeit im Platform-Engineering-Team fließt in die Pflege und Erweiterung von Glue Code, anstatt in die Entwicklung neuer Services. Viele Ressourcen sind gebunden, um Konfigurationsfehler und ähnliche Probleme zu debuggen.

Kurz gesagt: Glue Code ist der intransparenteste und gleichzeitig fragilste Teil der meisten IDPs.

Wenn du dich in einer solchen Situation wiederfindest, solltest du dir Cloudomation ansehen. Wir haben das Tool gebaut, um genau dieses Problem zu lösen, und macht ihn vom Problem zur Stärke.

Der Zweck von Cloudomation ist es,

• deinen Tool-Stack technologieübergreifend auf eine wartbare und transparente Weise zu integrieren
• und dir zu ermöglichen, eine Abstraktionsschicht über deinen Stack zu bauen, mit der du standardisierte Services für andere Stakeholder bereitstellen kannst – selbst wenn dein Stack auf unterschiedlichen Technologien basiert.

Aufgeschlüsselt nach den oben genannten Argumenten, hier die Gründe, warum es sinnvoll sein kann, Cloudomation zusätzlich zu den bereits eingesetzten Open-Source-Tools zu nutzen:

1. Ein Tool statt viele: Dank des breiten Funktionsumfangs – inklusive Workflow-Automatisierung, State-Management, API- und CDE-Management – ermöglicht Cloudomation es Platform Engineers, viele Herausforderungen in einem einheitlichen Framework zu lösen, anstatt mit einem Flickenteppich aus verschiedenen Open-Source-Tools zu arbeiten. Ein Framework für viele Anwendungsfälle bedeutet: schnellere Umsetzung und wesentlich einfachere Wartung der Plattform. Mehr darüber, welche Tools durch Cloudomation Engine ersetzt werden können, findest du in unserer Doku.
2. Einzigartige Funktionen: Es gibt Aufgaben, die Cloudomation erledigen kann, aber Open-Source-Tools nicht.
   1. Custom-Objects mit Custom-Lifecycles: Ähnlich wie Custom Resource Definitions in Kubernetes – aber viel flexibler – ermöglichen dir Custom Objects eine Abstraktionsschicht zu schaffen, die vollständig individuell und nicht an eine bestimmte Technologie gebunden ist. Damit bekommst du Lifecycle-Management, State-Managementund vollständige Transparenz – egal, ob du Deployments, Testdaten, Applikationen, Server oder etwas ganz anderes bereitstellen willst. Das ist unschätzbar wertvoll, wenn du komplexe Infrastruktur über verschiedene Clouds und Technologien hinweg nachhaltig managen willst.
   2. Stabilität und Skalierbarkeit durch Savepoints: Wie Python auf Cloudomation ausgeführt wird, unterscheidet sich grundlegend von anderen Plattformen. Bei jedem Aufruf unserer Python API speichern wir den aktuellen Ausführungszustand deines Skripts. Das bedeutet: Skript-Ausführungen können jederzeit unterbrochen und später fortgesetzt werden. Das macht Cloudomation besonders robust und einfach skalierbar.
   3. Cloudomation AI Assistant: Viele AI-Assistenten bieten Code-Vervollständigung oder helfen bei allgemeinen Python-Fragen. Unser integrierter Cloudomation Assistant kennt die spezifische Funktionalität von Cloudomation und hat Tools, mit denen er direkt Ressourcen erstellen und Code in Cloudomation schreiben kann. Auch, wenn Cloudomation ein mächtiges und komplexes Tool ist, ist es durch den AI-Assistenten einfach zu bedienen.
3. Services & Support, SLAs: Bei uns bekommst du nicht nur Standardsupport, sondern eine persönliche Ansprechperson aus unserem dedizierten Consulting-Team.

Zusammenfassung

Während Open-Source-Tools ein zentraler Bestandteil der meisten internen Entwicklungsplattformen sind, ist es sinnvoll, auch kommerzielle Tools einzusetzen. Besonders wenn das Platform-Engineering-Team klein oder stark ausgelastet ist, können kommerzielle Tools helfen, den operativen Aufwand deutlich zu reduzieren.

Als ein Python-Framework für Platform Engineering ermöglicht Cloudomation es Platform Engineers, auf einfache und visuelle Weise eine Abstraktionsschicht zu erstellen, die aus benutzerdefinierten Objekten besteht – etwa zur Darstellung von Infrastruktur und Services. Diese Abstraktionsschicht ist direkt mit Workflow-Automatisierung und Lifecycle-Management in der Cloudomation-Plattform verknüpft und soll technologie- und cloudübergreifend funktionieren.

Damit reduziert Cloudomation effektiv die Komplexität beim Aufbau interner Entwicklungsplattformen und befähigt Platform-Engineering-Teams mit begrenzten Ressourcen, eine komplexe Infrastruktur und umfangreiche Tool-Stacks nachhaltig zu managen.