En prônant une proximité accrue entre développeurs, métiers et exploitants, l’initiative DevOps et les micro-services entendent délivrer des services plus souples, ouverts et évolutifs. Vérification.

Face aux enjeux du déploiement accéléré de nouveaux services informatiques et de leur intégration continue, l’entreprise rapproche ses responsables métiers des développeurs et exploitants informatiques. C’est tout le sens de l’approche DevOps qui associe des procédures harmonisées à un outillage, en grande partie open source, dédié au packaging des applications, au suivi des versions et à la corrections des bugs fonctionnels ou d’implémentation.

D’un côté, on trouve des développeurs informatiques à faible coût en Inde ou en Pologne par exemple. On peut y externaliser une partie des efforts de développement, la tierce maintenance ou un bureau d’études via quelques contrats d’outsourcing bien rédigés. De l’autre, il faut conduire un changement culturel, dénicher des compétences rares, garantir une maîtrise de toutes les activités IT, jusqu’à la supervision des infrastructures.

« Il y a un ticket d’entrée RH pour
généraliser l’approche DevOps. Il s’agit de modifier les rôles, la culture et les fiches de postes du développement et de la production. »

Alain Sacquet, cabinet TimSpirit

Pourquoi changer de culture informatique ? C’est une mutation qui semble à la fois difficile, chère et compliquée car elle touche l’humain et l’organisation de l’entreprise. “Les ressources unitaires sont plus chères mais on obtient un système tellement plus productif que l’approche DevOps s’avère finalement plus rentable”, assure Alain Sacquet, responsable de l’offre DevOps au cabinet TimSpirit et auteur de “Mettre en œuvre DevOps” (Dunod, 2016).

D’après lui, mieux vaut basculer vers des équipes intégrées, avec des informaticiens complices de la conception jusqu’à l’exploitation des services, en passant par le codage, les interfaces, les tests et la documentation.

Finie la commande de méga-lots vertigineux en interne ou offshore. Finis aussi les contrats reflétant une organisation archaïque. L’approche DevOps défend une réalisation par petits incréments, planifiés, vérifiés et validés avec les métiers. Autrement dit, pas de DevOps sans business et réciproquement.

Une collaboration orientée qualité

Qui est concerné par l’initiative, les entreprises du CAC40, les grandes administrations, les industriels, les ETI, les PME ? “Tout le monde est concerné. Les grandes banques comme les startups. C’est un mode de travail plus réactif, plus qualitatif, plus productif. La bascule est inéluctable, au même titre que la production à flux tendus dans l’industrie ou les séries limitées sur une même chaîne”, ajoute Alain Sacquet. Où verra-t-on les dernières poches de résistance ? “On les trouvera peut-être dans des entreprises à l’abri des transformations numériques ou bien là où le modèle économique est blindé”,prévoit l’expert.

Les grandes entreprises restent les plus impliquées dans ce rapprochement avec 30 % des sociétés de plus de 2000 salariés déjà opérationnelles, contre 19 % des sociétés de taille moyenne, note l’observatoire DevOps d’IDC : “la différence s’estompe progressivement, 18 % du mid-market est en cours de déploiement ou projette une telle initiative, contre 15 % des grands comptes. Près de 41 % des organisations du secteur public ont initié une approche DevOps, contre 34 % des entreprises privées”, compare encore Karim Bahloul, Research and Consulting Director, d’IDC France.

On le constate, une grosse part du marché reste à conquérir. D’autant que les besoins de mobilité, la stratégie multicanal et la transformation numérique accélèrent la mise en œuvre de cette approche. Toutefois, le besoin d’accompagnement n’en demeure pas moins réel.

Démarrer par une analyse de maturité

“DevOps nécessite un cadre de travail, en particulier dans les entreprises dont l’héritage en applications monolithiques est lourd. C’est le premier frein technique et organisationnel à son adoption”, remarque Philippe Puschmann, directeur de la communauté de talents DevOps, Agilité, Scrum d’Avanade, intégrateur en technologies Microsoft auprès des grands comptes.

