Depuis plusieurs années maintenant, les évangélistes de la plate-forme plaident pour que les outils PaaS soient excellents pour l’expérience des développeurs. Les outils PaaS accomplissent généralement cela en effectuant des changements dans trois domaines de l’expérience des développeurs : le débit, l’efficacité et la productivité. Dans cet article, une base solide pour cette affirmation est établie au moyen de la théorie et de la perspicacité de praticiens actifs.
La loi de Little
La loi de Little stipule :
Débit = Travaux en cours ÷ Temps de cycle
La loi de Little fournit une approche simple pour évaluer l’efficacité de tout système de file d’attente. Il aide à déterminer le nombre (moyen) d’éléments dans une file d’attente stationnaire et dépend des éléments déjà présents dans la file d’attente ainsi que des éléments supplémentaires arrivant en tête.
Ce qui nous préoccupe, c’est l’application de la loi de Little au travail qui doit être fait par les ingénieurs d’une équipe de génie logiciel. À l’origine, cette loi a été formulée à partir d’une combinaison de recherche opérationnelle et de théorie des files d’attente; il a une immense application en génie logiciel.
Considérez n’importe quelle organisation ayant plusieurs équipes de développeurs de logiciels, chacune travaillant sur des parties distinctes du code de l’entreprise. Ils suivent la méthodologie DevOps et mettent fréquemment en production. Malheureusement, en raison de la nature du logiciel, le code fourni par les ingénieurs rencontre des problèmes de fiabilité et de latence lorsqu’il est en production.
Files d’attente croissantes, application de la loi de Little
Ces problèmes, ainsi que de nouvelles fonctionnalités, constituent désormais le pipeline des développeurs de l’organisation. Au fur et à mesure que davantage de code est fourni à la production par les développeurs, la quantité de logiciels à maintenir par eux augmente de manière monotone. Ajoutez à cela – l’infrastructure, la surveillance, la sécurité et d’autres aspects en raison de la prédominance de la culture du « décalage à gauche ». Les développeurs sont désormais responsables de l’écriture et de la maintenance d’un grand volume de code sans rapport avec l’application. Il en résulte que les ressources d’ingénierie sont détournées de là où elles sont les plus précieuses.
Entrez dans Kubernetes !
L’introduction de Kubernetes a vraiment accru la complexité, impliquant davantage les développeurs dans sa configuration, sa maintenance et son démontage. Cette complexité supplémentaire a eu pour effet de les éloigner davantage des tâches liées au développement d’applications. Au lieu de cela, il a des développeurs travaillant avec l’infrastructure et la configuration de Kubernetes. Cette citation des gens de Garden.io résume assez bien la situation : en moyenne, un développeur cloud ne passe que 11 % de son temps à écrire du code. Au lieu de cela, environ 3 fois plus de temps est consacré à travailler sur le passe-partout, la plomberie, le débogage des pipelines, l’attente et l’écriture de « code sur code » qui n’a pas grand-chose à voir avec leur entreprise.
Daniel Bryant, écrivant pour InfoQ, rapporte, Bien que Kubernetes ne fournisse pas une plate-forme complète en tant que service (PaaS) comme une expérience prête à l’emploi, la combinaison d’une API bien définie, d’abstractions claires et d’une extension complète points en font un élément fondamental parfait sur lequel s’appuyer. Ces aspects ont rendu la communauté des développeurs très réceptive à Kubernetes. Cependant, en réalité, le contrôle d’accès, la journalisation, la surveillance, la mise en réseau, l’entrée, le stockage, les sauvegardes et la gestion des secrets sont nécessaires pour rendre les clusters Kubernetes prêts pour la production.
La technologie pour l’amour des technologies ?
Plusieurs personnes ont fait écho au sentiment que Kubernetes n’est pas une plate-forme complète en soi. D’après le blog Platform.sh ― Kubernetes lui-même n’est pas une plateforme ; c’est un cadre dans lequel vous pouvez en construire un. Il est bien connu que Kubernetes est un élément unique d’une plate-forme beaucoup plus grande nécessaire pour exécuter des services en production. La complexité de Kubernetes apparaît souvent comme une énorme barrière à l’entrée pour ce qui est une technologie bien conçue qui a des contrats bien définis entre ses composants. Le succès de Kubernetes vient du fait qu’il est l’un des outils d’orchestration de conteneurs les plus flexibles. Introduit à une époque où les équipes d’ingénierie logicielle avaient du mal à gérer les conteneurs à grande échelle, il s’agit désormais de l’un des projets open source les plus populaires au monde.
Le sentiment d’urgence est faible pour les équipes d’ingénierie logicielle des grandes entreprises. Ils disposent de ressources et d’une bande passante suffisantes pour soutenir leurs efforts visant à créer la bonne plate-forme pour leurs équipes logicielles. Ce n’est pas non plus pour les startups en évolution rapide. Ils ont des chemins dorés configurés pour la production, qui leur serviront pour le moment. Au lieu de cela, ce sont les centaines de milliers d’entreprises de taille moyenne qui ont le besoin le plus pressant. Ces équipes se sont développées au-delà des premières phases de bricolage de scripts et n’ont pas atteint les niveaux d’investissement d’équipes plus importantes.
Le temps gagné est de l’argent gagné
Le temps de développement, ou le mois-homme (ou la variante mois-personne la plus adaptée au sexe), est la ressource la plus précieuse d’une équipe d’ingénierie logicielle. On peut aussi l’exprimer naïvement en multipliant simplement le coût unitaire par le nombre total d’heures travaillées par les ingénieurs. Formuler cela en termes de calcul reviendrait à intégrer le coût d’emploi des ingénieurs en fonction du temps dans une plage de temps. Ces approches s’effondrent lorsqu’une analyse plus approfondie est faite de la nature variée du travail qu’un ingénieur est appelé à faire. Par exemple, la communication au sein de l’équipe est une partie essentielle du travail d’un ingénieur. Cela inclut la communication au sein de l’équipe, avec les parties prenantes externes et la communication sur les réseaux sociaux. Il existe également des interruptions imprévues des travaux antérieurs, telles que le triage des bogues, la dette technique et d’autres travaux consultatifs.
Le récent passage à des paradigmes, tels que l’infrastructure en tant que code et la gestion des conteneurs en tant que code, a été mené par le mouvement « Shift Left ». Cela a amené les développeurs à rationner leur temps entre l’écriture (et la maintenance) du code qui est responsable de diverses choses en plus de contribuer à l’application principale. Cela ronge davantage la ressource critique; temps de développeur.
Kubernetes englobe tous ces paradigmes. Par nature, Kubernetes adopte une syntaxe déclarative, qui dépend fortement d’états programmés manuellement qui sont imités par les systèmes en cours d’exécution. L’utilisation de l’automatisation le long du pipeline CI/CD natif du cloud, des étapes de développement à la production, nécessite que toutes les parties soient gérées à l’aide de code. Cela représente une surcharge importante pour les développeurs, qui doivent les écrire et les tenir à jour.
(*ou la variante mois-personne la plus adaptée au sexe)
Pour les développeurs, cela se traduit par une réduction supplémentaire du temps disponible pour le développement d’applications. Cela fera exploser l’organisation de manière désastreuse, à savoir des cycles de développement de produits plus lents, ce qui signifie une stratégie de mise sur le marché lente, ce qui entraîne une perte d’avantage concurrentiel, entraînant finalement un arrêt brutal des entreprises.
Le PaaS est-il une bonne réponse ?
La technologie doit également résoudre ces problèmes. Il le fait sous la forme d’outils PaaS – des voies d’accès à la production spécifiquement avisées, sans friction et en or. Les cadres d’opinion ont réussi parce qu’ils abstraits efficacement la complexité entourant les couches sous-jacentes, ce qui réduit au minimum le temps que les développeurs doivent consacrer à des tâches autres que le développement d’applications. L’utilisation de PaaS peut généralement augmenter considérablement la vitesse des développeurs, ce qui se traduit par des versions plus rapides et plus fréquentes, ce qui est la mesure éprouvée de la productivité des équipes d’ingénierie logicielle. Les outils PaaS peuvent également aider à soulager les équipes d’ingénierie qui ont construit des spaghettis de script autour de leurs processus de déploiement.
L’inconvénient de l’approche PaaS est que les besoins d’une équipe d’ingénierie logicielle devront vraiment résonner avec la conception du PaaS. Ne pas le faire entraînera une mauvaise expérience de développement.
Un nombre croissant d’outils ont un impact sur l’écosystème PaaS autour de Kubernetes. Certains des exemples les plus anciens sont : RedHat OpenShift, Cloud Foundry Korifi et Google kf. Plus récemment, une poignée d’entrants, tels que D2IQ, KubeFirst, Qovery, Napptive et Acorn, ont émergé dans l’espace. Il existe également quelques outils qui ont adopté une approche git-first, se faisant appeler GitOps. Quelques exemples sont Weaveworks et Gimlet.
Si vous travaillez vous-même avec Kubernetes, je vous encourage à utiliser l’un des outils PaaS répertoriés ci-dessus. Travailler sur des plates-formes de développement internes est également une bonne alternative, mais s’accompagne de coûts associés qui peuvent être non négligeables. Le réglage fin des outils PaaS pour qu’ils s’intègrent parfaitement aux flux de travail des développeurs peut garantir l’amélioration des mesures de productivité.