Nous ne savions pas que vous aviez besoin de…
De nombreuses personnes évitent la composante « culturelle » associée à DevOps. Mais la « culture » est liée à la « communication », et la communication est essentielle au succès non seulement de DevOps, mais également de tous les efforts d’automatisation et d’orchestration dans l’entreprise.
Nous ne savions pas que vous aviez besoin… du port 7243 ouvert.
Nous ne savions pas que vous aviez besoin… de nouvelles entrées DNS.
Nous ne savions pas que vous aviez besoin… de l’adresse IP du client.
Nous ne savions pas que vous aviez besoin de…
Nous ne le savions pas.
Ces trois petits mots illustrent, peut-être de manière plus poignante que tout autre, le défi de communication auquel sont confrontées de nombreuses entreprises aujourd’hui. Les frameworks et les scripts ne peuvent automatiser que ce que vous leur dites d'automatiser, et cela signifie qu'à un moment donné, vous devez le savoir. Comment savez-vous? C'est ça la communication.
C'est un cliché dans l'informatique que les responsables réseau ne parlent pas aux développeurs et que les opérations n'aiment pas la sécurité, mais la réalité est qu'à moins que chacun des domaines opérationnels qui régissent l'environnement de production ne sache ce qui est nécessaire pour déployer une application en production, elle ne peut pas être orchestrée.
Oh, des tâches individuelles comme la configuration d'un pare-feu ou d'un équilibreur de charge peuvent être accomplies assez facilement, mais chacune d'entre elles nécessite des informations spécifiques à l'application pour être utile. Vous ne pouvez pas ouvrir un port si vous ne savez pas lequel l'application utilise. Nos données iHealth de janvier 2017 montrent que sur plus de 6 000 clients, 36 731 ports distincts (uniques) sont utilisés. Il n'y a pas beaucoup de protocoles utilisés dans l'entreprise (il y en a beaucoup, mais pas tant que ça), ce qui signifie qu'une variété de sites utilisent des protocoles qui ne sont pas sur leurs ports « natifs ». Même les applications Web sont réparties sur plusieurs ports. Il y a ceux qui me viennent sans doute à l'esprit quand je dis HTTP/S : les ports 80 et 443. Et il existe également des ports alternatifs souvent utilisés pour ces protocoles, les ports 8080 et 8443. Ensuite, il y a 8081 (utilisé par 4605 serveurs virtuels différents, qui représentent approximativement des applications) et 8082. Et il y a bien sûr de nombreux ports au-dessus de la plage privilégiée (0-1024) qui sont utilisés sans application apparente (pour moi à partir de mes données). En effet, le port 10203 n'a pas de protocole « standard » qui lui est attribué.
Le problème ici est que nous ne pouvons pas simplement supposer un port spécifique pour un déploiement d’application donné. Ces informations doivent être communiquées, au cas où quelqu'un voudrait exécuter le back-end de son API publique sur un port différent. La sécurité par l’obfuscation est toujours d’actualité, les gars.
En plus d’une donnée aussi simple, vous ne pouvez pas configurer un équilibreur de charge si vous ne savez pas quelle adresse IP publique ou quel nom d’hôte il utilise ou quels services back-end doivent être inclus dans chaque cluster. Ce sont des informations dont vous avez besoin, et ces informations doivent circuler du développement ou des opérations vers les personnes qui gèrent les systèmes, généralement dans les réseaux.
Cela signifie des communications. Ce n’est pas que vous ne pouvez pas créer un outil ou un formulaire pour collecter ces informations. L’économie (autre) des API et les efforts de transformation numérique interne nécessitent presque que ces échanges soient de nature numérique. Mais pour créer un formulaire ou une API pour les collecter, vous devez savoir quelles données vous souhaitez collecter.
Vous devez vous asseoir et en discuter. Autour d'une pizza et d'un café. Autour d'une bière et d'ailes de poulet. Par e-mail ou par téléphone. D'une manière ou d'une autre, vous devez réellement communiquer avec tous les différents groupes responsables du déploiement d'une application et vous assurer que vous savez ce que vous devez savoir.
Lorsque les gens parlent de culture et de communication dans le contexte de DevOps, c’est l’une des choses qu’ils essaient de transmettre.
Bien entendu, il y a plus à dire, mais nous ne pouvons ignorer qu’au cœur de l’accélération des choses pour répondre aux demandes des entreprises et des consommateurs se trouve le simple principe de la communication. De savoir ce dont une application a besoin pour aller plus vite, plus intelligemment et plus en toute sécurité. Parce que ce que vous ne savez pas ne peut pas être automatisé, et ce que vous ne pouvez pas automatiser nécessite une intervention manuelle qui peut introduire des retards et des défis dans le processus de déploiement. Si vous souhaitez que les applications soient plus rapides et plus sûres, vous devez travailler plus intelligemment, pas plus dur, et tout commence par la communication entre toutes les différentes parties prenantes afin que vous sachiez ce qui est nécessaire.
Dans un monde en pleine transformation numérique, savoir représente réellement la moitié de la bataille. C'est l'autre moitié qui est la technologie. Vous ne pouvez pas exécuter avec succès une stratégie numérique qui inclut, en partie, une approche DevOps pour le développement et le déploiement, sans les deux.