Ich habe meine Karriere vor 20 Jahren als Softwareentwickler begonnen. Viele von uns - und ich weiß, dass ich nicht allein bin - haben das beispiellose Wachstum der öffentlichen Cloud miterlebt und erleben es auch heute noch.
Es gibt Cloud-Anbieter, die eine bestimmte Meinung darüber haben, wie man mit ihnen bauen sollte. Wir nennen diesen Ansatz " Platform Native". Sie wollen, dass Sie auf eine Art und Weise bauen, die ihre Dienste und ihre Werkzeuge nutzt, und zwar innerhalb ihres Ökosystems. Aber Cloud-Anbieter sollten Ihnen nicht vorschreiben, wie Sie bauen und bereitstellen. Stattdessen sollten Ihre Workloads portabel sein und auf offenen und standardbasierten Tools basieren, mit denen Sie sie überall dort bereitstellen und verschieben können, wo es sinnvoll ist, um die beste geografische, preisliche oder leistungsbezogene Lösung für Ihren Workload zu finden.
Die heutige Einkaufsreise von Entwicklern
Ich habe bei der Auswahl des richtigen Cloud-Anbieters Fehler gemacht. Das haben viele von uns. Aber diese Erfahrungen - gute und schlechte - haben es mir ermöglicht, Muster im Auswahlprozess zu erkennen. Und ich habe fünf Phasen im Cloud-Kaufprozess eines Entwicklers entdeckt.
1. Entdecken. Ganz gleich, ob Sie auf einer Veranstaltung von etwas Neuem erfahren, während Sie Stack Overflow oder einen Reddit-Thread lesen, YouTube ansehen oder wo auch immer, ein Cloud-Dienst wird Ihr Interesse wecken, weil Sie noch nie davon gehört haben. Und plötzlich denken Sie: Was ist das? Wie ist das für mich anwendbar? Wie kann es mir helfen?
Es gibt noch viele weitere Fragen, die Sie während der Erkundung stellen können. Ihr Ziel sollte es sein, Antworten auf die Frage zu erhalten, was ein Cloud-Angebot einzigartig macht, was es von etwas erkennbar Ähnlichem unterscheidet und welchen besonderen Nutzen es Ihnen bietet. Ganz gleich, ob es sich um eine Serviceverpflichtung oder etwas anderes handelt, hier sollten Sie fragen: "Warum?"
2. Auswertung. In diesem Stadium sind wir über das Fragen hinausgekommen und ziemlich sicher, dass es etwas gibt. Jetzt ist es an der Zeit, sich zu engagieren und zu bewerten, was wir entdeckt haben. Planen Sie keinen großen Zeitaufwand ein. Es dauert in der Regel nur 15 bis 20 Minuten, um in die Dokumentation einzutauchen. Aber Sie müssen tiefer eintauchen, um den Dienst oder das Tool zu verstehen und alle Unterschiede zu dem, was Sie bereits wissen, zu bewerten.
Es ist zwar hilfreich, genau zu wissen, welche Dienste Sie bewerten, aber machen Sie sich keine Sorgen, wenn Ihr Wissen über andere Cloud-Anbieter etwas begrenzt ist. Nehmen Sie zum Beispiel unser verwaltetes Kubernetes-Angebot. Wenn Sie mit den Angeboten der Konkurrenz vertraut sind, können Sie einige Vergleiche zwischen diesen und Linode Kubernetes Engine ziehen.
Hier ist ein Auszug aus einem Anwendungsfall von Elliot Graebert, Director of Engineering beim Drohnenhersteller Skydio.
"Die Schnittstellen sehen ziemlich identisch aus, so dass es unmöglich ist, eine als besser zu bezeichnen. Ihr Design ist klar und sauber, ohne die Funktionsfülle, die in AWS und Azure vorherrscht. Meiner Meinung nach trägt diese Einfachheit wesentlich dazu bei, dass Sie einsteigen, Ihre App bereitstellen und sich wieder dem Schreiben von Code zuwenden können." Er fügt hinzu: "Die unglaubliche Geschwindigkeit, mit der Linode neue k8s-Cluster hochfährt, wird einige Zielgruppen ansprechen, und die Gesamtzeit der Knotenbereitstellung war solide."
3. Lernen. Jetzt sind wir bereit für den wichtigsten Schritt. Der Grund dafür ist, dass Sie während der Evaluierungsphase einige Zeit investieren werden, aber dies ist der Zeitpunkt, an dem Sie die meiste Zeit investieren werden. Als Entwickler gehen uns eine Million Projekte durch den Kopf. Jetzt machen wir eine Art Anpassungsübung, um zu sehen, ob sich dieses Cloud-Angebot lohnt. Seien Sie darauf vorbereitet, Stunden in das Lernen zu investieren. Die wichtigste Frage, die es zu beantworten gilt, ist: Wird dieser Cloud-Anbieter und seine Lösung für mein nächstes Projekt geeignet sein?
4. Bauen. Welcher Ingenieur liebt es nicht, seine Hände auf eine Tastatur zu legen? Aber bei diesem Schritt gehen die Dinge oft schief. Wir haben uns darauf konditioniert, MVPs (minimal viable products) zu bauen, obwohl wir eigentlich MLPs, "minimal lovable products", bauen sollten.
MVPs sind das absolute Minimum, und Sie werden sie nicht unbedingt mögen. Von all den MVPs, die ich im Laufe meiner Karriere entwickelt habe, kann ich kein einziges nennen, das für die Produktion geeignet war. In meiner heutigen Rolle liebe ich es, Entwicklern zu zeigen, wie man einen MLP erstellt. Das Ergebnis ist etwas, bei dem sie ehrlich beurteilen können, ob sich der Aufwand, den sie in die Entwicklung gesteckt haben, gelohnt hat oder nicht.
5. Maßstab. Es gibt so viele Fragen, die Sie sich in dieser Phase stellen werden. Wenn Sie die Skalierung verstehen, wollen Sie wissen, wie Sie die Vorteile mehrerer Regionen nutzen können, sei es, um Daten von einem Punkt zu einem anderen für die Notfallwiederherstellung zu replizieren oder um einfach in mehr als einer Region zu existieren. Denken Sie bei der Skalierung nicht nur an die Prozesse, sondern auch an die Mitarbeiter. Wie sieht es aus, wenn Sie mehr Mitarbeiter in diesen Prozess einbinden müssen?
Sie sollten sich auch über den Integrationsprozess informieren. Ob über eine CLI oder API, finden Sie heraus, welche Möglichkeiten der Automatisierung es gibt. Wir befinden uns in einer Automatisierungswelle, bei der Infrastructure as Code (IAC) den Ton angibt. Wir können mit weniger mehr erreichen, weil wir wissen, dass Prozesse skalierbar sind, Menschen aber nicht. Bewerten Sie den Aufwand, der für die Einrichtung der Infrastruktur und die Skalierung erforderlich ist.
Plattform-Nativ gegenüber Cloud-Nativ
Die Wahl der Cloud wird auch weiterhin eine evolutionäre Reise sein. Wir müssen anfangen, sie objektiver zu betrachten. Als ich mich das erste Mal in die Cloud wagte, baute ich ausschließlich mit diesen Plattformen und Tools. Die gesamte damals verfügbare Fachliteratur bezog sich auf eine bestimmte Plattform. Aber als ich mich als Ingenieur weiterentwickelte, fing ich an, auf eine Cloud-native Art und Weise zu bauen, bei der ich meine Arbeitslast aufnehmen und an einen anderen Ort verlagern konnte, was mir mehr Kontrolle über die Dinge gab, die ich baute. Und das tat ich mit Hilfe von Open-Source-Tools, die es mir ermöglichten, einheitliche Standards wie CI/CD, IaC und Containerisierung zu übernehmen.
Wenn all dies mit Ihrer Denkweise übereinstimmt und Sie auf diese Weise Cloud-native Lösungen entwickeln möchten, würden wir gerne mit Ihnen sprechen. Wenden Sie sich an mich oder ein anderes Teammitglied, um Ihre Cloud-Kaufreise zu besprechen.
Kommentare