Une nouvelle étude mondiale indique que 69 % des entreprise en région Asie-Pacifique et Japon ont mis en œuvre DevOps. DevOps permet une meilleure collaboration et améliore ainsi l’efficacité opérationnelle, accélère l’innovation et le délai entre un concept et les bénéfices apportés par de nouveaux services.

Avec l’avènement des applications à la demande, du cloud, de la distribution de contenu, de la 5G et de l’Internet des objets, l’ère des réseaux statiques et des logiciels statiques est révolue. Ces technologies exerceront une pression supplémentaire sur le réseau et poseront ainsi de nouveaux défis aux entreprises, les incitant à agir et à mettre en œuvre de nouvelles plates-formes logicielles et réseau avancées. Afin de maintenir un avantage durable dans l’économie à la demande et à l’échelle du Web, les entreprises doivent revoir leurs pratiques informatiques pour innover et réagir plus rapidement aux menaces de leurs concurrents.

Des entreprises réparties sur l’ensemble de la région APAC utilisent DevOps afin de créer, modifier, tester et valider des logiciels et assurer les objectifs suivants : en premier lieu, offrir rapidement des services différenciés, générateurs de revenu à leurs utilisateurs finals et, en second lieu, assurer un contrôle efficace de tous les dispositifs matériels ou virtuels sur le réseau.

Dans les petites sociétés en pépinière, comme dans les grandes entreprises, les équipes adoptent la culture DevOps pour faire avancer leurs applications et répondre rapidement aux changements. Mais le secret de la réussite DevOps ne repose pas simplement dans ses outils, mais plutôt dans la manière de le déployer et de l’appliquer. Voici, donc, 5 caractéristiques essentielles des déploiements DevOps réussis :

1) Respecter la culture de l’organisation
Le facteur de réussite primordial d’un déploiement DevOps est le personnel de l’organisation et la façon dont ses membres travaillent ensemble. DevOps représente un changement radical dans la manière de fonctionner de l’organisation. Il est malheureusement beaucoup plus difficile d’apporter un changement de culture dans une organisation que d’adopter un petit nombre de nouvelles pratiques logicielles.

Une culture collaborative et respectueuse doit être établie sur l’organisation informatique complète de la société, dans laquelle le développement (Dev) et les opérations d’exploitation (Ops) collaborent de façon productive. Une philosophie fondamentale de DevOps est que les développeurs, le personnel d’exploitation et les équipes d’assistance doivent se considérer mutuellement comme des acteurs importants et rechercher activement le travail en commun.

2) Procéder par petites étapes
Le passage à une organisation DevOps est facilitée et rencontre moins de résistance s’il est mis en œuvre à « petits pas » : avec des déploiements plus simples et plus fréquents, plutôt qu’un gros changement, rendant toujours l’adaptation plus difficile. Des déploiements de dimension plus restreinte sont plus simples à tester et beaucoup moins risqués.

3) Utiliser une orchestration du système pour profiter des avantages liés à l’automatisation
Pendant la mise en œuvre de DevOps, les sociétés doivent avoir conscience qu’elles peuvent créer de nouveaux compartiments quand elles mettent en œuvre des déploiements spécifiques à un domaine. Un service central de coordination est nécessaire pour donner une visibilité d’un bout à l’autre sur la façon dont sont déployés les différents aspects du système réseau tout en permettant à chaque domaine de se gérer de manière autonome afin de réduire la complexité de la gestion et d’éviter la duplication fonctionnelle. Une orchestration du système sur plusieurs domaines permet de gérer et de manipuler les services de bout en bout, à partir d’un point central et à un niveau d’abstraction élevé.

4) Accommoder les systèmes hérités quand cela est nécessaire
Les grandes entreprises particulièrement dans des secteurs sensibles comme ceux des services financiers et de la santé, par exemple, subissent souvent des contraintes complexes liées aux infrastructures héritées.

La mise en œuvre de DevOps dans une unité d’activité peut avoir un impact sur une autre application, ou avoir des ramifications juridiques. Ces organisations doivent réfléchir à de nouvelles manières d’intégrer la mentalité DevOps à leurs procédés standards.

Les entreprises de ce type doivent être pragmatiques avec les systèmes hérités : une certaine hétérogénéité fait partie de la vie des réseaux. Ces organisations peuvent envisager ce que Gartner appelle une « informatique bimodale », équilibrant le besoin de garder des processus hérités dans certains domaines, tout en automatisant ceux où cela est possible pour parvenir à une agilité et une stabilité informatique.

5) Adopter un jeu d’outils DevOps, puis le faire eux-mêmes
Le jeu d’outils DevOps choisi par l’entreprise est ce qui lui permettra de développer rapidement de nouveaux services virtuels, de les personnaliser et de les différencier. Plutôt que d’externaliser auprès de gros intégrateurs au point d’en devenir dépendantes, les entreprises doivent choisir un jeu d’outils leur donnant les moyens de prendre les commandes, une fois que quelqu’un les a guidées à travers le démarrage initial et une formation de départ. Le jeu d’outils doit idéalement permettre aux entreprises de construire elles-mêmes des services ou de recourir à une équipe de services professionnels pour le faire, mais elles ne doivent pas être contraintes à l’une ou l’autre approche.

Dans l’environnement actuel des affaires en évolution rapide, la « vieille méthode » de conduite des affaires n’est pas viable. Un logiciel DevOps offrant du choix, de l’ouverture, des moyens et une approche en libre service doit être associé à une méthode de développement alliant pragmatisme et réflexion stratégique. Ce modèle permettra aux entreprises d’intégrer leur développement de produit, leur informatique et leurs opérations afin de créer un écosystème interconnecté réduisant les délais nécessaires pour offrir de nouveaux services et pour s’adapter rapidement aux changements des besoins du marché.

Cet article a été publié initialement sur CIO Asia.