Es entstand Platform-as-a-Service (PaaS). als führende Kraft im sich ständig weiterentwickelnden Bestreben, die Softwareentwicklung zu optimieren. PaaS geht auf das Jahr 2006 mit Force.com zurück, gefolgt von Heroku, AWS Elastic Beanstalk und DotCloud, das sich später in Docker verwandelte.
Während der PaaS-Sektor einen erheblichen Platz einnimmt 170-Milliarden-Dollar-Markt In der Cloud-Branche haben Unternehmen auch heute noch Probleme mit der manuellen Bereitstellung und dem Workload-Lifecycle-Management. Warum wird „Platform-as-a-Service“ nicht weiter verbreitet?
Bereitstellung eines PaaS-Erlebnisses für alle Workloads
PaaS-Plattformen könnten vielseitiger sein, und ich spreche nicht von Sprach- und Framework-Kompatibilität. Während PaaS oft als zentrale Anlaufstelle für die Bereitstellung beliebiger Anwendungen definiert wird, gibt es einen Haken. Mit Anwendungen sind hier üblicherweise 12-Faktor-Anwendungen gemeint.
Allerdings passen viele Workloads nicht ganz in die Form typischer Web-Apps; Sie bringen einzigartige Anforderungen mit sich, wie zum Beispiel Stapelverarbeitungsaufgaben, High-Performance-Computing-Workloads (HPC), GPU-intensive Aufgaben, datenzentrierte Anwendungen oder sogar Quantencomputing-Workloads.
Ich werde nicht auf alle Vorteile eingehen, die PaaS bietet. Dennoch sollten Unternehmen alle ihre Arbeitslasten so einfach wie möglich verwalten, und die Abstraktion ihrer Bereitstellung und Verwaltung ist der richtige Weg.
Es braucht einen Wandel. Erstens müssen Unternehmen, die das PaaS-Paradigma übernehmen, erkennen, dass es keine einheitliche Workload-Lösung geben wird. In einem aktuellen Diskurs zu diesem Thema bekräftigt der ehemalige Google-Ingenieur Kelsey Hightower diese Vorstellung von einem einzigen, allumfassenden PaaS bleibt unwahrscheinlich.
Unternehmen, die das PaaS-Paradigma übernehmen, müssen erkennen, dass es keine einheitliche Workload-Lösung geben wird.
Er benutzte auch Workload-API um ein Tool zu benennen, das dieses nahtlose „Hier ist meine App, führen Sie sie für mich aus“-Erlebnis bietet. Ich mag den Begriff „Workload-API“, weil er die Absicht klar zum Ausdruck bringt: eine bestimmte Workload auszuführen. Im Vergleich zu Platform-as-a-Service (PaaS), das genauer sein muss und zu der Verwirrung führt, dass PaaS eine Wunderwaffe für den Betrieb von irgendetwas ist. Ich werde diesen Begriff für den Rest des Artikels verwenden.
Die zweite Änderung für Unternehmen, die ein nahtloses Bereitstellungs- und Verwaltungserlebnis für alle ihre Workloads bieten möchten, besteht darin, zu berücksichtigen, dass jeder Workload über eine eigene Workload-API verfügen sollte. Zum Beispiel, Amazon Lambda könnte für Batch-Jobs verwendet werden, Vercel für Frontend, Vertex-KI für Modelle des maschinellen Lernens und Korifi für Web-Apps.
Sehen wir uns nun an, wie man Workload-APIs auswählt.