Il conseille de démarrer par une analyse de maturité DevOps, un examen préalable mené sur sept axes, à partir duquel un plan d’accompagnement sera élaboré. Outre le recueil de cas d’usages, cette phase inspecte la cohésion des équipes IT. L’étude cerne la dette technique, la vitesse de traversée d’un nouveau service jusqu’à sa mise en production, apprécie les efforts d’analyse, de tests, jauge la détection d’anomalies en production ou encore le temps moyen de résolution d’un bug. Les procédures et l’outillage au complet sont évalués, des diagnostics à la télémétrie en passant par la génération du datacenter qui délivre les ressources d’infrastructures.

“Nous recommandons de commencer par cet état des lieux. C’est une analyse précieuse pour accompagner l’organisation”, confirme l’expert agile. De la feuille de route d’implémentation jusqu’aux tableaux de bord d’aide à la décision, l’accompagnement adresse ensuite la gestion du changement organisationnel, l’architecture applicative, la mise en place de conteneurs et l’industrialisation des développements. L’automatisation de l’infrastructure participe à l’amélioration de la qualité des codes. L’implémentation de solutions ALM (gestion du cycle de vie des services) reste fondée, chez Avanade, sur le socle Team Foundation Server et les outils SonarQube (analyse de qualité du code) et NDepend (analyse d’applications .Net). Le travail collaboratif contribue à “désiloter” la production tandis que la surveillance et la télémétrie capturent les comportements des utilisateurs en vue d’offrir un dimensionnement correct de l’infrastructure à tout moment, y compris lors des pics de charge.

Un outillage ouvert aux standards

Avec son ouverture croissante vers l’open source, et le rachat du studio mobile Xamarin en février 2016, Microsoft démontre une volonté d’élargir son écosystème de développement et de prendre en compte les environnements mobiles Android et IOS ainsi que les outils de production libres tels Maven (moteur de production Java) et Jenkins (serveur d’intégration continue). “Avec la portabilité de Docker sur Azure, sur Amazon et ailleurs, les conteneurs vont former une vague énorme dans les prochaines années. Grâce à eux, nous devenons agnostiques de la technologie d’hébergement sous-jacente. L’offre Release Management de Microsoft peut construire des package Docker tandis que l’offre Azure Container Service assure leur déploiement dans le Cloud de l’éditeur”, précise Philippe Puschmann.

Quiconque songe à l’intégration continue compte en réalité sur une production IT fiable, sans interruption. Mais, en pratique, c’est rarement le cas démontre Guillaume Morel, le président d’Invivoo, éditeur d’outillage DevOps pour la finance : “Même lorsque l’on répartit la complexité d’une application dans des micro-services, évolutifs indépendamment les uns des autres, une base de données absente obligera à relancer le processus. XComponent Studio intervient sur le cycle du packaging et la supervision des micro-services. AC2 ajoute un format pour automatiser les tests fonctionnels, vérifier l’état d’une passerelle Fix [NDLR : protocole et format des marchés financiers] ou le nombre de transactions traitées par la plateforme.”

L’expert voit émerger, au-delà des interfaces communes (API REST), des formats standards de type Swagger pour embarquer la documentation dans le code, apporter de la transparence aux API et stabiliser l’ensemble du puzzle.

Des tests et une maintenance simplifiés

Les micro-services intéressent logiquement les centres de données, pour leurs applications internes dans un premier temps. “Notre système interne est fondé sur un CRM construit de façon itérative pour lequel il y a de la dette technique, un empilement de modifications sur de nombreuses couches. Avec les micro-services, on a la capacité de sortir des petits bouts de métiers progressivement, par exemple la gestion du monitoring, la facturation deviennent des bulles fonctionnelles que l’on peut exposer en terme d’API (application programming interface)”, illustre Philippe Jung, responsable de l’équipe R&D de Celeste. Il apprécie notamment la testabilité simple des micro-services et leur périmètre bien défini, contrairement aux gros blocs de codes monolithiques.

