Container – Ohé du bateau

Logi SA, une entreprise logistique de taille moyenne, est très orientée client. Pour offrir le meilleur service à sa clientèle exigeante, elle a mis en place une IT moderne combinant son infrastructure sur site avec des services extensibles et innovants multicloud. Logi SA souhaite déployer une nouvelle prestation: informer ses clients à tout moment de l’état actuel de leurs ­livraisons. Son ERP ne permet cependant ni de déployer les véhicules de livraison, ni de suivre en temps réel leur localisation. Divers hyperscalers proposent à cet effet des modules IoT prêts à l’emploi, que Logi SA peut facilement intégrer dans son infrastructure multicloud à l’aide de containers. Pour Logi SA, cette technologie a de nombreux avantages, à commencer par la réduction importante du temps nécessaire aux tests, au déploiement et à la maintenance, et donc une plus grande capacité d’adaptation aux changements du marché et des besoins de ses clients.

Combiner de grands composants IT sans restriction

Les architectures microservices basées sur des containers sont un moyen éprouvé de simplifier l’intégration de nouveaux services dans les environnements hybrides multiclouds, aujourd’hui très répandus. La popularité des containers n’est pas surprenante, car les applications qui y recourent sont de plus en plus complètes. Par le passé, les containers servaient essentiellement à des applications développées à l’interne, principalement des applications web simples destinées à des domaines peu critiques, alors qu’aujourd’hui, les éditeurs de logiciels d’entreprise les livrent de plus en plus souvent sous forme de containers. Dans le même temps, la portabilité (découplage de l’infrastructure sous-jacente et des environnements d’exécution) s’est considérablement améliorée. Les plateformes étant aujourd’hui agnostiques, les entreprises bénéficient d’un niveau d’interopérabilité très élevé et elles peuvent combiner presque sans restriction les services d’un large éventail de fournisseurs.

De l’île à l’archipel

Le «paysage informatique global» est passé de centres de données formant chacun un îlot gérable, à un archipel de composants et de services provenant de multiples fournisseurs. Tous ces éléments sont reliés par un réseau fait d’innombrables tunnels avec un trafic de données encapsulé et un ensemble croissant de règles de sécurité. Dans une architecture microservices, les containers renferment les composants d’une application, ce qui permet d’employer différentes technologies, mais entraîne aussi un large éventail de langages de programmation, frameworks et autres bases de données.

Le défi de la complexité

Ces deux évolutions apportent d’innombrables possibilités et augmentent la capacité d’innovation, mais elles peuvent aussi entraîner une complexité augmentant à un rythme exponentiel. Opérer de manière fiable des applications multi-langages sur différentes plateformes n’est pas une gageure.

Il convient donc de développer et de respecter des politiques de sécurité, par exemple via des mécanismes garantissant que les containers et les composants logiciels sont autorisés seulement dans un environnement répondant à certains critères. L’élaboration technique de ces politiques nécessite une compréhension approfondie des Workloads et de leurs caractéristiques. Du point de vue de la sécurité informatique, il s’agit de repenser les architectures applicatives et d’intégrer des concepts tels que le zero trust. Toutes ces activités requièrent des compétences IT spécifiques, faisant parfois défaut à l’interne, en particulier chez les PME. Il est dès lors conseillé de déléguer les tâches de sécurité et d’exploitation à un partenaire IT qualifié disposant d’une large palette d’experts.

----------

Avec les standard cloud native, l’entreprise est plus indépendante

Entre le multicloud, les architectures microservices et le recours à des containers, les entreprises ont de nombreuses options en matière de stratégie applicative et de sourcing. En entretien, Mario Iseli explique comment faire les bon choix. Interview: Nadja Baumgartner

Les modèles informatiques hybrides sont en plein essor. Faut-il travailler avec plus d’un fournisseur cloud?

Il convient de noter que tous les fournisseurs de cloud offrent des fonctionnalités différentes. La question qui se pose est donc la suivante: quelles exigences commerciales doivent être couvertes et quel fournisseur y répond le mieux? Les considérations sur la diversification des risques peuvent plaider en faveur de plusieurs fournisseurs cloud. En général, éviter le lock-in réduit la dépendance à l’égard d’un fournisseur et de ses plans pour le futur. D’autre part, pour les gros clients ayant des workloads importants, les arguments de prix peuvent plaider en faveur d’une stratégie de sourcing unique, sachant qu’il est plus aisé de négocier avec un fournisseur auquel on achète de gros volumes. Quel que soit le nombre de fournisseurs, une entreprise peut conserver son indépendance en construisant ses applications proprement sur la base des standard portabilité cloud native, ce qui permet ensuite de les déplacer rapidement d’un environnement à l’autre.

Comment gérer la complexité qu’entraîne une multitude de fournisseurs?

Le paysage applicatif d’une entreprise est généralement diversifié sur le plan technologique. Les applications d’entreprise sont souvent construites avec des architectures monolithiques traditionnelles. En revanche, les applications métier modernes sont souvent développées en interne avec des microservices qui reposent sur une architecture cloud native. Les entreprises doivent donc maîtriser des opérations mixte sur des architectures modernes et legacy, ce qui demande beaucoup de ressources – au final, il faut que la fonctionnalité de toutes les applications critiques soit garantie 24 heures sur 24. A cette fin, certains prestataires IT proposent une sorte de service de pompiers: en cas de dysfonctionnement, des experts sont dépêchés sur place pour fournir une assistance sur tous les composants concernés. Il est également possible d’externaliser le risque opérationnel auprès d’un opérateur, avec lequel on définit conjointement les objectifs de niveau de service.

Quels sont les avantages d’une architecture microservices par rapport à l’approche monolithique?

Des interfaces clairement définies entre les différents microservices permettent de répartir la responsabilité des composants entre plusieurs équipes DevOps. Il est ainsi plus simple de maintenir et de remplacer les composants individuels et les opérations peuvent être rationalisées. Le remplacement d’un microservice peu critique réduit le risque lors des changements et déploiements, ce qui permet des cycles de release plus court (déployés plus rapidement).

Les entreprises gagnent-elles en flexibilité, lorsque tous leurs applicatifs s’appuient sur des architectures microservices?

Elles peuvent commencer par y recourir pour les applications qu’elles contrôlent: celles qu’elles développent à l’interne et celles qui sont développées sur mesure par un prestataire. Dans les deux cas, il est bon de définir des standards clairs et uniformes. Les règles relatives à l’authentification et à l’autorisation sont importantes: il convient de définir selon quels modèles les différents microservices communiquent entre eux, comment s’appliquent les directives de sécurité, comment s’effectuent l’exécution des tests automatiques ou la vérification des Artifacts en matière de vulnérabilités connues, etc. Si ces standards sont clairement définis et respectées, l’entreprise gagne en flexibilité, car le passage d’un fournisseur à l’autre devient un jeu d’enfant et désamorce tout effet de lock-in.

Quelle approche spécifique recommandez-vous pour mettre en œuvre une stratégie de microservices dans l’entreprise?

Il n’y a pas une approche unique qui conviendrait à toute organisation. L’approche dépend fortement du paysage applicatif et des plans futurs de chaque entreprise. La stratégie en matière de microservices est l’un des aspects de la modernisation des applications, qui fait elle-même partie de la stratégie cloud et IT de l’entreprise, laquelle doit être alignée sur les objectifs business. Les microservices et les containers ne sont pas une fin en soi, mais des facilitateurs.