5 minute(s) de lecture

Cela fait maintenant plusieurs semaines que j’ai pris la décision de migrer une partie de mes services vers des solutions de cloud computing et peut-être que cela peut vous intéresser que je vous raconte comment j’ai choisi de gérer chaque cas, avec des explications sur chaque choix et des exemples concret de configuration. Ces articles ne vous intéresseront probablement pas beaucoup si vous maintenez un blog qui fait quelques centaines ou milliers de pages vues par jour, mais si vous êtes en train de monter la futur startup de la mort qui tue, ou bien si vous gérez à la petite semaine des services web qui encaissent du trafic, alors vous y découvrirez peut-être quelques trucs intéressants.

cloud computing.pngPour commencer, les promesses du cloud sont plus qu’attractives:

  • des capacités infinies ou presque (CPU, mémoire, stockage)
  • la possibilité de gérer facilement une montée en charge aussi bien temporaire (pour encaisser des pics de trafic par exemple), que dans la durée (pour accompagner votre croissance), et cela de manière quasi-instantanée.
  • des backups simplifiés, soit parce que le service s’en charge pour vous (par exemple sur Amazon S3), soit via l’utilisation des systèmes de snapshot (on y reviendra)
  • un paiement en fonction des ressources réellement utilisées, permettant de démarrer avec des couts bas et d’avoir en permanence des couts proportionnels à votre activité, plutôt que d’avoir à investir d’avance dans de l’infrastructure pour héberger correctement vos services.

J’ai donc passé beaucoup de temps à apprendre et décortiquer les offres, afin d’avoir une vision claire de ce que je veux faire et comment le faire. Je vais donc dans les prochaines semaines mettre en ligne différents articles sur le sujet, au fur et à mesure de la migration de mes différents services vers le cloud. Mon constat est que les offres de cloud sont nombreuses, que c’est devenu un terme marketing à la mode, et que les offres vraiment sérieuses et abordables sont finalement plutôt rares. De plus, il y a très peu d’offres attractives en France, ce qui peut poser derrière des problèmes en terme de référencement, étant donné que j’ai toujours entendu les référenceurs me dire qu’il était important d’héberger son site avec une adresse IP dans le pays auquel le contenu est destiné. Enfin, on est habitué en France à la notion de trafic illimité, mais dans le cloud, on paye généralement à la bande passante consommée, et cela peut faire grimper rapidement la facture si vous faites beaucoup de trafic, on verra comment y remédier.

Ce qui est certain, c’est qu’en 2 ans, j’ai du faire 4 migrations de serveurs pour augmenter mes capacités à servir des pages, et que c’est très lourd à chaque fois de tout migrer, même si j’ai automatisé un certain nombre de choses: c’est souvent beaucoup de temps de perdu. De même, en cas de crash d’un serveur, restaurer le service est souvent bien trop long. Enfin la gestion des backups devient un calvaire, notamment sur mon site de tv en replay ou bien de clips videos en HD, où je stocke plusieurs centaines de GO d’images que je ne peux pas perdre.

De plus, pour minimiser les coûts, on a trop souvent tendance à multiplier les services qu’on héberge sur nos serveurs dédiés (une machine à 100E/mois chez OVH, bien configurée, peut encaisser beaucoup de choses, j’en fais l’expérience chaque jour). Tant que tout roule, pas de problème, mais quand l’un des services vient à dérailler, cela pénalise immédiatement tous les autres ce qui est vraiment problématique. C’est donc au final un très mauvais calcul qui ne fait qu’accélérer l’apparition de cheveux blancs à chaque nouveau problème ;-)

services dans le cloud.png Basculer vers le cloud, va donc permettre:

  • de choisir au mieux chaque service afin que chaque tache soit réalisée de manière optimale (ie. gestion des contenus statiques, des contenus dynamiques, de la base de donnée, des taches de fond)
  • de permettre d’avoir une architecture non plus guidée par les coûts mais bien par la logique: combien d’entre vous hébergent sur un même serveur BDD, serveurs applicatifs, frontal web et taches crons, alors que tout le monde sait que tout cela devrait être sur des serveurs séparés?
  • d’être capable de faire croitre plus facilement mon activité ou celle de mes clients sur le long terme, mais aussi en fonction des pics d’activité (par exemple, sur Replay.fr, ça dort le mardi et le mercredi, mais le dimanche soir et le lundi soir, c’est pire que la cote d’azur en été).
  • de ne pas avoir besoin à chaque fois de tirer des plans sur la comète pour dimensionner les infrastructures d’hébergement: je ne compte plus le nombre de fois où un hébergeur m’a demandé qu’elles étaient mes prévisions de charge et de trafic parce qu’il faut ensuite 2 semaines pour ajouter et configurer une nouvelle machine … Qu’est ce que j’en sais moi? Je suis pas madame Irma ;-) Du coup, on se retrouve généralement à avoir X serveurs qui dorment en prévision du futur trafic qu’un jour c’est sur on encaissera et donc faut être certain d’être prêt, tout cela pour découvrir que le jour dit, tout s’écroule finalement car on avait sous-estimé quelque chose, c’est ballot hein?

Vous l’aurez compris, le cloud permet donc de maitriser ses coûts au plus juste, de construire dès le départ une architecture évolutive qui tient la route, et surtout, de pouvoir réagir très rapidement en fonction des aléas qui jalonnent le parcours de tout service web qui connait une popularité croissante.

Voila, l’introduction est posée, je vous propose qu’on se retrouve rapidement pour un premier article sur la gestion des contenus statiques via Amazon S3. Et comme je ne suis surement pas un expert, mais plutôt un amateur éclairé, n’hésitez surtout pas à intervenir dans les commentaires pour me corriger quand je dis des âneries, ou pour me suggérer comment mieux faire quand vous trouvez que ce que je suggère c’est vraiment trop nul ;-)

Voici la liste des articles déjà publiés sur le sujet: