On parle beaucoup maintenant de la façon dont le nuage est passé, et juste d'un moyen coûteux d'envoyer des gens dans l'espace. Un article de blog de David Heinemeir Hansson a publié il y a quelque temps sur la façon dont il pense que le nuage est en grande partie de nouvelles couches de peinture sur de vieux trucs et veut donc le laisser derrière lui immédiatement. En tant que praticien qui a passé du temps sur et hors du cloud avec des entreprises grandes et petites, voici mes commentaires.

Maintenant, David n'est pas léger. Il est l'homme derrière Basecamp que des millions de personnes utilisent. Il est également l'homme derrière le framework Ruby on Rails largement utilisé par des dizaines de millions de personnes. C'est un auteur à succès. Il est même un véritable pilote de course certifié. Je n'ai jamais écrit de projet open source majeur et je ne fais du vélo que devant les hippodromes, alors soyons clairs - je tire sur des géants. Ma seule défense - j'ai fait certaines de ces choses à toutes sortes d'échelles. Je suis né une fois sur le nuage, j'ai passé du temps uniquement sur le sol et j'ai fait plusieurs allers-retours, ce qui, espérons-le, me donne une vue qui vaut la peine d'être vue.

L'argument central de Davi, à savoir qu'il ne faut pas louer si l'on peut acheter, est correct, mais seulement dans certaines circonstances. David lui-même en signale deux ; une nouvelle entreprise qui n'a pas encore de clients ou une entreprise établie avec une croissance très volatile où il dit que le cloud est meilleur. Cependant, son argument est que ce sont les deux SEULS cas où le cloud est meilleur, c'est là que je pense qu'il trébuche sur sa voiture de course.

Tout d'abord, obtenons un peu de contexte. David - il faut comprendre son point de vue. La société 37Signals est une petite entreprise — 7,9 millions de dollars de revenus et environ 95 employés. Il compte environ 14 millions d'utilisateurs par mois sur quelque 150 000 clients payants. C'est une entreprise rentable et en croissance constante qui n'est pas financée par du capital-risque et, contrairement à la plupart des autres entreprises technologiques, valorise une croissance rentable lente plutôt qu'une mise à l'échelle rapide. C'est quelque chose dont ils ont parlé à plusieurs reprises - leur idéal est l'épicerie locale plutôt que Slack ou NetFlix.

Cela fait de 37Signals une valeur aberrante. Pour cette raison, ce qui fonctionne pour eux n'est pas toujours ce qui fonctionne pour les autres, nous avons donc besoin de plus de nuances.

Mise à l'échelle sans le Cloud

L'article indique que Basecamp exécute déjà un service vaste et complexe, mais ce n'est pas vraiment correct. Pour autant que je sache sur le propre site de Basecamp et en cherchant sur Google d'autres sources, la société compte 8 à 10 millions de visiteurs par jour et 130 000 comptes. Ce n'est pas très grand; même RBL Bank où je travaille actuellement compte environ 7 à 8 millions de visiteurs par mois. En plus de cela, Basecamp n'a pas de transactions en temps réel, un traitement back-end relativement simple et des exigences de sécurité beaucoup plus simples.

David lui-même déclare : « Nous avons un modèle commercial qui est incroyablement compatible avec la possession de matériel et son amortissement sur de nombreuses années. Des trajectoires de croissance majoritairement prévisibles. Un personnel expert qui pourrait tout aussi bien utiliser ses talents pour faire fonctionner nos propres machines »

Cette différence est cruciale. Les charges de Basecamp sont probablement gérées par une poignée de serveurs, contre plus de 3 000 serveurs pour RBL Bank exécutant plus de 40 secteurs d'activité. Exécution d'une opération d'infrastructure complète avec des centaines de racks et des milliers de serveurs, sans parler des piles de routeurs et de commutateurs. Et, il y a tout ce besoin d'assistance 24h/24 et 7j/7. Une poignée de personnes peut-elle gérer cela?

Pour la plupart des CTO d'entreprise, la réponse est un non immédiat. - Tant de matériel s'épelle généralement. Il y a l'équipe serveur avec ses experts Linux, l'équipe réseau avec ses experts Cisco, l'équipe stockage avec ses experts EMC, l'équipe virtualisation avec ses experts VMWare, l'équipe base de données avec ses experts Oracle, etc. Beaucoup d'experts, beaucoup de superviseurs, beaucoup de complexité à affronter.

Cependant, je suis d'accord avec David; ce n'est pas la réalité d'aujourd'hui.

