Foto: Postmodern Studio - shutterstock.com
Bei Heroku gibt es immer ein "aber". Seit 15 Jahren höre ich, wie Heroku als "magisch" beschrieben wird, als der Goldstandard für Entwicklererfahrung. Allerdings scheint Heroku seiner Mythologie nicht gerecht werden zu können. Damit will ich nicht sagen, dass Heroku auf andere Services und Produkte keinen beträchtlichen Einfluss hatte - aber es gibt einen Grund, warum Kubernetes und nicht Heroku zunehmend zum Standard wird, wenn es darum geht, Applikationen zu erstellen und zu skalieren. Manche meinen, Heroku sei seiner Zeit voraus gewesen. Das mag sein. Vielleicht war auch einfach der Preis für die magische Entwicklererfahrung zu hoch, um in der modernen Unordnung des Enterprise Computing zu funktionieren.
Goldenes Developer-Experience-Zeitalter
Weil das Unternehmen kürzlich die Abschaffung seines kostenlosen Angebots angekündigt hat, ist Heroku wieder in den Schlagzeilen. Der Grund: Es war zu viel Arbeit, dem Missbrauch seines kostenlosen Offerings Einhalt zu gebieten. "Unsere Produkt-, Technik- und Sicherheitsteams betreiben außerordentlichen Aufwand, um Betrug und Missbrauch der kostenlosen Heroku-Produktpläne in den Griff zu bekommen", sagte Bob Wise, General Manager von Heroku und Executive Vice President bei Salesforce (das Heroku Ende 2010 übernommen hat).
Anstatt Katz und Maus mit Kryptobetrügern zu spielen, hofft das Unternehmen, seine Investitionen seien bei seinen Kunden besser aufgehoben - von denen es wahrscheinlich weniger gibt, als es sein sollten. Das klingt jetzt vielleicht nach Kritik, ist aber nicht so gemeint. In meinem Umfeld wurde Heroku bisher ausschließlich dafür gelobt, wie es die Bereitstellung von Anwendungen revolutioniert hat. Das dauerte vor Heroku genauso lange - oder gar länger - als die Erstellung.
Das Problem, war laut Jason Warner, zwischen 2014 und 2017 leitender Entwicker bei Heroku, dass "Heroku nie fertig war." Die Übernahme durch Salesforce war dabei nicht hilfreich - dadurch wurde die Entwicklung von Heroku auf Eis gelegt. Der Ex-Chefentwickler drückt es folgendermaßen aus: "Heroku war für eine Reihe von Anwendungen magisch. Ein fertiges Heroku hätte für viele weitere magisch sein können."
Abgeschottet von Innovation
Trotz des Einflusses, den Heroku auf die Branche hat, scheint es, als sei das Unternehmen bei Salesforce in ein schwarzes Loch gefallen.
"Ich weiß es nicht genau, aber ich vermute, dass die Zahl der Mitarbeiter bei Heroku heute geringer ist als vor fünf Jahren", twitterte Craig Kerstiens, Produktleiter bei Crunchy Data und ehemaliger Heroku-Mitarbeiter. Wenn man bedenkt, dass heute mehr Anwendungen auf Heroku laufen als vor fünf Jahren, ist das überraschend. Es ist anzunehmen, dass Heroku immer ein wenig orthogonal zum Hauptgeschäft von Salesforce ausgerichtet war, was es für das Unternehmen schwierig machte, die benötigten, internen Mittel zu erhalten. Als ursprüngliches, aber geschlossenes Entwicklererlebnis konnte Heroku nie mehr sein, als Salesforce daraus machen wollte. Es gab keine Chance auf Investitionen von außen, was sich mit steigendem Community-Engagement für Kubernetes zunehmend als Problem erwies. Dabei hätte alles ganz anders laufen können, meint zum Beispiel Entwickler Scott Williams:
Very yes. It had a ton of potential and was more intuitive than openshift v2. If it had gone open source around the time Kubernetes came out, we'd probably all still be taking it seriously.
— Scott Williams ?? (@vwbusguy) August 27, 2022
James Ward von Google sieht das Hauptproblem anderweitig verortet:
I believe that by far the biggest issue was the lack of an escape hatch. When a team/org reached the limits of Heroku the only option was to do all the things Heroku provided - infra automation, ops, etc. With Kubernetes there are useful abstractions and escape hatches.
— James Ward (@_JamesWard) August 27, 2022
Daher hat der Entwickler Jeremy Chone wohl recht, wenn er schreibt:
Similar to #GoogleAppEngine. PaaS makes projects easy to start hard to finish.
— Jeremy Chone (@jeremychone) August 27, 2022
Kubernetes hit it right.#Heroku #PaaS #CloupApp #AWS #Kubernetes
Unternehmen neigen dazu, auf chaotische Magie zu setzen: Ein Enterprise-Entwickler mag eine PaaS mögen, die hochgradig eigenwillig ist und die Erstellung einer bestimmten Anwendungsklasse unglaublich einfach macht. Ein Enterprise-Entwicklungsteam sollte jedoch daran denken, Tools erweitern und anpassen zu können, um der chaotischen Realität der bestehenden und zukünftigen Infrastruktur Rechnung zu tragen. (fm)
Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation Infoworld.