L’approche micro-services facilite la maintenance et permet des évolutions plus rapides de composants conçus par domaine. “Nous générons des API pour les autres services de l’entreprise, qui deviennent des consommateurs internes, pas pour nos clients. Produire des API c’est bien, les documenter c’est mieux. Pour y parvenir et évoluer vers l’intégration continue, nous étudions l’outil Swagger, un framework de suivi pour exposer les API.”

Dans cette transformation, l’ingénieur recommande de bâtir sur les standards (HTTP, REST, JSON), avec un réflexe de développement consistant, dès le départ, à coder sous la forme de modules testables. “Il faut s’assurer que l’API reste en phase avec l’activité métier, indépendante de l’implémentation interne de l’application. Entre nous, on dessine des blocs métiers pour illustrer, par exemple, la préférence d’un client qui souhaite recevoir une facture deux fois par mois plutôt qu’une facture chaque mois. Une fois d’accord sur cet objectif, le concepteur de l’API précise les paramètres qu’il attend en entrée, puis il indique tous les messages qu’il est susceptible de délivrer en sortie.”

La gestion des API gagne du terrain

Pour personnaliser les applications ou pour collaborer avec des partenaires, les API forment un enjeu économique plus qu’un simple point de contact entre services techniques.

Le français Axway a avalé son compatriote Systar en 2014 puis, en début d’année 2016, l’américain Appcelerator, entrant ainsi dans le développement d’applications mobiles et complétant son offre de gestion d’API. Axway API Management Plus facilite le suivi du cycle de vie des API et en améliore la sécurité. Cette solution contribue à mettre en œuvre une intégration et un déploiement continu tout en réduisant les risques d’erreurs. Grâce aux bonnes pratiques DevOps, les développeurs, responsables sécurité informatique et architectes systèmes maîtrisent le développement de leurs API et créent des micro-services fondés sur un référentiel de règles métiers. Axway accélère ainsi la conception d’API exposant des sources de données et la création de micro-services à grande échelle. Ces derniers sont automatiquement déployés sur un environnement Node.js en interne, ou bien sur un Cloud public ou encore sur un Cloud hybride.

Rival d’Axway, Automic réalise des logiciels spécialisés dans l’automatisation de la production qui suivent l’approche DevOps. Cet éditeur autrichien s’est porté acquéreur en 2014 du Français Orsyp, auteur du programme d’ordonnancement Dollar Universe. Il compte pour partenaires les éditeurs Oracle et SAP ce qui lui permet d’automatiser jusqu’aux interactions avec les progiciels de gestion intégrés et les applications frontales de suivi de la relation des clients.

Yann Guernion, le directeur marketing produit d’Automic, rappelle les motivations principales pour retenir l’approche DevOps : “Nos clients adoptent DevOps pour avoir des développements plus agiles et pour fournir à leurs propres clients une qualité logicielle améliorée. En second lieu, ils souhaitent fournir des services plus rapidement, améliorer le time-to-market ou rattraper un retard sur un concurrent. Enfin, le troisième aspect périphérique concerne la transformation numérique, c’est maintenant un grand projet dans de nombreuses entreprises dont la réussite passe par les deux premiers points.”.

La spécificité d’Automic réside dans sa plateforme unifiée adressant plusieurs cas d’usages d’automatisation, via une technologie homogène. Les domaines couverts sont les charges applicatives, la livraison d’environnements et de stacks applicatives ainsi que le suivi des versions avec des phases de tests automatisées. Les interactions ciblent les appels entre web services et les appels entre applications que celles-ci soient exécutées dans le datacenter de l’entreprise ou sur un Cloud public ou privé. Là encore, les outils open source s’avèrent précieux, l’arrêt d’une construction automatique (build) pouvant générer un ticket d’incident sous Jira ou vers un service SaaS comme ServiceNow.

Auteur : Olivier Bouzereau

Source : SOLUTIONS IT n°13/ Novembre - Décembre 2016