L'infrastructure d'aujourd'hui, même sur site, est généralement déjà virtualisée et des outils matures existent pour gérer chaque aspect de manière largement automatisée afin qu'une petite équipe (pas particulièrement experte) puisse faire - avec l'aide des OEM - tout ce qui nécessitait une armée. Rappelez-vous qu'il fut un temps où une machine Xerox nécessitait un opérateur certifié - aujourd'hui, un tout-petit peut appuyer sur le bouton et obtenir des réponses parfaites car la technologie a progressé, les interfaces ont été simplifiées et les pièces mobiles réduites. Quelque chose de similaire est arrivé aux serveurs et aux réseaux ; la plupart des DSI n'ont tout simplement pas remarqué. Tous les éléments de gestion intégrés simples disponibles sur le cloud aujourd'hui sont également facilement (et de manière fiable) disponibles sur site.

Amazon et Google ont eux-mêmes utilement ouvert la plupart des outils qu'ils utilisent, ainsi que les VMWare, les Nuntanix et les Dell du monde ont copié et mûri. Les hyperscalaires atteignent aujourd'hui des ratios serveurs/personnes de l'ordre de 10 000, ce qui signifie qu'une personne gère 10 000 serveurs. À l'échelle de l'entreprise un peu plus petite, il est toujours possible de gérer facilement quelques milliers de serveurs avec pas plus qu'une équipe de cricket. N'oubliez pas que nous ne parlons pas de la prise en charge du code d'application - c'est le même effort dans le cloud ou sur site - mais plutôt de la gestion de l'infrastructure réseau de stockage de calcul sous-jacente.

Il n'y a pas de magie. Une configuration matérielle simplifiée et virtualisée (tout est du même type) et des personnes polyvalentes et d'excellents outils de gestion - que la plupart des entreprises ont à portée de main si seulement elles ont essayé. NSE le fait dans IFSC Gift City, Zerodha le fait, les startups le font mais les entreprises établies ont du mal à sortir des paradigmes existants pour le faire de cette façon.

