Qu’est-ce que le cloud ?
Il s’agit avant tout d’une approche différente de l’hébergement Web dont l’objectif est de mutualiser les ressources physiques (notamment les serveurs) tout en permettant à chacun de bénéficier de ressources virtuelles (capacité de calcul, stockage…) variables selon leurs besoins.
Cela permet par exemple à une application de lancer des calculs lourds occasionnellement sans devoir réserver cette capacité de calcul en permanence : au lieu de louer un gros serveur qui ne sera pleinement utilisé qu’une fois par semaine par exemple, on peut louer un petit serveur pour gérer la charge courante et lancer un plus gros serveur à la demande pour les plus gros calculs, sans impacter le serveur principal.
Mais cela va encore plus loin : la plupart des hébergeurs fournissent des services qui permettent de ne plus avoir à gérer de serveurs ! Qu’il s’agisse de bases de données managées (gérées par l’hébergeur) ou de clusters applicatifs (qui permettent de lancer des machines virtuelles de votre choix dynamiquement), vous n’avez alors plus à vous soucier du système d’exploitation : tout est pris en charge pour vous permettre de vous concentrer sur le développement de votre application.
Une conception différente
Bien que le cloud repose toujours sur des machines physiques similaires à celles d’un hébergement standard, pour profiter de ses avantages il faut souvent des ajustements dans le fonctionnement et la conception de vos applications.
Vous pouvez toujours héberger une application historique ou conçue de façon plus traditionnelle sur le cloud sans l’adapter, mais vous risquez de payer plus cher que nécessaire et de vous heurter à des problèmes de scalabilité similaires à ceux rencontrés sur un hébergement standard.
Tout d’abord le cloud vise à avoir une adhérence plus faible au matériel voire au système sous-jacent. Cela veut dire que les applications cloud-native doivent idéalement être conçues pour s’adapter au fait d’être coupées ou lancées à la volée.
Une API pourra par exemple être lancée plusieurs fois lors d’une montée en charge pour répondre à une hausse des demandes, puis ces mêmes instances pourront être supprimées progressivement une fois le pic passé.
Il faut donc s’assurer qu’aucune donnée n’est perdue, mais aussi que les différentes instances soient synchronisées : si un utilisateur démarre une session de navigation sur une instance, il doit retrouver ses données sur une autre instance sans interruption.
Attention à ne pas confondre l’utilisation de micro-services, qui vont chacun répondre à des besoins spécifiques sans adhérence forte au reste de vos applications tout en permettant de gérer la charge plus finement pour chacun d’entre eux, avec l'architecture cloud qui vise à distribuer et redonder une application (qu’elle soit constituée de micro-services ou non). Vous pouvez très bien avoir l’un sans l’autre !
Des coûts gérés plus finement
Un aspect parfois mal compris du cloud est la gestion des coûts. Vous ne payez effectivement que pour les ressources que vous consommez, mais il ne revient qu’à vous d’optimiser cette consommation.
Si vous devez par exemple gérer de forts pics de trafic, que ceux-ci sont potentiellement difficiles à prédire, mais que vous avez un usage régulier assez faible, le cloud peut alors vous permettre une flexibilité idéale pour maîtriser vos coûts.
Idem si vous avez des besoin ponctuels spécifiques : vous avez un algorithme qui utilise énormément de ressources de façon ponctuelle ? Vous pouvez louer des instances éphémères à la demande en les payant à l’heure, voire à la minute !
Vos process impliquent de déployer des services éphémères à la volée (par exemple pour des tests ou du déploiement continu) ? Vous pouvez les lancer et les détruire comme bon vous semble sans payer des serveurs inutilisés le reste du temps.
Une gestion spécifique
Qui dit conception et coûts différents dit gestion différente. Et c’est là qu’une partie des incompréhensions du cloud a lieu : la gestion ne se fait pas de la même façon puisque l’architecture est plus variable.
Mais cela ne veut pas dire qu’il faut tout laisser faire sous prétexte que "c’est du cloud, ça coûte forcément cher". Il faut donc déterminer et suivre vos coût fixes : ceux qui permettent à votre produit de tourner de façon minimale dans un usage normal.
Utiliser des ressources "jetables"
Certains hébergeurs proposent des ressources moins chères car elles sont "jetables". Ils peuvent par exemple vous garantir une capacité de calcul constante, mais sans forcément garder la même machine physique sous-jacente. Cela impliquera donc d’avoir des coupures potentielles sur certains processus (qui seront tués et/ou lancés aléatoirement)… que vous aurez bien sûr conçus pour s’adapter à ce genre d’aléas. 
En somme vous payez pour utiliser dynamiquement du matériel qui autrement tournerait à vide, à un tarif réduit en contrepartie d’une sorte de bail précaire.
AWS et GCP appellent ces gammes "Spot", elles peuvent être idéales pour des applications de test/recette tolérantes aux pannes, ou pour des applications hautement redondées qui peuvent supporter une panne partielle aisément.
Choisir ses offres de services managés
La plupart des hébergeurs proposent des offres clés en main pour des services souvent utilisés, qu’il s’agisse d’une base de donnée, d’envoi de notifications (email, SMS, mobile…), de stockage de fichiers… et bien d’autres !
Mais s’ils éliminent un certain coût de mise en place et de maintenance, certains de ces services peuvent coûter cher si leur usage n’est pas dimensionné correctement.
Si par exemple vous demandez à avoir une base de donnée hautement redondée avec un stockage énorme alors que vous avez finalement un volume restreint de données à y stocker ou qu’elle n’est que peu sollicitée… il vaut peut-être mieux passer à une offre inférieure. Cela peut paraître évident, mais il arrive de prévoir un usage plus important que prévu, avec un coût inutilement élevé à l’arrivée, sans s’en rendre compte.
Commencez par dimensionner pour le besoin actuel, il sera toujours temps de migrer plus tard si l’usage évolue.
Surveiller les coûts d’usage
Certains services, bien que gratuits en apparence, peuvent avoir des coûts dans certains cas. Par exemple la bande passante peut-être gratuite au sein d’un VPC, lui-même fourni gratuitement (ou pour un prix fixe), mais la bande passante sortante peut être facturée.
Il est parfois nécessaire de concevoir son application différemment pour faire transiter les informations par d’autres canaux, ou d’internaliser certains outils plutôt que d’appeler des services externes.
Bien que ces coûts peuvent paraître faibles au premier abord, ils peuvent finir par s’accumuler, surtout à mesure que votre usage augmente.
Documenter et automatiser ses déploiements
Pour permettre un meilleur suivi des ressources gérées, il devient vite indispensable de documenter ce que vous déployez : pour chaque type de ressources il faut connaître leur nombre, mais aussi leur configuration pour connaître leur coût mais aussi leurs capacités.
Des outils comme Terraform ou Ansible sont très utiles pour ce genre de tâches : votre configuration étant ainsi stockée dans du code, vous pouvez la versionner (avec Git ou un équivalent) pour en documenter l’évolution.
Vous pourrez également profiter des fonctionnalités de différentiel pour n’appliquer que les changements nécessaires sans détruire ce qui existe déjà.
Mais au-delà de ça, comme il s’agit de code, vous pouvez utiliser un pipeline de déploiement continu pour appliquer automatiquement les changements apportés à ces fichiers : pas besoin de donner toute la configuration aux développeurs, tout est géré par des serveurs
Aller plus loin
Vous avez des questions ? Certains aspect du cloud sont encore flous dans votre esprit ? N’hésitez pas à poser vos questions en commentaire !