Le problème
Background
Un peu de background, j'ai un parcours d'ingénieur système et réseaux, c'est un terme aussi générique qu'ingénieur DevOps aujourd'hui, qui indique surtout qu'on a patauger du côté de l'infrastructure en touchant un peu à tout.
ZenOps est un intégrateur, et les intégrateurs peuvent travailler sur des sujets très variés (Serveurs Linux, VMWare, Windows Server, Annuaires LDAP, réseau, messagerie, backup, etc...). L'expérience acquise m'a donc permis d'explorer un large éventail de ces technologies, dans des contextes variés (architecture, migration de solutions, maintenance, évolution, etc...).
Un peu d'histoire
Le paysage de l'IT évolue régulièrement avec de nouvelles innovations venant régulièrement bouleverser les habitudes. Ces innovations ont cependant suivi une certaine logique qu'on trouve dans n'importe quelle industrie :
- Gérer toujours plus de serveurs, avec moins de ressources
- Réduire les coûts
- Simplifier la vie des administrateurs, ce qui revient à réduire leur nombre, ou plutôt à agrandir leur périmètre, ce qui dans un certain sens réduit les coûts.
Les serveurs bare-metal stand-alone d'antan avait un défaut, le gaspillage de ressource, trop de manutention, du HA compliqué (voir pas du tout de HA).
On les a donc remplacé par des serveurs qui hébergent plein de serveurs (aka. hyperviseurs) qui nous permettent d'optimiser l'usage de ressources tout en corrigeant le problème de HA et offrant de manière générale davantage de flexibilité.
On se concentrera donc sur l'optimisation des ressources.
Le modèle était bon, mais la maintenance de tous ces composants était à la charge de l'entreprise.
Quelque part en 2006, Amazon a lancé une offre d'hébergement permettant de créer des machines à la demande, tout en laissant la gestion des serveurs et du réseau au SI, avec une facturation sur mesure, à l'heure. On a appelé ça le "Cloud", puis le "Cloud Public".
Soyons honnêtes, cela n'a dans la très grande majorité des cas aucunement fait baisser les coûts, mais :
- On était sur une facturation On Demand, difficile de faire plus flexible.
- La complexité lié à la gestion du matériel interne (serveurs, SAN, etc...) était fortement réduite : Pas besoin de commander du matériel, le remplacer, le maintenir.
- L'infrastructure est facile à redimensionner.
Le principal inconvénient est le coût, qui devient vite prohibitif.
A partir de là, on parle d'infrastructure OnPremise ou Cloud, l'un n'ayant jamais effacé l'autre.
Et pour les développeurs ?
Ces innovations venaient principalement répondre à des problématiques d'infra, mais on oublie vite que ces systèmes n'ont pour seul objectif que de faire fonctionner les applications métiers conçues par nos développeurs (ou des éditeurs).
Ces derniers ont bien évidemment eu leur lot d'évolution, mais on observait un phénomène : Une tension récurrente opposait la nécessité de mettre à jour les plateformes systèmes à l'impossibilité d'actualiser les applications métier ou d'infrastructure pour qu'elles puissent s'adapter aux nouvelles technologies.
Ces défis ont souvent entraîné un décalage entre les versions des applications en production et les versions officiellement supportées par les développeurs / éditeurs, que cela concerne le système d'exploitation ou l'application elle-même. Les SI parvenaient péniblement (voir pas du tout) à rattraper le retard.
La problématique était donc particulièrement complexe :
- Impossibilité de mettre à jour un le socle système d'une application sans briser une dépendance.
- Comment faire pour maintenir l'application à jour quand le dernier développeur sur le sujet a pris sa retraite 5 ans plus tôt ?
- Des CVEs étant publiées tous les jours, comment maintenir un niveau de sécurité adéquat quand on cumule les vulnérabilités critiques ?
- Tout cela entraînait des délais entre chaque release beaucoup trop long, avec des délais de mise en production tout aussi long.
Le post suivant parle des conteneurs, un début de solution, et surtout le début de Kubernetes.