Mis à jours 9 avril 2019 Une journée dans la vie de deux équipes de développement
De nombreuses personnes s’inquiètent du prix de l’hébergement cloud public par rapport au coût de l’infrastructure traditionnelle sur site. Pour vous donner plus de détails, suivons deux équipes de développement au sein d’une entreprise – et comparons leur approche à la construction d’un service similaire.
La première équipe déploiera son application à l’aide de l’infrastructure traditionnelle sur site, tandis que la seconde utilisera certains des services cloud publics disponibles sur AWS.
Les deux équipes sont invitées à développer un nouveau service pour une entreprise mondiale qui dessert actuellement des millions de consommateurs dans le monde. Ce nouveau service devra répondre à ces exigences de base :
- La capacité de mettre à niveau pour répondre à des demandes élastiques
- Assurer la résilience pour réagir à une panne de datacenter
- Assurer que les données sont sécurisées et protégées
- Fournir un débogage approfondi pour le dépannage
- Le projet doit être livré rapidement
- Le service doit être rentable pour construire et maintenir
En ce qui concerne les nouveaux services, il semble que ce soit un ensemble d’exigences relativement standard . Ce qui ne favoriserait intrinsèquement ni l’infrastructure traditionnelle sur site ni le cloud public.
Le meilleur hébergeur Cloud le moins cher
Avant d’aller plus loin, nous tenons à vous recommander Infomaniak comme le meilleur hébergeur Cloud pas cher. Voici une brève présentation de cet hébergeur, pour en savoir d’avantage consultez la page d’avis Infomaniak Cloud
Infomaniak offre une panoplie de plan Cloud Public infogéré à des prix abordable pas cher. Voici un aperçu des caractéristiques de ses solution Cloud :
- Espace disque : 100 GB jusqu’à 2 To SSD
- CPU : jusqu’à 36
- Mémoire vive RAM : 96 Go
- Certificats SSL gratuits pour tous vos sites web
- Adresses IP dédiés gratuits
- Plateforme VOD/AOD gratuite de plus de 10 Go d’espace
1 – Mettre à niveau pour répondre aux demandes des clients
Lorsqu’il s’agit d’évolutivité, ce nouveau service doit être évolutif pour répondre aux demandes variables des consommateurs. Nous ne pouvons pas créer un service qui pourrait baisser les demandes et coûter de l’argent à notre entreprise. Courant ainsi le risque de nuire à sa réputation.
L’équipe traditionnelle
Avec une infrastructure sur place, l’approche architecturale impose de dimensionner la capacité de calcul afin qu’elle corresponde à vos demandes de données de pointe. Pour les services qui comportent une charge de travail variable, cela vous laissera beaucoup de capacité de calcul excessive et coûteuse en période de faible utilisation.
Cette approche est considérée comme du gaspillage. Ainsi, les dépenses en capital vont fort probablement nuire à vos profits. De plus, le maintien de votre flotte de serveurs sous-utilisés entraîne de lourds coûts opérationnels. C’est un prix qui est souvent négligé. Vous ne saurez pas le montant d’argent et le temps que vous gaspillerez pour prendre en charge un réseaux de serveurs nus pour un seul service.
L’équipe Cloud
Avec une solution d’évolutivité automatique basée sur le cloud, votre application évolue en fonction de la demande. Cela signifie que vous ne payez que pour les ressources de calcul que vous consommez.
Une application basée sur le cloud, bien architecturée, permet de mettre à l’échelle et de régresser de manière transparente et automatique. L’équipe de développement définit des groupes de mise à l’échelle automatique qui génèrent plus d’instances de votre application. Cette mise à l’échelle est en fonction de l’utilisation élevée du processeur ou d’un grand nombre de requêtes par seconde. Ainsi, vous pouvez personnaliser ces règles en fonction de votre contenu.
"Friends Don't Let Friends Build Data Centers" Charles Phillips, CEO @Infor #AWSSummit pic.twitter.com/MLEknyLAyp
— AWSonAir (@AWSonAir) July 13, 2016
2- Résilience pour réagir à l’échec
Lorsqu’il s’agit de résilience, l’hébergement d’un service sur l’infrastructure qui réside dans les mêmes quatre murs n’est pas une option. Si votre application réside dans un seul centre de données, alors vous êtes débordé quand (ou pas si) quelque chose échoue.
L’équipe traditionnelle
Pour répondre aux critères de résilience de base pour une solution sur site, cette équipe doit disposer d’un minimum de deux serveurs pour la résilience local. Cette dernière est répliquée dans un second centre de données pour la redondance géographique.
L’équipe de développement devra identifier une solution d’équilibrage de charge qui redirige automatiquement le trafic entre les sites en cas de saturation ou de panne. Il faut aussi s’assure que le site miroir est continuellement synchronisé avec l’ensemble de la pile.
L’équipe Cloud
Dans chacune de ses 50 régions dans le monde, AWS fournit plusieurs zones de disponibilité. Chaque zone est composée de l’un des centres de données les plus tolérants aux pannes. Ils sont dotés de fonctionnalités de basculement automatisées permettant de transférer en toute transparence les services AWS vers d’autres zones de la région.
La définition de votre infrastructure en tant que code dans un modèle CloudFormation garantit la cohérence des ressources d’infrastructure entre les zones. Cette cohérence se fait durant les événements de mise à l’échelle automatique. Le service d’équilibrage de charge AWS requiert un minimum d’efforts pour configurer et gérer le flux de trafic.
3 – Sécurisez et protégez vos données
La sécurité est une exigence fondamentale de tout système développé au sein d’une organisation. Vous ne voulez vraiment pas faire partie des sociétés malheureuses qui traitent des retombées d’une faille de sécurité.
L’équipe traditionnelle
L’équipe traditionnelle supportera les coûts permanents pour s’assurer que les serveurs nus qui exécutent leurs services sont sécurisés. Cela signifie investir dans une équipe qui tente de surveiller, d’identifier et de corriger les menaces de sécurité. Cela se fait à partir de diverses sources de données uniques.
L’équipe Cloud
Tirer parti du cloud public ne vous exempte pas de la sécurité. L’équipe cloud doit rester vigilante, mais ne doit pas s’inquiéter de la correction de l’infrastructure sous-jacente. AWS travaille activement contre les exploits zero-day – plus récemment avec Spectre et Meltdown.
L’utilisation des services de sécurité de chiffrement et de gestion des identités d’AWS permet à l’équipe cloud de se concentrer sur leur application, et non sur la gestion de la sécurité indifférenciée. Les appels d’API aux services AWS sont entièrement audités à partir de CloudTrail, qui assure une surveillance transparente.
4 – Surveillance et journalisation
Chaque infrastructure et service d’application déployé doivent être étroitement surveillés avec des données agrégées en temps réel. Les équipes doivent avoir accès à des tableaux de bord qui fournissent des alertes lorsque les seuils sont dépassés. Ils offrent la possibilité de tirer parti des journaux pour la corrélation des événements en vue de résoudre des problèmes.
L’équipe traditionnelle
Pour l’infrastructure traditionnelle, vous devrez mettre en place des solutions de surveillance et d’alerte à travers des fournisseurs disparates et des solutions Snowflake. Cela prend énormément de temps, et il est incroyablement difficile d’y arriver.
Pour de nombreuses applications déployées sur site, vous pouvez rechercher vous-même dans les fichiers journaux stockés sur le système de fichiers de votre serveur. Cela vous permettra de comprendre pourquoi votre application plante. Beaucoup de temps sera gaspillé car les équipes ont besoin de se connecter au serveur, de naviguer vers le répertoire unique des fichiers journaux, puis de parcourir plusieurs centaines de fichiers. Ayant fait cela pour une application qui a été déployée sur 60 serveurs, vous vous rendez compte que ce n’est pas une bonne solution.
L’équipe Cloud
Les services AWS natifs, tels que CloudWatch et CloudTrail, font du monitoring des applications cloud un jeu d’enfant. Sans beaucoup de configuration, l’équipe de développement peut surveiller une grande variété de métriques différentes pour chacun des services déployés. Cal rend le processus de débogage un rêve absolu.
Avec l’infrastructure traditionnelle, les équipes doivent créer leur propre solution et configurer leur API ou service REST pour envoyer les fichiers journaux à un agrégateur. Obtenir cette ‘out-of-the-box’ est une amélioration insensée de la productivité.
5 – Accélérez le développement
La capacité à accélérer le temps de mise sur le marché est de plus en plus importante dans l’environnement des affaires d’aujourd’hui. Les coûts d’opportunité perdus pour les implémentations retardées peuvent avoir un impact majeur sur les bénéfices nets.
L’équipe traditionnelle
Pour la plupart des entreprises, l’achat, la configuration et le déploiement du matériel nécessaire à de nouveaux projets prennent beaucoup de temps. En outre, l’acquisition de capacités supplémentaires à l’avance entraîne un gaspillage massif en raison de mauvaises prévisions.
Très probablement, l’équipe de développement traditionnelle passera des mois à travailler sur la myriade de silos et de transferts pour créer les services. Chaque étape du projet nécessitera une demande de travail distincte pour les administrateurs de bases de données, de systèmes, de sécurité et de réseau.
L’équipe Cloud
Lorsqu’il s’agit de développer de nouvelles fonctionnalités en temps opportun, disposer d’une vaste gamme de services prêts à la production est un paradis pour les développeurs. Chacun des services AWS est généralement bien documenté et peut être consulté par programme via la langue de votre choix.
Avec de nouvelles architectures cloud telles que serverless, les équipes de développement peuvent créer et déployer une solution évolutive avec un minimum de friction. Par exemple, en quelques jours, vous pouvez construire un clone sans serveur d’Imgur qui intègre une reconnaissance d’image, une solution intégrée de surveillance/journalisation prête à la production. En plus elle est incroyablement résiliente.
Si vous devez développer la résilience et l’évolutivité vous-même, vous pouvez vous assurez que vous développeriez toujours ce projet. Le produit final serait loin d’être aussi bon qu’il l’est actuellement.
Avec une architecture sans serveur, vous expérimentez et livrez la solution en moins de temps que le nécessaire pour provisionner du matériel dans la plupart des entreprises. Vous collez simplement une série de services AWS avec des fonctions Lambda – et voilà ! Vous pouvez vous concentrer sur le développement de la solution, tandis que l’évolutivité et la résilience indifférenciées sont gérées pour vous par AWS.
Le verdict des coûts sur le cloud computing
En ce qui concerne l’évolutivité, l’équipe cloud est clairement gagnante avec une élasticité à la demande, ne payant que la puissance de calcul dont elle a besoin. L’équipe n’a plus besoin de ressources dédiées à la maintenance et à la correction de l’infrastructure physique sous-jacente.
Le cloud fournit également aux équipes de développement une architecture résiliente avec :
- Un ensemble zones de disponibilité multiples.
- Une panoplie de fonctionnalités de sécurité intégrées à chaque service.
- Un nombre important d’outils cohérents pour la journalisation et la surveillance.
- Des services par répartition («pay-as-you-go»).
- Une expérimentation à moindre coût pour une livraison accélérée.
Plus souvent qu’autrement, le coût absolu du cloud représentera moins que le coût d’achat, de support, de maintenance et de conception de l’infrastructure sur site nécessaire à l’exécution de votre application, avec moins de complications.
En tirant parti du cloud, nous pouvons aller plus vite et surtout, avec le minimum d’investissement initial nécessaire. Dans l’ensemble, l’économie du cloud va activement travailler en votre faveur lors du développement et du déploiement de vos services dans l’entreprise.
Il y aura toujours quelques exemples de niche où le coût du cloud est prohibitivement plus cher que l’infrastructure traditionnelle, et quelques situations où vous finissez par oublier que vous avez laissé des boîtes de test incroyablement chères pendant la fin de semaine.
Cependant, ces cas restent rares et peu nombreux. Sans compter que Dropbox a débuté sur AWS – et ce n’est qu’après avoir atteint une masse critique qu’ils ont décidé de migrer hors de la plate-forme. Même maintenant, ils débordent dans le cloud et conservent 40% de leur infrastructure sur AWS et GCP.
L’idée de comparer les services cloud à l’infrastructure traditionnelle, basée sur une seule métrique, le « coût », est insuffisante : elle ignore de manière flagrante certains des avantages majeurs que le cloud offre aux équipes de développement et à votre entreprise.
Dans les rares cas où les services cloud entraînent un coût absolu supérieur à celui de votre offre d’infrastructure traditionnelle, ils représentent toujours une meilleure valeur en termes de productivité, de rapidité et d’innovation des développeurs.
