Certains s’accordent à dire que le “DevOps est mort ; vive l’ingénierie de plateforme. En effet, des termes tels que “plateforme d’ingénierie”, “portail de développeur” ou même “Backstage” sont de plus en plus utilisés. Mais le DevOps est-il vraiment mort ? Qu’est-ce que l’ingénierie de plateforme ? Quelles sont les différences ? Comment l’ingénierie de plateforme gère-t-elle le DevSecOps et la sécurité ? Dans cette tribune, Tiexin Guo, Guest Security expert chez Gitguardian tente de répondre à ces interrogations.
DevOps est-il mort ? A cette question la réponse est non car les technologies, les frameworks et les méthodologies ne meurent jamais vraiment. Ils grandissent, s’adaptent et évoluent. C’est comme le développement agile. Quand en avons-nous entendu parler pour la première fois ? Est-ce mort maintenant ? Mais, d’une certaine manière, le DevOps est bien “mort”. Bien qu’il n’ait pas disparu de la communauté technologique de manière conventionnelle, il est “mort” dans le sens où de nombreuses entreprises et équipes qui cherchaient à utiliser DevOps n’ont pas réussi à répondre à leurs attentes. En 2019, un analyste de données de Gartner a prédit que d’ici 2022, 75 % des initiatives DevOps ne répondraient pas aux attentes, et ce chiffre pourrait atteindre 90 % en 2023. Il convient de souligner que ces initiatives DevOps ont échoué non pas en à cause de défis technologiques, mais en raison de facteurs humains négligés tels que la confiance, la participation et le travail d’équipe. Initialement, le DevOps était présenté comme la solution ultime à tous les problèmes au sein des silos opérationels, promettant de révolutionner l’industrie. Cependant, de nombreuses équipes ont malheureusement été en deçà de leurs attentes initiales. Pire encore, il semble qu’en fin de compte, les développeurs ne veulent pas vraiment faire le travail d’Ops !
Les développeurs ne veulent pas faire de l’Ops
Certains développeurs pensent que le paradigme DevOps “vous le construisez, vous le gérez” est certainement bénéfique, voire parfois nécessaire ; d’autres ne veulent pas du tout toucher aux opérations. Par exemple, dans ce sondage, les réponses mettent en évidence la division, avec 41,8 % des répondants disant oui aux tâches d’opérations, 42,1 % disant non et 16,1 % étant indifférents. Il s’avère que les développeurs ont tendance à éviter l’infrastructure et les opérations, ce qui n’est pas très positif pour le succès du DevOps.
La conséquence est que l’ingénierie de plateforme est devenue de plus en plus populaire en réponse à cette tendance. L’ingénierie de plateforme, tout comme le DevOps, est apparue en réponse à la complexité croissante de l’architecture logicielle moderne. Aujourd’hui, les utilisateurs finaux non experts, tels que les développeurs, sont souvent chargés d’exploiter un ensemble complexe de services qui peuvent être incroyablement difficiles à gérer. Alors que le DevOps essaie de résoudre le problème de collaboration et de vélocité du cycle de vie du développement de logiciels (SDLC) d’un point de vue culturel – où la responsabilité partagée, la croissance continue et l’état d’esprit d’apprentissage sont valorisés, le travail d’équipe, les meilleures pratiques et les chaînes d’outils modernes sont encouragés – l’ingénierie de plateforme essaie d’aborder le problème sous un angle différent : celui de l’auto-service. Par exemple le cas s’applique si une équipe de développeurs, qui a besoin d’une base de données relationnelle (RDS) pour sa nouvelle application, mais qui n’a pas les connaissances nécessaires pour en créer une dans un fournisseur de cloud spécifique, tel qu’AWS, en utilisant l’outil d’automatisation approprié, tel que Terraform. Tous les développeurs ne sont pas familiers avec l’infrastructure et l’orchestration de leurs systèmes.
Accéder au niveau approprié d’auto-service et d’abstraction
L’approche DevOps pour résoudre ce problème consiste à créer une équipe pluridisciplinaire qui comprend un expert des services AWS et de l’infrastructure en tant que code qui possède les autorisations appropriées pour provisionner automatiquement les ressources cloud en écrivant des modules Terraform et en déployant le RDS dans AWS. A l’inverse, dans l’approche de l’ingénierie de plateforme, il devrait y avoir un produit intégré qui sert de “portail de développeur interne”, de sorte que les développeurs demandent un RDS dans AWS via l’auto-service, et la plateforme le crée automatiquement. Il ne s’agit que d’un exemple ; les portails de développeurs internes peuvent accomplir bien plus s’ils sont correctement conçus.
En bref, l’ingénierie de plateforme consiste à concevoir et à construire un produit intégré qui comprend des chaînes d’outils et des flux de travail pour répondre aux exigences opérationnelles de l’ensemble du SDLC. Cette approche permet aux développeurs d’accéder au niveau approprié d’auto-service et d’abstraction qui convient à leur organisation ou à leur équipe à l’ère du cloud natif.
Ingénierie de plateforme vs DevOps
Bien que ces capacités d’auto-service améliorent l’expérience et la productivité des développeurs, ce n’est pas pour tout le monde, surtout pas pour les petites équipes d’entreprises: même si une organisation décide d’acheter un portail de développeur interne en tant que service au lieu de le construire à partir de zéro, elle doit toujours maintenir l’automatisation et les modèles en arrière-plan. Il est important de garder en tête l’exemple précédent de RDS dans le cloud, l’entreprise doit avoir la connaissance pour maintenir les modèles Terraform pour générer le module. Si une équipe ou une entreprise est trop petite pour l’ingénierie de plateforme, DevOps peut être une approche plus efficace. Dans les environnements plus petits, la collaboration tend à être plus intime, le rythme est plus agile et il y a généralement moins de friction organisationnelle. Il est important de noter que l’ingénierie de plateforme ne sert pas de remplacement au DevOps. Elle n’émerge pas pour remplacer le DevOps. Bien que beaucoup disent que le DevOps est mort avec l’avènement de l’ingénierie de plateforme, ce n’est pas une situation où l’un remplacera l’autre : les deux approches peuvent se compléter. L’ingénierie de plateforme peut être considérée comme une évolution du DevOps, car elle partage le même objectif et peut en améliorer l’efficacité. Il est probable que nous verrons toujours beaucoup de culture DevOps, et il est également probable que de nombreuses organisations d’ingénierie logicielle auront des équipes de plateforme établies pour aider à rassembler les développeurs de logiciels et les opérations informatiques.
Où la sécurité s’inscrit-elle dans ce nouveau paradigme ?
Il est impossible de parler de DevOps sans parler de sécurité (ou DevSecOps); après tout, la sécurité est la priorité zéro. DevOps aborde la sécurité en “décalant à gauche”. Contrairement aux méthodes traditionnelles de développement de logiciels, où les tâches liées à la sécurité n’étaient abordées qu’à la fin du cycle de vie du développement logiciel (SDLC), ce qui pouvait entraîner des retards de projet et n’était pas évolutif, DevOps/DevSecOps intègre la sécurité à chaque étape du SDLC dès que possible, en utilisant des outils d’automatisation. Cette approche est connue sous le nom “de cuisinier” (“baking in”) la sécurité. Pour illustrer, lors de l’écriture de code, les développeurs tiennent compte des problèmes de sécurité potentiels, tels que le stockage et la récupération sécurisés de secrets et de références, plutôt que d’attendre un audit ou une revue finale avant de pousser en production. De plus, lors de la création d’images de machines virtuelles ou de conteneurs, des analyses de vulnérabilités sont automatiquement effectuées lors de chaque build, et toutes les vulnérabilités trouvées sont immédiatement traitées, plutôt que de procéder à une analyse ponctuelle avant l’expédition en production.
Le “shift left”
Toutes ces méthodes de traitement des questions de sécurité de manière plus agile, réactive et automatisée en “décalant à gauche” sont toujours applicables à l’ingénierie de plateforme ; il n’y a pas de contradiction ici en ce qui concerne DevOps et l’ingénierie de plateforme. Avec l’aide de l’ingénierie de plateforme, les portails de développeurs internes peuvent automatiser l’ensemble du processus de manière plus poussée. Considérez trois exemples concrets : Tout d’abord, la création d’un nouveau microservice. Au lieu d’écrire du code de base et d’assembler manuellement des pipelines CI/CD, des fichiers Docker et des manifestes Kubernetes, le portail de développeurs interne peut amorcer l’ensemble de votre projet en utilisant des modèles existants. Ces modèles comprennent du code de base pour l’application, ainsi que des pipelines préconfigurés qui suivent les meilleures pratiques DevSecOps. Ils recherchent également des secrets codés en dur dans le code source et vérifient les YAML, entre autres choses. Le 2ème scénario envisagé est le besoin de stocker des secrets. Au lieu de chercher le gestionnaire de secrets que l’équipe utilise et de déterminer si celle-ci a la permission de créer des secrets, il est possible d’aller sur le portail de développeurs interne, qui s’intègre au gestionnaire de secrets. Ici, il est possible de créer des secrets de manière autonome sans se soucier des détails sous-jacents, grâce au niveau d’abstraction approprié fourni par l’ingénierie de plateforme.
Les 3 principes de la beauté de l’ingénierie de plateforme
Enfin, on peut imaginer le lancement d’une nouvelle machine virtuelle dans le cloud. Au lieu d’écrire du code d’automatisation à partir de zéro ou de copier-coller à partir de la base de code existante et de vérifier les paramètres des groupes de sécurité avant le déploiement, imaginez qu’il s’agisse simplement d’aller sur le portail de développeurs interne, de cliquer sur un bouton et d’attendre que tout soit déployé en utilisant un modèle maintenu et sécurisé par l’équipe d’ingénierie de plateforme ? La beauté de l’ingénierie de plateforme réside au final dans ces principes :
- Libre-service
- Bon niveau d’abstraction
- Les meilleures pratiques et l’automatisation intégrées
Cette introduction à l’ingénierie de plateforme permet une meilleure compréhension de la raison pour laquelle elle a émergé et de sa proposition de valeur centrale pour les développeurs, ainsi que des différences avec DevOps et de la manière dont la sécurité est abordée avec ce nouveau paradigme.
Tiexin Guo, Guest Security expert @Gitguardian
