Um den Markt und die Wünsche unserer Kunden besser zu verstehen, spreche ich regelmäßig mit Software Developer, Technische Leiter, CTOs, Platform Engineers und anderen Menschen im Bereich Software Development.
Obwohl jedes Unternehmen einzigartig ist und jede Person eine eigene Sichtweise auf die Herausforderungen hat, mit denen ihr Unternehmen konfrontiert ist, sehe ich einige klare Muster. In diesem Blogpost will ich meine Learnings teilen.
Disclaimer: Das ist keine wissenschaftliche Abhandlung.
Die Einblicke, die ich hier beschreibe, sind Resultat meiner subjektiven Interpretation. Ich habe einen Fragebogen, den ich für meine Interviews nutze, weiche aber regelmäßig davon ab, aktualisiere und ändere ihn. Daher ist kein Interview wie das andere. Bei den von mir befragten Personen handelt es sich nicht um eine repräsentative Stichprobe, sondern hauptsächlich um Personen, die einem Interview zugestimmt haben, nachdem ich sie über LinkedIn kontaktiert hatte, so dass die Stichprobe eine starke Auswahlverzerrung aufweist.
Ich führte die Interviews durch, um zu lernen. Während ich meine Fragen auf die Themen Entwicklungsumgebungen, Entwicklungspraktiken und Herausforderungen im Softwareentwicklungsprozess konzentrierte, hatte ich kein klares Ziel, das ich mit diesen Gesprächen erreichen wollte. Daher sind die Erkenntnisse, die ich hier präsentiere, eine eher zufällige Sammlung von Mustern, die ich nach dem erneuten Lesen und Analysieren meiner Gesprächsnotizen erkannt habe.
Ich habe nur mit B2B-Softwareunternehmen gesprochen.
Hier sind meine wichtigsten Erkenntnisse:
#1 Kubernetes dominiert
Die Mehrheit nutzen Docker und Kubernetes, um die eigene Software auszuführen. Ich hatte erwartet, dass jüngere Unternehmen eher K8s nutzen, konnte das aber in meinen Interviews nicht bestätigen. Unternehmen, die kein K8s nutzen, sind selten. Die Gründe dafür sind Architekturen, die inkompatibel sind (Legacy Fat Clients) oder der Arbeitsaufwand zu hoch wäre, während die automatischen Skalierungs-Features nicht wirklich benötigt werden.
#2 Das lokales Deployment der Software, an der gearbeitet wird, ist ein Problembereich
Die meisten Personen gaben zu, dass die Ausführung der eigenen Software entweder nicht möglich oder extrem mühsam wäre. Die Hauptgründe dafür sind:
#3 Unzureichende Rechenleistung der Laptops
Ein gängiges Muster ist, dass einige (micro oder “midi) Services benötigt werden, um die Software ausführen zu können. Diese Services benötigen zu viel Rechenleistung. Laptops sind schlichtweg nicht dafür geeignet. Dies führt dazu, dass es fast schon Standard ist, dass Entwickler_innen sehr leistungsfähige Laptops bekommen, aber viele immer noch Probleme mit den Ressourcenanforderungen für die lokale Ausführung ihrer Anwendungen haben.
#4 Mehr als die Hälfter der Developer konnte ihre Software als Teil ihrer Entwicklungsumgebung nicht ausführen
Etwa ein Drittel der Personen sagen, dass das kein Problem darstellt. ⅔ sagen, dass es ein großes Problem ist.
#5 Klein und junge Unternehmen erwarten mehr von ihren Entwickler:innen
Umso kleiner und umso jünger das Unternehmen ist, umso wahrscheinlicher ist es, dass
- von Developern erwartet wird, dass sie lokales Deployment selbst einrichten und durchführen und gleichzeitig
- keinen standardisierten und keine bewährte Methode anbieten, um das zu tun. Developer müssen selbst herausfinden, wie das lokale Deployment funktioniert.
Skripte und Konfigurationsdateien werden zwischen Developern ausgetauscht, und es gibt gängige Muster, wie Entwickler_innen ihre Anwendungen lokal ausführen, aber es gibt sehr oft keine klare und standardisierte Methode zur Einrichtung eines lokalen Deployments, die für die Mehrheit funktioniert. Oft gibt es mehrere sehr unterschiedliche Möglichkeiten, eine Anwendung lokal zu deployen, die von verschiedenen Devs oder verschiedenen Teams verwendet wird.
#6 Hybride Setups, mit denen Entwickler_innen nur einen oder zwei Dienste lokal ausführen und sich mit anderen in einem entfernten Cluster verbinden, gelten als eine hervorragende Lösung
Aber ich habe nur von einem Unternehmen gehört, dass es so arbeitet. Dabei handelte es sich um ein Startup und ich habe mit dem CTO gesprochen, der für dieses Thema zuständig war. Über die Sichtweise der einzelnen Entwickler_innen kann ich deshalb nichts sagen, aber nach Aussage des CTO funktionierte dies sehr gut. Ich habe aber gehört, dass mehrere andere Unternehmen dies als Zielzustand genannt haben und es sogar als „magisch, fantastisch“ beschrieben haben (wörtliches Zitat). Ich habe eine Reihe von Blogposts darüber geschrieben, falls Sie mehr darüber erfahren möchten.
#7 Infrastrukturkosten sind eine großes Sorgenkind
Es ist oft zu teuer, jeder Person die Möglichkeit zu geben, ein eigenes Deployment für die Anwendung zu haben. Dies ist wiederum hauptsächlich auf den hohen Ressourcenbedarf der Anwendung selbst zurückzuführen, der eine lokale Ausführung oft unmöglich macht und eine Remote-Ausführung teuer macht. Teilweise oder hybride Deployments, bei denen einige Dienste von mehreren Personen gemeinsam genutzt werden, gelten als mögliche Lösung, sind aber aufgrund der Zustandsabhängigkeit der Dienste oder anderer architektonischer Besonderheiten oft nicht möglich.
#8 Es ist Standard, Dev-Tools nicht zu standardisieren
Die meisten Unternehmen lassen Entwickler_innen ihre eigenen Tools nutzen. Das reicht von IDEs zu Debuggern und auch Tools, die sie für das lokale Deployment nutzen. Viele stellen Tools zur verfügung, die von Entwickler_innen genutzt werden können, z.B. Lizenzen für Jetbrains IDEs etc. Diese Tools müssen aber nicht genutzt werden. Dies bezieht sich nur auf Werkzeuge, die von einzelnen Entwicklern_innen in ihrer eigenen Entwicklungsumgebung (d. h. auf ihren eigenen Laptops) verwendet werden.
#9 VSCode und Jetbrains sind die bei weitem am häufigsten genutzten IDEs
Das ist, denke ich, keine Überraschung.
#10 (Backend) Entwickler_innen mögen keine Browser-Only-IDEs
Die meisten Entwickler_innen haben eine bevorzugte IDE und wollen diese weiter nutzen. Die meisten sind offen, um andere IDEs auszuprobieren, aber sie müssen sie sofort mögen. Ansonsten wird nicht darauf umgestiegen. VSCode im Browser ist eine kleine Ausnahme, da Devs, die schon VSCode verwenden, sagen, dass sie bereit wären, die Browser-Version zu nutzen (oder sie zumindest ausprobieren würden).
#11 Der schnelle Release neuer Features wird immer über technischer Qualität priorisiert
Dieser Punkt wird von vielen Personen erwähnt und oft als Vorwurf vorgebracht.
#12 Technische Schulden gehören zum Leben dazu
Es gibt keine Codebase ohne technische Schulden. Viele Entwickler ärgern sich darüber, dass die Beseitigung technischer Schulden nur um der Beseitigung technischer Schulden willen keine Priorität genießt.
#13 Qualität ist ein Problem
Vor allem große, technisch ausgerichtete Organisationen, insbesondere solche, die schnell gewachsen sind, sehen sich mit schwerwiegenden Qualitätsproblemen bei dem von ihnen produzierten Code konfrontiert. Die Theorien über die Ursachen reichen von zu vielen Juniors, schlechtem Onboarding, mangelhaften oder fehlenden Tests, hoher Personalfluktuation bis hin zu einer zu hohen Komplexität in der Anwendung selbst. Nur eine Person gab an, dass ihr Unternehmen eine schlechte Developer Experience als Ursache ausgemacht hat: „Wenn das Testen zu lange dauert, wird es nicht gemacht.“
#14 Ausfälle sind üblich
Die meisten Leute, mit denen ich gesprochen habe, geben zu, dass es zu Ausfällen bei ihrer Software kommt. In den meisten Fällen sind die Auswirkungen vernachlässigbar – die Kunden bemerken es nicht einmal oder die Auswirkungen sind minimal. In meinen Gesprächen habe ich keine Geschichten über größere Ausfälle gehört, die zu Strafzahlungen oder Klagen gegen Unternehmen geführt hätten. Dennoch haben viele Entwickler_innen die Erfahrung gemacht, dass Software in Produktion kaputt geht und “all hands on deck” gerufen werden, um das Problem zu beheben.
#15 Es gibt kein Standard-Deployment-Modell
Die große Mehrheit der Unternehmen haben einige Elemente in ihrem Deployment-Modell, die sie selbst als „nicht standardisiert“ bezeichnen.
Am häufigsten ist ein hohes Maß an Variation bei Deployments, d. h. die Deployments der Software in Produktion unterscheiden sich voneinander. Je nach Geschäftsmodell (z. B. überwiegend SaaS mit einigen benutzerdefinierten Deployments oder jeder Kunde hat ein eigenes Deployment oder irgendetwas dazwischen) bedeutet dies Dutzende oder Hunderte von verschiedenen Konstellationen/Konfigurationen der Software, die in Produktion laufen.
Andere nicht standardisierte Elemente wurden mir als „monolithische Überbleibsel“, „On-Prem-Überbleibsel“, Hunderte von Microservices und kundenspezifische Komponenten beschrieben.
#16 Reines SaaS ist selten
In der Stichprobe von Leuten, mit denen ich gesprochen habe, gab es nur eine winzige Minderheit, die ein reines SaaS-Geschäftsmodell hatte, bei dem alle ihre Kunden ihr Produkt als SaaS nutzen. Die Mehrheit hatte entweder ein gemischtes Modell, bei dem einige Kunden dedizierte Instanzen hatten und andere Kunden das SaaS-Angebot nutzten. Eine ganze Reihe hatte dedizierte Instanzen (oft im Sinne von dedizierten Kubernetes-Clustern) für jeden einzelnen Kunden.
#17 Die meisten Unternehmen wissen nicht, wie ihre Entwickler_innen ihre Zeit verbringen
Eine meiner Standardfragen lautet: „Wie viel Zeit verbringen Sie bzw. die Entwickler_innen in Ihrem Team mit der Einrichtung, Wartung und Fehlerbehebung ihrer lokalen Entwicklungsumgebung?“
Die meisten haben darüber nachgedacht, bevor sie eine Antwort gegeben haben, was zeigt, dass dies etwas ist, worüber sie vorher wahrscheinlich nicht nachgedacht haben. Die Antworten waren allesamt Schätzungen, die auf Bauchgefühl beruhten. Keine einzige Person konnte mir eine Antwort geben, die auf einer tatsächlichen Zeiterfassung beruhte.
Auf meine Nachfragen zur Zeiterfassung teilten mir die meisten mit, dass sie entweder überhaupt keine Zeiterfassung vornehmen oder die Zeit nur als Gesamtarbeitszeit erfassen und nicht nach einzelnen Aufgaben aufschlüsseln. In den wenigen Unternehmen, in denen die Zeit für Tickets erfasst wurde, gaben die Entwickler_innen an, dass nur die Summe und nicht die für die einzelnen Tickets aufgewendete Zeit überprüft wird. Die Zeit, die für administrative Aufgaben, Besprechungen oder Tools aufgewendet wird, wird nicht gesondert erfasst, sondern für jedes Ticket, das in Bearbeitung ist.
#18 Jeder will großartiges UX
Wenn Entwickler_inne ein Tool nicht sofort lieben, werden sie es nicht benutzen. „Wenn die Erfahrung nahtlos ist, spielt es keine Rolle, was sich dahinter verbirgt.“
#19 Cloud Development Environments (CDEs) sind eine unbekannte Produktkategorie
Viele haben von Platform Engineering gehört. Wenige von CDEs.
Fazit
Wenn man sich das Bild ansieht, das sich daraus ergibt, sind einige der von mir genannten Punkte eindeutig miteinander verbunden. Kubernetes wurde genau dafür entwickelt, um die Ausführung von Anwendungen mit vielen Diensten und hohen Gesamtressourcenanforderungen zu ermöglichen.
Das sind genau die Art von Anwendungen, die auf einem Laptop mit begrenztem RAM und CPU nur schwer oder gar nicht ausgeführt werden können. Während K8s also das Problem der Ausführung solcher Anwendungen in Produktion gelöst hat, bleibt das Problem der Ausführung solcher Anwendungen für die Entwicklung in den meisten Unternehmen (mit denen ich gesprochen habe) ungelöst. Es gibt zwar Technologien, die dieses Problem angehen, aber der Open-Source-Teil dieser Technologien ist noch unausgereift und wird nicht in großem Umfang eingesetzt. Der kommerzielle Teil steckt sogar noch mehr in den Kinderschuhen. (Siehe auch meinen Blogbeitrag über Tools für die Entwicklung von K8s-basierten Anwendungen).
Wenn ich die Liste jetzt durchlese, habe ich das Gefühl, dass viele der von mir beschriebenen Erkenntnisse weder neu noch überraschend sind. Für mich war es aber wichtig zu erfahren, womit die interviewten PErsonen in dem Bereich zu kämpfen haben.
Ich habe den Eindruck gewonnen, dass sich die Softwareentwicklung derzeit in einer Art Wildwestzustand befindet. Ich habe gehört, dass die Situation besser war. Dass das Leben der Entwickler_innen in den 2000er und frühen 2010er Jahren einfacher gewesen ist, als die Standardanwendung ein Monolith war und Entwickler_Innen einfach nur Code schrieben, ihn in das Repository gepusht haben und von dort aus das Operations-Team die Arbeit übernahm. Ich kann das aus eigener Erfahrung nicht bestätigen (ich bin zu jung) und ich bin mir nicht sicher, ob es nur ein Beispiel dafür ist, dass Menschen oft glauben, dass die Dinge früher besser waren. (Im Allgemeinen waren sie es nicht.) Unabhängig davon, wie die Dinge in der Vergangenheit waren, ist mir klar, dass die Arbeit von Devs heute sehr komplex ist und dass viele damit zu kämpfen haben.
Was zeigen diese Interviews für uns als Unternehmen, das sich auf die Bereitstellung einer Automatisierungslösung und auf Tools konzentriert, um Devs das Leben zu erleichtern? Die Interviews bestätigen, dass viele Herausforderungen existieren, diese für viele Personen reale Probleme sind und unsere Tools diese Herausforderungen entsprechend aufgreifen und lösen.
Für unser CDE-Produkt Cloudomation DevStack haben wir die folgenden Schlussfolgerungen gezogen und umgesetzt:
- DevStack muss die Entwicklung von Software unterstützen, die in K8s in Produktion läuft
- DevStack muss ein hybrides Setup unterstützen, bei dem die CDE nur einen Teil der gesamten Anwendung enthält und diese mit anderen Services in einem gemeinsamen Cluster verbindet
- DevStack muss es Unternehmen ermöglichen, ein solches hybrides Setup zu erstellen, wenn es nicht bereits existiert
- DevStack muss es Unternehmen ermöglichen, die Infrastrukturkosten im Griff zu behalten. Wir haben beschlossen, dies zu unterstützen, indem wir:
- Einen klaren Überblick über die aktuellen Kosten bieten
- Einfache automatische Mechanismen zum Herunterfahren / in den Ruhezustand versetzen von ungenutzter Ressourcen, ohne die Arbeit der Entwickler_innen zu beeinträchtigen
- Bereitstellung von Vorlagen und Beratung, um Kunden bei der Erstellung ressourcenoptimierter, kosteneffizienter Entwicklungsumgebungen in der Cloud zu unterstützen (z. B. über ein hybrides Setup)
- DevStack muss es Devs ermöglichen, ihre bevorzugten Tools, einschließlich ihrer bevorzugten Offline-IDE, weiterhin zu verwenden. Wir tun dies, indem wir die Quellcode-Repositories auf den Laptop spiegeln und den Code und die IDE lokal belassen, während wir nur den komplexen und ressourcenintensiven Build und das Deployment der Anwendung an die CDE auslagern. Als netter Nebeneffekt ermöglicht dies auch die Arbeit bei sporadischer / schlechter Internetverbindung oder wenn Entwickler_innen offline sind, da sie immer Zugriff auf den lokalen Quellcode haben.
- DevStack muss „Nicht-Standard“-Komponenten und Deployment-Modelle unterstützen
- DevStack muss Entwickler_innen eine großartige UX bieten
Wenn Sie mehr darüber erfahren möchten,
- wie wir dies umgesetzt haben,
- oder an einem Test interessiert sind,
nehmen Sie Kontakt auf.
