Ange et démon: Amazon Web Services

Cela fait maintenant plusieurs années que je joue avec AWS. Au fur et à mesure de mes expériences, et le recul que j’ai pu prendre, j’ai constaté que mes avis ont souvent changé. Le fait est qu’AWS est aujourd’hui un acteur majeur dans le cloud, les start-ups ou les services à fort trafic.


La claque

Le virage Hosting/AWS fait souvent l’effet d’une claque. La première erreur que l’on fait quand on essaie AWS, c’est d’avoir un comportement d’admin classique: on a une VM avec un prix fixe, et on fait ce qu’on veut.

C’est faux chez AWS. En réalité, on a une VM avec un prix bas variable, et si on fait ce qu’on veut, on a plutôt intérêt à avoir une carte bleue illimitée. Le premier mois d’utilisation chez AWS, c’est souvent un rappel à l’ordre:

Le cloud est une solution d’Infrastructure as a Service, avec une capacité de montée en charge, que l’on peut manipuler avec du code, qui s’adapte à nos besoins, mais qui, surtout, est facturé à la consommation.

J’avoue, mon premier mois de conso, c’était une facture de 1000 euros. C’était pas exprès , j’ai voulu faire du benchmark de grosse instance, et bêtement, j’ai laissé les instances tourner tout un week end. Boulette.

A cette époque, le billing dashboard n’existait pas. Le détail des consos tenait dans un CSV anecdotique, il n’y avait pas d’alerting, pas de consolidation de facture. Donc on prenait conscience de la facture… quand on la recevait. Un poil trop tard pour rectifier le tir.

A cette époque, c’était moins facile de faire sauter les limitations du nombre d’EC2. On n'hésitait pas à créer plusieurs comptes AWS. J’ai connu quelqu’un qui s’était retrouvé avec toute son infra down, juste parce qu'il avait bloqué sa carte bleue…

Sortir du mindset admin/hosting se fait doucement avec le temps. Petit à petit, en prenant connaissance/conscience des services AWS, on s’imagine remplacer ses applications que l’on met en place au profit de services AWS décentralisés, dont on ne doute jamais de la haute disponibilité, ni de la compétence des personnes d’Amazon. Ou comment arrêter de monter ses propres DNS pour passer sur Route53. Ou comment arrêter de monter des clusters actif/passif MySQL et basculer sur RDS. Il faut avouer que monter un réplicat en lecture se fait en quelques clics, et ça, c’est toujours impressionnant.


L’optimisation financière

Très vite, avec l’arrivée des premières factures, on pense “optimisation financière”.

D’abord, parce qu’on se rend compte que ça coute un poil plus cher qu’une infrastructure classique. Et puis, parce qu’on comprend qu’on peut remplacer une partie de nos EC2 avec des services gérés directement par Amazon.

L’optimisation directe

Afin de réduire les coûts, on peut effectivement remplacer les serveurs de cache par les solutions de Cloudfront, ou on peut remplacer le serveur qui contient les données statiques par S3, par exemple.

Ca, c’est de l’optimisation directe. On remplace un service technique par un autre. C’est bien, parce qu’on évite d’avoir des serveurs payés full time et on les remplace par des services que l’on paye à la consommation.

C’est important car dans 99% des cas, la seule chose incompressible en terme d’infrastructure Amazon, c’est EC2. Vous avez très certainement pas d’autres choix que d’avoir au moins une VM qui tourne pour votre site ou votre application. Eventuellement, pour des raisons de scaling, vous pouvez avoir besoin de plusieurs instances EC2 pour héberger votre site. Mais grâce à la solution d’auto-scaling d’Amazon, vous n’avez pas à vous soucier des serveurs supplémentaires. Amazon s’occupe de rajouter les serveurs nécessaires à la charge, ou à la disponibilité, puis les détruit une fois vos besoins satisfaits. Bref, Amazon c’est génial.

L’optimisation indirecte

Avec la migration vers une plateforme de services, et non plus de serveurs, vous transférez la compétence.

Je m’explique: si demain vous avez besoin d’une infrastructure hautement disponible avec MySQL, alors il vous faut soit une personne compétente techniquement pour le faire, soit une personne qui va prendre du temps pour essayer de le faire. Ca demande donc du temps et de la compétence. En passant par un service comme Amazon, vous vous affranchissez de ce genre de besoin. Simplement parce qu’ils ont réduit la complexité de la chose en un clic.

Vous n’avez donc plus besoin de savoir mettre en place, juste de savoir utiliser. Et en IT, c’est souvent 2 personnes différentes.

Et c’est là qu’on fait de l’optimisation indirecte.

Ca veut pas dire que vous allez pouvoir licencier les personnes hautement techniques pour les remplacer par les services Amazon, mais que vous allez accéder à un niveau d’efficacité digne des plus grands, même si votre site vend les confitures confectionnées par votre grand mère.

C’est un des arguments de vente d’Amazon: donner l’accès à quiconque à un niveau de technicité digne des plus gros.


Rien n’est gratuit, encore plus quand on paye moins

L’optimisation financière est en règle générale, la seconde étape dans une migration vers Amazon. Et si ce n’est pas le cas, ce le sera à la réception de votre première facture.

Et très souvent, on se tourne vers l’infrastructure pour gérer cette optimisation. On demande rarement aux équipes de développement de mieux gérer le code qu’ils ont écrit. Le legacy ne sera pas un sujet traité ici, désolé.

Alors on fait le tour de l’infrastructure en place, on étudie les différents services proposés par AWS, et on migre petit à petit vers une infrastructure “cloud native”. C’est à dire 90% de services, et 10% de serveurs. A la louche.

Une fois terminé, vous serez certainement considéré comme le héros du jour, qui a sauvé l’entreprise d’une faillite certaine. Mieux encore, non seulement le site est devenu scalable au point de passer dans la prochaine édition de Capital sans tomber en panne, mais vous faites faire des économies à l’entreprise, par rapport à votre ancien hébergeur!

Bien joué, vous venez de mettre en péril votre entreprise!

Wait… What?

Et oui. Votre entreprise est maintenant complètement dépendante d’Amazon. A tel point que si vous envisagez d’en sortir, vous devrez d’abord étudier le coût de tout recoder.

Il faudra penser aux services que vous devrez remplacer par une solution maison, penser aux compétences qu’il vous manque en interne, penser au code de vos applications ou de votre site qui sont spécifiques à Amazon.

Enfin, estimer le coût que cela aura de tout remplacer, et le comparer au coût que ça a de rester chez Amazon. Et vous voilà coincé.


Le juste milieu

La raison pour laquelle vous êtes coincés est simple: AWS a des années d’avance sur la concurrence en terme de services managés. Longtemps, le cloud c’était des VMs, du load-balancing, et un object storage. Résultat, vous ne pouvez pas prendre votre plateforme actuelle et la transférer chez la concurrence.

Azure rattrape son retard doucement, et annonce de nouveaux services capables de concurrencer AWS. Mais Azure, c’est Microsoft. Donc priorité aux technos de la maison. Ca doit faire une petite dizaine d’année que le service managé MySQL existe chez AWS, il est seulement en bêta chez Azure à l’heure où je vous parle…

Bref, vous l’aurez compris: si vous faites une optimisation financière agressive chez Amazon, vous êtes totalement coincés chez eux.

Attention, je dis pas qu’il ne faut pas aller chez AWS. Je dis juste qu’il faut toujours envisager qu’un jour, vous aurez besoin/envie d’en sortir. En gardant ça à l’esprit, vous réfléchirez à 2 fois avant de tout migrer chez Amazon :)

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.