Il y a cependant une mise en garde (et elle pourrait être importante). Votre pile matérielle doit être uniforme et relativement nouvelle pour que cela fonctionne (ce qui est d'ailleurs en effet la réalité. La plupart des outils et des compétences deviennent compliqués ou impossibles à moins que vous ne vous soyez engagé dans des piles simplifiées et modernisées. Un peu comme Southwest Airlines n'ayant que un type d'avion qui est un élément clé de la stratégie utilisée par Southwest pour littéralement s'envoler vers les nuages.

Spiking sans le Cloud

La déclaration de David selon laquelle les entreprises sont stables ou volatiles est trop simple. Toute entité commerciale complexe a toujours plusieurs secteurs d'activité et plusieurs produits - et donc un mélange de produits stables et volatils. Les nouvelles entreprises peuvent se lancer à petite échelle et se développer rapidement, ou se lancer à grande échelle et se développer encore plus rapidement, ou avoir une croissance régulière à l'une ou l'autre échelle. De plus, il est difficile de prédire les pics à l'avenir.

Basecamp a le luxe d'une croissance régulière et de la prévisibilité des pics futurs. Après des années dans la même entreprise avec le même produit, il est peu probable qu'il y ait des pics inattendus. Ce n'est pas le cas de la plupart des entreprises complexes, où les nouveaux lancements et introductions constants rendent les choses plus volatiles. Même ici, cependant, David lui-même raconte à quel point le cloud était une aubaine lorsqu'ils ont lancé Hey – 300 000 utilisateurs en heures plutôt que les 30 000 prévus en mois.

Cela peut-il être réalisé sans le cloud ? Ici, la réponse est non (mais avec quelques clauses échappatoires). La mise à l'échelle sur site pour une seule entreprise signifie essentiellement laisser la capacité inactive ; il n'y a pas d'autre moyen d'obtenir de la capacité à la demande. Une partie de la charge peut être allégée en réaffectant dynamiquement les ressources des applications inactives aux applications occupées (une capacité dont disposent aujourd'hui la plupart des piles sur site modernes), mais la capacité sur site est finie et finalement relativement limitée.

Ce qui peut être fait aujourd'hui éclate dans le nuage. Même les entreprises traditionnelles ont commencé à le faire de manière limitée, en exécutant des tâches de gestion de données massives sur le cloud au lieu d'acheter le matériel nécessaire. Oracle et de nombreux autres équipementiers matériels offrent un moyen de se développer dans le cloud avec un paiement au fur et à mesure au-delà de la charge de base sur site - RBL Bank en a fait grand usage au cours des premiers jours de la mise à niveau de la banque de base, lorsque de nombreux travaux prenaient beaucoup plus de calcul pendant l'optimisation. Toutes les applications ne le prennent pas en charge, mais au fur et à mesure que les applications seront conteneurisées, cela deviendra de plus en plus la norme.

Bien sûr, si vous êtes en mode hypercroissance, toute cette capacité d'éclatement ne vous aidera pas ; vous préférez rester sur le cloud.

Nouvelles couches de peinture brillantes

David passe beaucoup de temps à parler de la façon dont les gens sont dupés par la magie d'AWS. Cela semble contredire le fait que les entreprises très sophistiquées sur le plan technologique (telles que Capital One, Nasdaq, Slack ou Netflix) continuent d'être sur le cloud et continuent de s'y engager. Netflix dépense environ 12 millions de dollars par mois aujourd'hui et s'est publiquement engagé à multiplier par 3 le nombre d'ici 2025. Slack s'est engagé à dépenser 400 millions de dollars. Il est peu probable que ces entreprises n'aient pas fait le calcul ou soient éblouis par les nouvelles couches de peinture.

Alors, qu'est-ce qu'un Netflix sait que Basecamp ne sait pas. Rien à dire, c'est juste une différence de point de vue. Quoi que vous fassiez sur le cloud, vous pouvez le faire sur site, et ce n'est plus aussi difficile ou exigeant en personnel qu'auparavant, mais c'est plus de travail que de le faire sur le cloud. Basecamp donne la priorité aux économies de coûts et est prêt à affecter quelques personnes supplémentaires à la gestion du service. Capital One, qui est beaucoup plus grand et aussi plus complexe, donne probablement la priorité à d'autres tâches par rapport aux économies de coûts du cloud ; ils peuvent, par exemple, choisir de déployer des personnes dans le développement de produits plutôt que dans la gestion de l'infrastructure. Il y a aussi une question d'échelle - passez à des centaines de milliers de serveurs et ce n'est plus quelques outils open source et une certaine automatisation.

Et puis il y a les services. Le cloud peut offrir de nombreux services entièrement prédigérés ; prenez simplement le service et ne vous souciez ni de l'application ni de l'infrastructure. Analyse, journalisation, base de données, backend mobile, stockage d'objets, service Web sans serveur, messagerie, tous sont disponibles à la demande, à la demande et avec une extrême fiabilité. Bien sûr, ils sont chers, mais même les personnes qui possèdent des voitures et des maisons louent chez Hertz et Marriott. L'astuce consiste à l'utiliser de manière appropriée et judicieuse, et à savoir quand quitter la location.

Résumé

L'adoption du cloud implique de nombreux facteurs, y compris le coût. Les entreprises qui ont besoin d'agilité doivent garder un pied dans le cloud. La gestion des problèmes non essentiels avec des compétences non essentielles finit par gonfler la main-d'œuvre d'une organisation. Cloud n'est pas une solution miracle - c'est un choix plus puissant dans un arsenal d'armes. L'époque où l'IAAS était l'objectif est révolue depuis longtemps. Passez au cloud uniquement si vous êtes prêt à être natif du cloud — conteneurisé, DevOps, mis à l'échelle horizontalement, etc.

Leçons clés :

• Ne placez pas aveuglément les choses sur le cloud. Considérez en permanence - pour chaque lancement de produit - si vous êtes plutôt Basecamp ou plutôt Netflix. Les nouvelles applications ou les applications hautement volatiles sont des candidats évidents, mais il en existe d'autres aussi. Et les choses changent, revoyez cela périodiquement pour voir où déplacer quoi.
• Soyez moins inquiet de ne pas pouvoir embaucher ou conserver des compétences sur site. Vous n'avez plus besoin de ces armées d'experts, vous pouvez donc former l'ensemble de votre personnel beaucoup plus largement et plus fréquemment. DevOps absorbe une grande partie de vos charges de travail d'experts (nécessite un changement culturel important).
• Nettoyez et simplifiez votre pile. La plupart de la complexité et des coûts sur site proviennent de l'achat de plusieurs variantes, fournisseurs et versions.- Be Southwest
• Déplacez-vous en interne pour les éléments les plus chers - dans AWS aujourd'hui, il s'agit de RDS (bases de données Postgres gérées), je vous suggère donc fortement de vous en éloigner. Développez des compétences en interne pour la gestion de Postgres et arrêtez d'avoir si peur des bases de données.
• L'époque où l'IAAS était l'objectif est révolue depuis longtemps. Passez au cloud uniquement si vous êtes prêt à être natif du cloud : conteneurisé, DevOps, mis à l'échelle horizontalement, etc. Lorsque cela est logique, utilisez certaines des valeurs ajoutées supplémentaires que le cloud offre gratuitement, telles qu'une bien meilleure surveillance, une mise à l'échelle automatique. Opérations AI, contrôle des coûts beaucoup plus fin (Netflix a fait des choses incroyables ici). Si vous n'êtes pas prêt à faire tout cela, remplacez votre CIO plutôt que votre infrastructure.