Les responsables informatiques doivent s'engager et adopter DevOps
Les professionnels de l’informatique sont des gens très pratiques. DevOps en tant que transformation culturelle n’est souvent pas suffisamment tangible pour ceux qui sont chargés de déployer des applications en production et de maintenir leur disponibilité, leur sécurité et leurs performances. Mais la réalité est que le changement culturel – la suppression des cloisonnements inter et intra-groupes – doit se produire, et le plus tôt sera le mieux.
Cela est particulièrement vrai lorsqu’il s’agit de l’impact des tendances et des architectures émergentes sur le réseau.
De nombreux dirigeants et praticiens axés sur le réseau n’accordent pas autant d’attention à l’évolution du paysage de l’architecture des applications. L'évolution vers les API et les microservices, par exemple, est rarement quelque chose dont nous parlons vraiment dans le monde des réseaux, à part le fait que notre infrastructure dispose également d'une API. Parce que SDN (ou SDDC).
Mais ils doivent être conscients de ces changements et de la manière dont ils auront un impact (non pas s'ils auront, mais ils auront) sur le réseau et la fourniture de ces applications aux consommateurs et aux collègues exigeants. Même ce qui semble être une décision d’architecture application peut s’avérer avoir un impact significatif non seulement sur l’architecture du réseau, mais également sur les performances et les exigences du réseau. La décision d'utiliser des microservices multi-locataires ou mono-locataires, par exemple, a un impact significatif sur les services réseau, de la sécurité au routage et à la commutation de base. Le fait de ne pas reconnaître les décisions architecturales concernant l’utilisation de HTTP/2 ou HTTP/1 en conjonction avec les microservices peut entraîner des problèmes importants sur le réseau et réduire les performances.
Les développeurs sont de plus en plus conscients de l’impact de leurs architectures à l’intérieur et à l’extérieur de leur domaine. La latence du service (le temps nécessaire à deux services pour communiquer sur le réseau) est un problème bien connu dans une architecture application hautement distribuée. Ce que les développeurs ne savent pas, c’est comment le réseau (et sa pile de services) peut contribuer à atténuer l’impact négatif sur les performances (et la résilience) d’un tel environnement.
C’est ce que les networkers savent.
Le problème est que les spécialistes du réseau ne sont pas impliqués tant que onze milliards de microservices ne sont pas mis en production. Ils n'ont pas été consultés et faire des suggestions au moment où ils sont engagés signifie potentiellement une refonte importante des services ou de application. Même un simple changement interpolant l'évolutivité dans le réseau plutôt qu'en interne à l'application devient un cauchemar. Mais si les services avaient été conçus en tenant compte de l’évolutivité du réseau, tout se serait déroulé sans problème.
Mais ce n'était pas le cas, et ces 9 dirigeants sur 10 ressentent-ils la pression de sortir leurs applications plus rapidement ? Ils se sentent encore plus sous pression parce qu’il faut du temps pour apporter les changements nécessaires au réseau afin de fournir autant de services interconnectés, interdépendants et liés entre eux.
Il existe quatre opérations en informatique : l’infrastructure, le réseau, le stockage et la sécurité. Et les quatre silos (ou tours si vous préférez une métaphore plus médiévale) doivent construire des ponts entre eux qui favorisent la collaboration et la communication plus tôt dans le cycle de développement. La collaboration sur les choix architecturaux doit être faite lors de la conception et non lors du déploiement. Et cette collaboration peut devoir être initiée par des dirigeants qui ont une visibilité sur chaque organisation pour savoir quand de nouvelles technologies et architectures sont envisagées.
DevOps ne se résume pas seulement à l’automatisation : c’est un outil et une technique pour atteindre un objectif. L’automatisation peut jouer un rôle important dans la réduction de la charge de travail de ceux qui sont chargés de déployer les services nécessaires au déploiement et à la distribution des applications, ce qui libère les experts dans les quatre domaines opérationnels. Cela leur permet de s’engager dans une plus grande collaboration – partage – entre les organisations afin d’améliorer l’échelle, les performances et la sécurité des applications essentielles à l’économie croissante des applications.
La réussite et la croissance d’une entreprise dépendent de la collaboration au sein de l’informatique, non seulement sur le terrain, mais également à la table des dirigeants.