5 Unternehmen, die bereits Cloud Development Environments nutzen

Remote Development Environments (RDEs) bzw. Cloud Development Environments (CDEs) sind im Trend. Aber was kann man von RDEs erwarten? 5 Unternehmen und deren Ergebnisse stellen wir in diesem Blogpost vor.

Inhalt

#1 Slack

Slack hat ein Projekt für die Entwicklung einer Remote-Entwicklungsumgebung ins Leben gerufen. Das Projekt beseitigte die Beschränkungen der bestehenden Arbeitsabläufe von Slack und verbesserte die Produktivität der Entwickler_innen, indem bei Bedarf eine neue, isolierte Entwicklungsumgebung bereitgestellt wird. Die neue Lösung hat Einschränkungen der lokalen Entwicklungseinrichtung aufgehoben und die damit verbundene Wartung großteils beseitigt.

Ergebnisse:

Slack Build Duration — Vergleich der Dauer eines Builds zwischen remote und lokalen Entwicklungsumgebungen.

Wie wurde das Tool angenommen? Ende Januar 2022 nutzten 90 % der Entwickler_innen das Tool.

Zitate:

“I think remote dev is a dramatically better experience. It allows working on multiple branches at once and frees up tons of resources on our laptops.”

“I’m a huge fan – this work has greatly improved my productivity and my quiet laptop fans really thank you.”

Bericht: https://slack.engineering/remote-development-at-slack/

Mehr zum Thema:

#2 Uber

Uber stand vor folgender Herausforderung: Einer großen, fragmentierten Codebasis, die über Tausende von Repositories mit verschiedenen Programmiersprachen, Build- und Konfigurationstools verteilt war. Um die Produktivität der Entwickler_innen zu verbessern, implementierte Uber eine Remote-Entwicklungsumgebung mit dem Namen Devpod. Devpod führte zu schnelleren Build-Zeiten, verbesserte die Sicherheit, Einrichtungszeit und führte zu einer fast wartungsfreien Umgebung.

Ergebnisse:

“Das Diagramm unten zeigt, dass die Git-Statuszeiten von p95 durchgängig unter 4 Sekunden liegen, während die Git-Statusleistung auf Laptops anfangs mit den wachsenden Monorepo-Größen anstieg, bis wir den Dateisystemmonitor und Sparse Checkouts auf Laptops implementierten.“

“Ebenso bieten Devpods durchweg eine bessere Leistung für unsere längsten vollständigen Builds, wie das folgende Diagramm für die p95-Latenz für Go-Builds zeigt. Devpods bieten im Durchschnitt eine 2,5fache Verbesserung gegenüber Laptops bei längeren, komplexeren Builds und eine 1,8fache Verbesserung gegenüber Laptops bei durchschnittlichen Builds (p75).”

“Mit all diesen Verbesserungen haben wir eine organische Akzeptanz der Devpod-Nutzung in der gesamten Organisation festgestellt. Im November 2022 haben über 60 % der Uber-Softwareingenieure Devpods eingeführt.”

Bericht: https://www.uber.com/en-RO/blog/devpod-improving-developer-productivity-at-uber/

#3 Monday

Monday ist stark gewachsen und musste dadurch Freigabe-, Bereitstellungsprozesse und die Entwicklungsumgebung an die neuen Bedürfnisse anpassen. Neue Features werden bei Monday schnell veröffentlicht. Die Entwicklungsumgebung musste darauf ausgerichtet und flexibler werden. Bis die Umgebung einsatzbereit war, konnte es aber Tage dauern. Das führte zu Schwierigkeiten beim Onboarding. Außerdem gab es Probleme mit den benötigten Services – diese verlangsamten die Laptops der Entwickler_innen stark. “Irgendwann wurde es fast unmöglich, mehr als ein paar Microservices gleichzeitig auszuführen.” Eine neue Lösung musste her, die einfach, reproduzierbar ist, Ähnlichkeit mit der Produktionsumgebung aufweist und Laptops nicht abschmieren lässt. Monday setzte daraufhin auf ein Tool, das Cloud Development Environments zur Verfügung stellt. Die Produktivitätssteigerung ist laut Monday enorm. Der Onboarding-Prozess hat sich verbessert und die Entwicklungsumgebung sofort einsatzbereit.

Bericht: https://engineering.monday.com/development-environments-in-the-cloud/

#4 Stytch

Bei Stytch erkannte man 5 Bereiche, die zu Produktivitätsverlusten führten: Zu viele Dienste (services), zu viel kontextuelles Wissen war für die Entwicklung erforderlich, die Einrichtung ihres Dashboards war zeit- und personalintensiv und es gab Probleme mit der Konfiguration und den Tests. Über drei Lösungsansätze wurde nachgedacht: Beispielsweise, dass man alle Services in Docker lokal laufen lassen könnte. Am Ende erfüllten aber nur Cloud Development Environments alle Anforderungen. Die größten Vorteile so einer Umgebung sieht Stytch in der Zentralisierung, Skalierung und Effizienz.

Bericht: https://stytch.com/blog/remote-dev-1/

#5 LinkedIn

Vor allem Laptops mit begrenzter Leistung, CI-Build-Fehler und Inkonsistenzen zw. Lokalen- und CI-Builds waren bei LinkedIn ein Problem. Das wollte das Unternehmen mit Remote Development Environments lösen. Es handelt sich um Container, die alle Tools und Pakete enthalten.

Ergebnisse:

Reduzierung der anfänglichen Einrichtungs- und Build-Zeiten von 10-30 Minuten auf nur 10 Sekunden.

Durchschnittliche Erstellungszeit für eine unserer Anwendungen auf verschiedenen Betriebssystemen/Anzahl der Kerne. (c) LinkedIn

Bericht: https://engineering.linkedin.com/blog/2021/building-in-the-cloud-with-remote-development

Remote Development Environments vs. Local Development Environments

In diesem Vergleichs-Dokument erfahren Sie im Detail, was die wichtigsten Unterschiede zwischen Cloudomation RDEs und lokalen Entwicklungsumgebungen sind.

Jetzt herunterladen

Fazit

Mit Remote Development Environments sind typische Probleme gelöst worden, die Manager_innen und Entwickler_innen frustrieren, oftmals aber einfach hingenommen werden.

Die häufigsten Probleme sind:

Unzufriedenheit mit der Einrichtung und Wartung der Entwicklungsumgebung.
Laptops stoßen schnell an ihre Leistungsgrenzen.
Komplexes Onboarding.

Die hier aufgelisteten Unternehmen haben teilweise eigene Tools entwickelt. Das ist nicht immer möglich und rentabel. Mit Cloudomation erhalten Sie eine Lösung, mit der auch Sie – ohne internen Entwicklungsaufwand für das Tooling – mit Remote Development Environments starten können. Mehr darüber erfahren: Cloudomation Remote Development Environments.