J'ai commencé ma carrière il y a 20 ans en tant qu'ingénieur logiciel. Beaucoup d'entre nous - et je sais que je ne suis pas le seul - ont été témoins de la croissance sans précédent du cloud public et continuent de l'être aujourd'hui.
Certains fournisseurs de services en nuage ont une opinion bien arrêtée sur la manière dont vous devez construire avec eux. Nous appelons cette approche " platform native". Ils veulent que vous construisiez d'une manière qui utilise leurs services et leurs outils, le tout au sein de leur écosystème. Mais les fournisseurs de cloud ne devraient pas dicter la manière dont vous construisez et déployez. Au contraire, vos charges de travail doivent être portables, en utilisant des outils ouverts et basés sur des normes qui vous permettent de les déployer et de les déplacer partout où il est utile de trouver la meilleure adéquation géographique, le meilleur prix ou la meilleure performance pour votre charge de travail.
Le parcours d'achat des développeurs d'aujourd'hui
J'ai commis des erreurs en choisissant le bon fournisseur de services en nuage. C'est le cas de beaucoup d'entre nous. Mais ces expériences, bonnes ou mauvaises, m'ont permis d'identifier des schémas dans le processus de sélection. J'ai ainsi découvert cinq étapes dans le parcours d'achat d'un développeur en matière d'informatique dématérialisée.
1. Découvrir. Que vous entendiez parler de quelque chose de nouveau lors d'un événement, que vous lisiez Stack Overflow ou un fil Reddit, que vous regardiez YouTube ou autre, un service en nuage suscitera votre intérêt parce que vous n'en avez jamais entendu parler auparavant. Et soudain, vous vous dites : "Qu'est-ce que c'est ? En quoi cela me concerne-t-il ? Comment cela peut-il m'aider ?
Il y a beaucoup d'autres questions à poser au cours de la découverte. Votre objectif doit être d'obtenir des réponses sur ce qui rend une offre de services dématérialisés unique, sur ce qui la différencie d'une offre similaire et sur la proposition de valeur spécifique qu'elle vous offre. Qu'il s'agisse d'un engagement de service ou d'autre chose, c'est là que vous posez la question "Pourquoi ?".
2. L'évaluation. À ce stade, nous avons dépassé le stade de l'interrogation et sommes pratiquement sûrs qu'il y a quelque chose. Il est maintenant temps de s'engager et d'évaluer ce que nous avons découvert. Ne prévoyez pas d'y consacrer beaucoup de temps. Il ne faut généralement que 15 à 20 minutes pour se plonger dans la documentation. Mais vous devrez vous y plonger plus profondément pour comprendre le service ou l'outil et évaluer les différences par rapport à ce que vous savez déjà.
Bien qu'il soit utile de comprendre exactement les services que vous évaluez, ne vous inquiétez pas si votre connaissance des autres fournisseurs de cloud est quelque peu limitée. Prenons l'exemple de notre offre Kubernetes gérée. Si vous connaissez les offres de la concurrence, vous pouvez établir des comparaisons entre celles-ci et Linode Kubernetes Engine.
Voici un extrait d'un cas d'utilisation d' Elliot Graebert, directeur de l'ingénierie chez le fabricant de drones Skydio.
"Les interfaces sont relativement identiques, ce qui rend impossible la désignation d'une meilleure interface. Leur conception est claire et nette, sans la prolifération de fonctionnalités qui prévaut sur AWS et Azure. À mon avis, cette simplicité contribue grandement à vous aider à entrer dans le système, à déployer votre application et à vous remettre à écrire du code. Il ajoute : "La vitesse incroyable de Linode pour démarrer de nouveaux clusters k8s plaira à certains publics, et leur temps de déploiement global des nœuds était solide."
3. Apprenez. Nous sommes maintenant prêts à passer à l'étape la plus cruciale. La raison en est que, pendant la phase d'évaluation, vous investirez un peu de temps, mais c'est à ce moment-là que vous investirez le plus de temps. En tant que développeurs, nous avons un million de projets en tête. Aujourd'hui, nous nous livrons à un exercice d'adaptation pour déterminer si cette offre de services dématérialisés en vaut la peine. Préparez-vous à investir des heures dans l'apprentissage. La plus grande question à laquelle il faut répondre est la suivante : Ce fournisseur de services en nuage et sa solution fonctionneront-ils pour mon prochain projet ?
4. Construire. Quel ingénieur n'aime pas poser ses mains sur un clavier ? Mais c'est à cette étape que les choses se gâtent souvent. Nous nous sommes conditionnés à construire des MVP (produits minimaux viables) alors qu'en réalité, nous devons construire des MLP, des "produits minimaux aimables".
Les MVP sont le strict minimum, et vous ne les aimerez pas forcément. De tous les MVP que j'ai construits au cours de ma carrière, je ne peux pas en citer un seul qui ait été adapté à la production. Dans mon rôle actuel, j'aime montrer aux développeurs comment créer un MLP. Le résultat est quelque chose qu'ils peuvent honnêtement évaluer si oui ou non l'effort qu'ils ont mis dans la construction en valait la peine.
5. L'échelle. Il y a tant de questions que vous poserez à ce stade. Lorsque vous comprendrez la notion d'échelle, vous voudrez savoir comment tirer parti de plusieurs régions, que ce soit pour répliquer des données d'un point à un autre en vue d'une reprise après sinistre ou simplement pour exister dans plus d'une région. Pensez à l'échelle non seulement du point de vue des processus, mais aussi du point de vue du personnel. Si vous avez besoin d'injecter plus de personnes dans ce processus, à quoi cela ressemble-t-il ?
Vous devez également comprendre le processus d'intégration. Que ce soit par l'intermédiaire d'un CLI ou d'une API, découvrez ce qui est disponible pour vous aider à automatiser. Nous sommes dans cette vague d'automatisation avec l'infrastructure en tant que code (IAC) en tête. Nous faisons plus avec moins parce que nous savons que les processus sont évolutifs et que les personnes ne le sont pas. Évaluez l'effort nécessaire pour mettre en place l'infrastructure et la faire évoluer.
Platform Native versus Cloud Native
Le choix de l'informatique dématérialisée restera un parcours évolutif. Nous devons commencer à l'envisager de manière plus objective. Lorsque je me suis aventuré pour la première fois dans l'informatique dématérialisée, j'ai construit exclusivement avec ces plateformes et ces outils. Toute la littérature technique disponible à l'époque concernait une plateforme particulière. Mais au fur et à mesure que j'évoluais en tant qu'ingénieur, j'ai commencé à construire de manière native, de sorte que je pouvais prendre ma charge de travail et la déplacer n'importe où, ce qui me donnait plus de contrôle sur les choses que je construisais. Et j'ai fait cela avec l'aide d'outils open source, qui m'ont permis d'adopter des normes unifiées telles que CI/CD, IaC et la conteneurisation.
Si tout cela correspond à votre façon de penser et que vous souhaitez construire de manière native, nous serions ravis d'en discuter avec vous. Contactez-moi ou n'importe quel membre de l'équipe pour discuter de votre parcours d'achat dans le cloud.
Commentaires