Le temps de louer une salle dans un datacenter, d'acheter des serveurs et d'avoir des ingénieurs à proximité pour résoudre les potentiels problèmes est-il révolu ? Alors que construire une infrastructure on-premise prenait avant des semaines (ou mois), cela prend désormais quelques heures. Avec des prix toujours plus bas, la question est simple : l'infrastructure on-premise a-t-elle un avenir?
Un problème de gestion des compétences
Le cloud computing a établi des standards pour déployer du logiciel, à commencer par EC2, S3 ou Kubernetes. Non seulement ces technologies sont très bien comprises et maîtrisées par les ingénieurs (après tout, ils ont appris ces technologies au cours de leur expérience professionnelle ou lors de projets personnels) mais leur utilisation dans les plates-formes de cloud computing est facilitée avec un outillage mature et bien supporté.
A l’inverse, lorsque l’on déploie sa propre infrastructure, il devient nécessaire de développer l’outillage spécifique pour gérer ses serveurs et le déploiement du logiciel. Cela devient alors un travail à temps plein qui nécessite d’embaucher des ingénieurs. De plus, cet outillage spécifique sera moins mature que leur équivalent disponible pour le cloud et par conséquent, ralentit l’entreprise dans le développement de son infrastructure et de ses applications.
Le choix est donc simple: en utilisant le cloud pour construire votre infrastructure, vous pouvez avoir accès à une plate-forme mature et des candidats opérationnels dès le premier jour. Faire le choix du on-premise signifie une longue période d’installation du matériel mais aussi l’embauche d'ingénieurs qui vont définir les méthodes de déploiement du logiciel et l'implémentation des outils.
Des performances toujours en hausse, des coûts toujours plus bas
Avec une adoption qui croît de 30% de trimestre en trimestre, les acteurs du cloud computing ont désormais une base d’utilisateurs si conséquente qu’ils peuvent optimiser eux-mêmes leur infrastructure et mettre à disposition de leurs clients des services toujours plus performants à des coûts toujours plus bas.
L’exemple parfait est le développement du Graviton par Amazon Web Services, un processeur qui délivre des performances supérieures aux processeurs Intel avec un coût inférieur. Cette technologie est bien entendu limitée aux clients d’Amazon Web Services. En développant son propre matériel, AWS est capable de supprimer tous les coûts n’apportant pas de la valeur et se focalisent sur le développement d’un produit performant pour leurs clients. Ces optimisations s’appliquent à toute l’infrastructure déployée dans le cloud. Ce processeur n’est pas uniquement utilisé pour déployer des instances de votre logiciel mais aussi pour l'hébergement de votre base de données ou l’orchestration de votre infrastructure. Ces optimisations sont loin d'être négligeables avec des performances supérieures de 25% à 40% et une réduction de coût de 5% à 10%. Choisir de rester on-premise, c’est donc aussi refuser ces potentielles optimisations.
La sécurité : un argument épouvantail
Un argument souvent soulevé en défaveur du cloud computing est la potentielle sécurité des données. Les fournisseurs de cloud computing sont considérés comme des infrastructures peu sécurisées et utiliser une infrastructure on-premise garantirait la sécurité des données. Une simple requête google montre que la sécurité est au cœur des préoccupations lorsqu’il s’agit du cloud computing.
Cependant, penser que le on-premise est plus sécurisé que le cloud, c’est comme penser que conduire en voiture est plus sûr que voyager en avion car nous avons le contrôle. Cependant, la grande majorité des problèmes de sécurité dans le cloud vient de l’utilisation qui en est faite. Les problèmes de configuration sont légion (par exemple, les buckets S3 étant incorrectement configurés comme étant publique ou les erreurs de configuration des routeurs et load balancer). Mais ce sont des problèmes faciles à régler. De nombreux services sont disponibles pour scanner une infrastructure déployée dans le cloud et trouver tout potentiel problème de sécurité (ce qui est beaucoup plus compliqué à faire pour une infrastructure on-premise).
De nombreuses compagnies ayant des contraintes de sécurité utilisent le cloud aujourd’hui. Capital One (banque établie aux Etats-Unis) a migré son infrastructure dans le cloud. Même le gouvernement Américain utilise aujourd’hui le cloud computing avec des services qui leur sont dédiés (et cette tendance ne va pas s'arrêter puisque Pentagon a annoncé il y a quelques mois un nouveau contrat pour développer leur infrastructure dans le cloud).
L’argument de la sécurité n’est qu’un prétexte, une barrière psychologique que certains décideurs utilisent pour ne pas changer le statu quo mais qui expose leur entreprise à être moins innovatrice dans les années à venir.
Quel avenir pour le on-premise?
Il y a peu de doutes : le on-premise va devenir un marché de niche dans les dix années à venir et de nouveaux fournisseurs de cloud computing vont émerger. Pour autant, il y a toujours quelques barrières mineures qui peuvent contraindre des entreprises à rester on-premise.
Premièrement, l’inertie des vieilles entreprises qui ont une infrastructure on-premise bien implantée. Ces sociétés ont déjà des locaux (et contrats de location dans des datacenter) et des serveurs et ne souhaitent pas changer la manière dont ils gèrent leur infrastructure, invoquant que leur infrastructure actuelle est si bien rodée que changer pour aller dans le cloud leur coûtera bien trop cher. Cependant, en gardant cette vieille approche, ils vont finir par payer bien plus en coût de développement et maintenance de leur infrastructure (ingénieurs dédiés à la gestion de l’infrastructure et de son outillage) et l'écart de coût et de performance entre cloud et on-premise continuera de se creuser.
Deuxièmement, une garantie de pouvoir changer de fournisseur de services. Beaucoup de solutions dans le cloud sont spécifiques au fournisseur (par exemple, utiliser une base de données Amazon Aurora sur AWS ne garantit pas de pouvoir basculer chez Google Cloud Services ou Azure). C’est un vrai problème qui peut être évité facilement: en utilisant des solutions génériques et interopérables, il est facile de pouvoir changer de fournisseur de services. Au lieu d’utiliser ECS pour déployer des conteneurs Docker, il est plus judicieux d’utiliser Kubernetes ; au lieu d’utiliser Amazon Aurora pour sa base de données, il est plus judicieux d’utiliser MySQL ou PostgreSQL. Pour éviter ce problème, beaucoup d’entreprises facilitent désormais le déploiement et la migration entre fournisseurs de service.
Enfin, un problème de souveraineté. Autrement dit, où sont physiquement localisées vos données. C’est un point critique pour l’Europe ou aucun fournisseur de cloud computing ne peut prétendre à une qualité de service égale à Amazon Web Services ou Azure. Si cela n’affecte pas les petites et moyennes entreprises, c’est cependant un point critique pour les grosses entreprises ou les instituts publics. Malheureusement, les initiatives européennes qui ont tenté de copier leur homologue américain se sont soldées par un échec. (qui se rappelle de Quaero?). Pourtant, les compétences techniques sont là, développer un cloud européen digne de ce nom n’est qu’une question de volonté politique et financière.