C’est une chose simple de trouver des références au cycle de l’innovation. Tapez simplement « cycle d’innovation » dans votre moteur de recherche préféré et vous serez récompensé par des millions de références en un clin d’œil. Cependant, trouver des références sur le cycle de complexité est désormais un peu plus difficile. C’est peut-être parce que je viens de l’inventer, mais je ne doute pas qu’elle existe et qu’elle continuera d’exister, tout comme l’innovation.
La complexité n’est pas nouvelle. Nous disposons de plusieurs générations de langages de programmation pour le prouver. Le nombre de personnes qui comprennent et peuvent exploiter la puissance du langage assembleur, par exemple, diminue. Enquête 2023 de Stack Overflow a trouvé (un chiffre quelque peu impressionnant) 5,43 % de ses 90 000 répondants qui ont une expérience avec le langage assembleur. Comparé aux 63,61 % familiers avec JavaScript ou même aux 49,28 % expérimentés avec Python, ce nombre est faible.
En fait, en regardant la liste, vous pouvez voir le cycle de complexité en action. Près du bas se trouvent les premiers langages comme l’assembleur. En montant dans la pile, vous rencontrerez C, C#, Python et JavaScript. C’est comme parcourir la chronologie évolutive des langages de programmation.
Chaque génération de langages est développée pour répondre à une certaine complexité inhérente à son prédécesseur. Java a tenté d’éliminer les horreurs généralisées de la manipulation de la mémoire des pointeurs inhérentes au C et au C++ en supprimant la gestion et l’accès à la mémoire.
Abstraction loin. C’est là l’essentiel à retenir, car c’est presque un axiome selon lequel la manière dont la technologie aborde la complexité consiste à abstrait loin.
Ce n’est pas être concernantdéplacé; il est simplement déplacé. La complexité est toujours là, cachée sous une interface plus simple.
Vous pouvez constater le cycle de complexité dans l’évolution de l’automatisation des services réseau et applicatifs. Des API impératives qui nécessitaient des centaines d’appels d’API individuels pour configurer un système aux API déclaratives d’aujourd’hui qui n’utilisent qu’un seul appel d’API. C’est plus simple, bien sûr, mais seule l’interface a changé. Les centaines d’appels mappés sur des paramètres de configuration individuels doivent encore être effectués, vous n’êtes tout simplement pas obligé de le faire vous-même.
La complexité vous a été retirée et a été confiée au système et à ses développeurs.
Cela semble génial, j’en suis sûr, jusqu’à ce que quelque chose se passe mal. Et quelque chose de mal se passera ; il n’y a pas moyen d’éviter que soit. Zero Trust repose sur le principe de « supposer une violation », et l’infrastructure Zero Touch (vers laquelle se dirige l’industrie) devrait avoir un principe similaire, « supposer un échec ».
Ce n’est pas que la complexité évolue. La complexité vient d’un trop grand nombre d’outils, de consoles, de fournisseurs, d’environnements, d’architectures et d’API.
À mesure qu’une entreprise évolue, elle ajoute davantage de ces éléments jusqu’à ce que la complexité submerge tout le monde et qu’une certaine forme d’abstraction soit mise en place. Nous voyons cette abstraction dans l’essor des réseaux multicloud pour répondre au réseau complexe de plusieurs cloud et réseaux de microservices, qui tentent de démêler le désordre à l’intérieur de architectures de microservices.
Les abstractions sous forme de solutions et de services font partie du cycle naturel de la complexité.
Mais avant de se lancer dans la dernière abstraction, les organisations devraient examiner attentivement leur situation actuelle, en particulier l’étalement des opérations internes. Selon notre recherche annuelle, chacun des trente services d’application que nous suivons dans chaque domaine est déployé par 93 % des organisations. C’est juste une catégorie ; nous ne suivons pas comment beaucoup de chaque service d’application est déployé.
Chaque catégorie est livrée avec son propre ensemble de Apis, outils et technologies, et chaque domaine a son propre ensemble de pratiques. Et même si des abstractions surgissent pour répondre à cette complexité, il incombe aux entreprises de déterminer dans quelle mesure cela est dû à des décennies de silos et de décentralisation.
Tout comme les organisations devraient auditer leurs portefeuilles d’applications de temps en temps pour réduire la duplication et la prolifération, elles devraient faire de même avec les services d’infrastructure et d’applications. Nous voyons déjà le début de ce mouvement dans une évolution vers des plates-formes qui fournissent un ensemble plus complet de solutions de sécurité ou de fourniture d’applications et réduisent le nombre d’abstractions nécessaires.
Appelez cela centralisation, appelez cela consolidation, appelez cela réduction de la complexité. Quel que soit le nom que vous lui donnez, éliminer la complexité en standardisant avec une approche de plateforme est un bien meilleur moyen de freiner le cycle de la complexité.
Vous ne pouvez pas arrêter le cycle. Mais vous pouvez le ralentir pour ne pas vous submerger.
Articles Liés:
