Cloud Development Environments (CDEs) sind eine junge Produktkategorie. Bisher gibt es auf dem CDE-Markt eine geringe Produktstandardisierung. Jeder CDE-Anbieter bietet ein einziges Featureset, wobei es zwischen den CDE-Produkten große Unterschiede in Bezug auf Technologien, Funktionen und Kernkonzepte gibt. In diesem Beitrag möchten wir erklären, wie sich DevStack von anderen CDE-Produkten unterscheidet – und für welche Softwareprodukte DevStack am besten geeignet ist.
#1 DevStack passt sich Ihren Entwickler_innen an
Die meisten CDE-Produkte unterstützen den Entwicklungsprozess mit einem bestimmten Stack an Tools. Wenn Entwickler_innen sich an diesen Prozess halten, werden sie mit der CDE problemlos zurechtkommen. Wenn die Entwickler_innen aber etwas anderes benötigen oder einfach ihre bewährten Arbeitsgewohnheiten nicht ändern möchten, können sie viele CDE-Produkte nicht verwenden.
Insbesondere beschränken die meisten CDE-Produkte Entwickler_innen in folgender Art und Weise:
- Nur eine bestimmte IDE oder eine Auswahl aus einer handvoll kompatibler IDEs können verwendet werden. Diese sind häufig browserbasiert.
- Der Quellcode ist nur auf der CDE verfügbar, worauf nur über die IDE zugegriffen werden kann.
- Eingeschränkten Zugriff auf das CDE-Dateisystem.
Dies bedeutet, dass Entwickler_innen bei vielen CDE-Produkten ihre Arbeitsweise grundlegend ändern müssen. Häufig wechseln sie zu einem rein browserbasierten Modell. Selbst wenn Entwickler_innen weiterhin ihre bevorzugte IDE verwenden können, sofern diese von der CDE unterstützt wird, haben sie häufig nur eingeschränkten Zugriff auf das CDE-Dateisystem. Das bedeutet, dass sie nur über die IDE mit der CDE interagieren können. Darüber hinaus können Entwickler_innen nicht ohne Internet arbeiten und sind auch vollständig in ihrer Arbeit blockiert, wenn die CDE-Plattform ausfällt.
Mehr dazu: Wie CDEs wirklich funktionieren – no bs
Cloudomation DevStack hingegen möchte den Umstieg auf eine CDE für Entwickler_innen so einfach und reibungslos wie möglich gestalten. Unabhängig von den bestehenden Präferenzen und Entwicklungsabläufen zielt DevStack darauf ab, sich anzupassen, indem DevStack folgendes unterstützt:
- Freie Wahl, wo der Source Code gespeichert wird, wobei die Standardkonfiguration den Quellcode sowohl auf dem Laptop der Entwickler_innen als auch auf der CDE gespeichert. Dies ermöglicht:
- Freie Auswahl der IDE oder des Editors. Mit lokalem Zugriff auf den Quellcode können Entwickler_innen jede beliebige IDE auswählen und lokal mit dem Quellcode arbeiten. Der Quellcode wird auf der CDE gespiegelt und alle Änderungen werden beim Speichern weitergegeben (nicht über ein Commit an die Quellcodeverwaltung). Ressourcenintensive Aufgaben wie das Debuggen werden weiterhin auf der CDE ausgeführt.
- Offline arbeiten. Mit dem Quellcode und der IDE auf dem Laptop der Entwickler_innen kann auch ohne Internetverbindung am Code gearbeitet werden. CDE-spezifische Funktionen wie das Ausführen von Builds, Tests oder das Debuggen des Codes sind offline zwar nicht verfügbar, aber Entwickler_innen können auch ohne Internet produktiv sein.
- Spiegelung anderer Artefakte, z. B. Logs, Berichte oder Dateien, die von der Software generiert werden, an der Entwickler_innen arbeiten. Das heißt: Es kann mit jedem beliebigen Tool auf dem Laptop gearbeitet werden.
- Randnotiz: Wenn an einer Software gearbeitet wird, die große Dateien produziert, wie z. B. Videodateien, erfordert das lokale Spiegeln dieser Dateien eine hohe Internetbandbreite. Hier ist es praktischer, direkt über die CDE darauf zuzugreifen. Wenn große Datenmengen für die Software benötigt werden, z. B. Beispiel- oder Testdaten, dann können diese Daten aufgrund der hohen Bandbreite, die mit CDEs verfügbar ist, schnell von entfernten Standorten innerhalb der Infrastruktur des Unternehmens auf die CDE übertragen werden.
- Vollständiger Zugriff auf die CDE. In der Standardkonfiguration sind DevStack-CDEs virtuelle Maschinen, auf die Entwickler_innen über SSH zugreifen können. Entwickler_innen haben vollständigen Zugriff auf das Dateisystem und auf alle auf der CDE laufenden Prozesse. Über die DevStack-CLI ist das Öffnen einer Terminalsitzung sehr einfach und ermöglicht, ähnlich zu arbeiten wie in einem lokalen Terminal.
DevStack zielt darauf ab, die Arbeitsabläufe von Entwicklern_innen so wenig wie möglich zu stören. Alles, was innerhalb der lokalen Entwicklung gut funktioniert – IDE und Quellcode – wird auf dem Laptop der Entwickler_innen belassen, während nur die Elemente in die CDE verschoben werden, die bei der lokalen Entwicklung oft schwierig sind – Erstellen und Deployment der Software, Testen, Debuggen und andere ressourcenintensive Aufgaben.
Mehr dazu: Wie die Standard-CDE-Architektur aussieht (Und was DevStack einzigartig macht)
#2 DevStack passt sich der zu entwickelnden Software an
Die meisten CDE-Produkte stellen CDEs als einzelne Container bereit. Das bedeutet, dass die Software, an der die Entwickler_innen arbeiten, in diesem einzelnen Container deployed werden muss, da sie sonst nicht Teil der Entwicklungsumgebung sein kann. Für kleine, einkomponentige Anwendungen wie einfache Websites oder Webanwendungen ist das kein Problem. Für jede Art von Mehrkomponentensoftware, Serversoftware mit großen Komponenten wie Datenbank-Backends und andere Hochleistungssoftware (die den Großteil der Unternehmenssoftware umfasst) ist das nicht machbar.
Eine zweite Gruppe von CDE-Produkten ermöglicht das Deployment von containerisierter Mehrkomponentensoftware. In solchen Fällen wird ein einzelner Entwicklungscontainer (der CDE) zusammen mit anderen Komponenten bereitgestellt, die die Software enthalten, an der Entwickler_innen arbeiten. Dabei wird normalerweise der gesamte Stack (Entwicklungscontainer und Anwendung) in einem Kubernetes- (oder OpenShift-)Cluster deployed. Dies ermöglicht zwar die Arbeit an containerisierter Mehrkomponentensoftware, trennt die Entwickler_innen aber in erheblichem Maße von der Anwendung. Der Zugriff auf andere Container innerhalb eines K8s-Deployments ist komplex. Aus diesem Grund verlassen sich lokale Deployments von containerisierter Mehrkomponentensoftware normalerweise auf Docker-Compose, um Container direkt auf dem Laptop zu deployen, ohne die zusätzliche Komplexitätsebene, die Kubernetes mit sich bringt. Docker-Compose-Workflows werden von den meisten CDE-Produkten nicht unterstützt.
Mehr dazu: Probleme mit der lokalen Entwicklungsumgebung: Ist Containerisierung die Lösung?
DevStack hingegen zielt darauf ab, die lokale Entwicklungsumgebung so originalgetreu wie möglich zu reproduzieren. In der Standardkonfiguration wird eine vollständige VM als Entwicklungsumgebung bereitgestellt, auf der jede Art von (containerisierter oder nicht containerisierter) Software deployed werden kann. Vorhandene Deployment-Skripte können wiederverwendet werden. Ressourcen der CDE können frei konfiguriert werden, mit der Option, sehr große CDEs zu deployen, GPUs zur CDE hinzuzufügen, nur einen Teil der Software auf der CDE zu deployen und eine Verbindung zu anderen Komponenten in einem gemeinsam genutzten Entwicklungscluster herzustellen oder auf mehreren VMs zu deployen.
Obwohl diese Flexibilität bedeutet, dass einige Anpassungen erforderlich sind, um eine CDE für ein bestimmtes Softwareprojekt zu konfigurieren, glauben wir, dass dies die beste Erfahrung bietet. Die Anpassung des Deployments der Software in die CDE nimmt für einen erfahrenen DevStack-Berater in der Regel 1–5 Tage für die Einrichtung und Übergabe in Anspruch. Dies ist erheblich weniger Zeit als die für viele andere CDE-Produkte erforderliche Zeit, um vorhandene Deployment-Modelle zu überarbeiten und neu aufzubauen, damit sie zum Deployment-Modell der CDE passen.
#3 Flexible Hosting-Optionen mit transparenter Preisgestaltung
Die meisten CDE-Produkte sind nur als SaaS verfügbar, wobei der Kunde auf die CDE-Plattform in der Cloud zugreift.
Dabei muss der Kunde dem CDE-Anbieter sein wertvollstes Gut anvertrauen: Den Quellcode, der in jeder einzelnen CDE in der Cloud-Infrastruktur des CDE-Anbieters verfügbar ist.
Darüber hinaus berechnen gängige CDE-Preismodelle den Benutzern_innen jede Stunde, die ein CDE läuft, mit einem erheblichen Aufschlag auf die tatsächlichen Infrastrukturkosten, die bei größeren Maschinentypen stark ansteigen. Dies macht SaaS-Angebote für Softwareprojekte mit mittlerem bis hohem Ressourcenbedarf sehr teuer.
Open-Source-CDE-Produkte können (meistens) selbst gehostet werden, bieten aber keine Unterstützung fürs Self-Hosting. In Anbetracht der Tatsache, dass CDE-Plattformen komplexe Softwareprodukte sind, entsteht für Benutzer_innen dadurch ein erheblicher Betriebsaufwand.
Die Managed-On-Premise-Verwaltung ist die beste Option aus beiden Hosting-Welten, die es Kunden ermöglicht, ihren Quellcode in ihrer Infrastruktur zu behalten und gleichzeitig die Wartung der CDE-Plattform an den CDE-Anbieter auszulagern. Diese Option wird nur von sehr wenigen CDE-Anbietern angeboten und ist in der Regel mit sehr hohen Gebühren für verwaltete Dienste verbunden.
Durch die Unterstützung verschiedener Hosting-Optionen für die DevStack-Plattform ermöglichen wir Organisationen, Infrastrukturkosten und Verwaltungsaufwand in Einklang zu bringen. DevStack ist wie folgt verfügbar:
- Vollständig selbst gehostet mit Support: Der Kunde hostet und wartet die DevStack-Plattform selbst. Der Kunde wählt, wo er die DevStack-Plattform hosten möchte: in seiner eigenen öffentlichen oder privaten Cloud-Infrastruktur oder in seinen eigenen Räumlichkeiten. Wir bieten unseren Kunden Support, um ihnen beim Einrichten und Verwalten von Updates und anderen Wartungsaufgaben für ihre DevStack-Installation zu helfen. Wir berechnen eine pauschale Supportgebühr und einen festen Satz pro CDE-Stunde, der unabhängig vom Maschinentyp oder der vom CDE verwendeten Infrastruktur ist.
- Vor Ort verwaltet: Der Kunde wählt, wo die DevStack-Plattform gehostet werden soll: in seiner privaten oder öffentlichen Cloud-Infrastruktur oder in seinen eigenen Räumlichkeiten. Der Kunde gewährt uns Zugriff auf die Infrastruktur. Wir installieren und verwalten die DevStack-Plattform für unsere Kunden. Wir berechnen eine pauschale Gebühr für verwalteten Service und Support sowie einen festen Satz pro CDE-Stunde, der unabhängig vom Maschinentyp oder der vom CDE verwendeten Infrastruktur ist.
- SaaS: Der Kunde greift in der Cloud auf die DevStack-Plattform zu, wo wir sie in unserer eigenen Infrastruktur hosten. Wir berechnen eine Pauschalgebühr für verwaltete Dienste und Support sowie einen Festpreis pro CDE-Stunde, der unabhängig vom Maschinentyp oder der vom CDE verwendeten Infrastruktur ist, und stellen unseren Kunden die Infrastrukturkosten separat und ohne Aufpreis in Rechnung. Dies ermöglicht es Kunden, leistungsstarke CDEs in einem SaaS-Angebot zu nutzen, ohne Kostenexplosion und mit voller Transparenz.
Einzelheiten finden Sie auf unserer Preisseite.
Fazit: Wann Sie sich für DevStack entscheiden sollten
DevStack unterscheidet sich von anderen CDE-Produkten folgendermaßen:
- Einfache Umstellung auf DevStack-CDEs, die nur geringe Änderungen in der Arbeitsweise der Entwickler_innen erfordert.
- Flexibilität bei den Deployment-Modellen der auf den CDEs entwickelten Software, mit Support für hochleistungsfähige, nicht containerisierte und andere nicht standardmäßige Software.
- Flexible Hosting-Optionen mit transparenter Preisgestaltung, die DevStack für Softwareprojekte mit mittlerem bis hohem und/oder speziellem Ressourcenbedarf erschwinglich machen.
Folglich eignet sich DevStack am besten für bestehende Softwareprojekte mit
- mittleren bis großen Entwicklungsteams, die von einer reibungslosen und mühelosen Umstellung profitieren,
- komplexe oder nicht standardmäßige Deployments, die nicht einfach in einem einzigen Container oder als mehrere Container in einem Kubernetes-Cluster deployed werden können,
- mittleren bis hohen Ressourcenbedarf, der mit den Preismodellen von SaaS-CDEs unerschwinglich teuer werden kann.