Exploiter le DevOps pour surmonter les défis du logiciel embarqué

Le DevOps est considéré comme la meilleure façon de répondre aux demandes du marché du logiciel embarqué : plus d'applications, de nouvelles fonctionnalités, le tout disponible en moins de temps.

Une tempête parfaite se prépare pour le développement logiciel des systèmes embarqués. Les appareils embarqués prolifèrent, notamment grâce aux nouvelles options de connectivité comme la 5G qui rendent possibles des applications innovantes d'appareils connectés, et leur utilisation s'étend, tirant parti de nouvelles capacités d'analyse et d'intelligence artificielle. Parallèlement, les besoins du cycle de vie des appareils, comme la réponse aux cyberattaques évolutives, rendent nécessaire la création et le déploiement rapides de modifications logicielles.

Ces conditions placent de nouvelles exigences sur les équipes de développement et d'opérations. De plus en plus, le DevOps est considéré comme la meilleure façon de répondre aux demandes du marché pour plus d'applications et de nouvelles fonctionnalités, toutes disponibles dans des délais plus courts. RTInsights s'est récemment entretenu avec Graham Morphew, Directeur Senior de la Gestion de Produit chez Wind River. Nous avons discuté des défis du développement logiciel pour appareils embarqués, des différences entre le DevOps pour les environnements traditionnels et les appareils embarqués, et plus encore.

Voici un résumé de notre conversation.

RTInsights : En quoi le DevOps pour les appareils embarqués diffère-t-il des approches DevOps traditionnelles ?

Morphew : Dans un environnement DevOps traditionnel basé sur l'informatique d'entreprise, vous avez un environnement d'exécution ubiquitaire. Vous tournez soit sur des serveurs Intel dans le cloud, soit sur un PC Intel. L'embarqué est très différent. Votre environnement d'exécution final est généralement une architecture différente de celle utilisée pour le développement. Il y a plus de défis en raison de la diversité du matériel final et de la façon dont vous y déployez. Par exemple, quand vous développez pour un environnement cloud, vous savez qu'il ira sur Google Cloud, Azure ou AWS. Quand vous développez du logiciel embarqué, la diversité des environnements de déploiement est quasi infinie, et vous pouvez aussi avoir des appareils dans des endroits reculés.

Il y a donc de nombreuses différences dans la façon de concevoir le logiciel et comment ces différences se traduisent en défis d'implémentation DevOps.

Vous devez faire face à du matériel spécialisé, de la compilation croisée, du débogage croisé, des empreintes mémoire, et des problèmes de sécurité. Vous n'avez pas les ressources quasi illimitées dont vous disposeriez dans un environnement cloud. Il y a une « île d'exécution » à garder à l'esprit lors de la conception de ces systèmes. Vous avez aussi la sécurité à gérer. Vous n'avez pas nécessairement le contrôle physique de la sécurité des appareils. Vous devrez peut-être faire face à du sabotage physique.

Un autre défi : les données de ces appareils sont plus difficiles à collecter. Dans un environnement DevOps, vous voulez une boucle de rétroaction continue. C'est facile si le développement se fait sur des serveurs sous votre contrôle. Quand il s'agit d'appareils, ils seront probablement distribués à distance et pas toujours en ligne. De nombreux problèmes différents entrent en jeu en comparant le DevOps traditionnel et le DevOps pour le logiciel embarqué.

RTInsights : Pourquoi la communauté des appareils embarqués se tournera-t-elle vers le DevOps ? Pourquoi devient-il convaincant, et qu'est-ce qui se passe sur les marchés pour stimuler cela ?

Morphew : Avec le logiciel embarqué, il y a un besoin croissant de mises à jour plus fréquentes et de meilleure qualité. Pour y parvenir, vous avez besoin d'automatisation. L'automatisation jouera un grand rôle dans l'avenir du DevOps et du logiciel embarqué. Il y a une décennie ou deux, l'accent était mis sur le matériel qui pilotait les capacités de l'appareil. Aujourd'hui, une part bien plus grande de la technologie différenciante parmi les fournisseurs d'appareils est logicielle.

Un autre facteur poussant les entreprises vers le DevOps pour les systèmes embarqués est quelque chose que nous voyons souvent chez Wind River : l'évolution démographique du développement logiciel.

Il y a deux camps très distincts. Vous avez vos développeurs traditionnels de logiciels embarqués et les nouveaux diplômés ou développeurs entrant dans le domaine des appareils intelligents depuis d'autres domaines logiciels. Les développeurs traditionnels ont tendance à être plus âgés, et beaucoup partent à la retraite. Comme moi, il y a des gens qui sont arrivés sur le marché à la sortie de l'université à une époque où l'on consultait des manuels matériels, on programmait des registres, etc. Ce n'est plus quelque chose sur quoi les programmes universitaires passent beaucoup de temps maintenant.

J'ai un fils en âge d'être à l'université. Il programme en Python. Il vient d'apprendre le C pour la première fois, et ce fut une révélation. Python offre des niveaux d'abstraction bien plus élevés.

Le DevOps peut aider à surmonter cet obstacle entre l'environnement applicatif et le désir de le rendre familier aux développeurs de logiciels d'appareils. Le besoin de le faire est que les entreprises qui construisent des appareils ont du mal à attirer de nouveaux talents en développement logiciel.

Je parlais récemment à quelqu'un que nous avions embauché comme stagiaire, et il nous a dit que beaucoup de ses camarades veulent aller dans la Silicon Valley travailler pour des entreprises comme Facebook, Google, Apple et Tesla. Pour les entreprises dans les segments industriels ou aérospatiaux et de la défense, il peut être plus difficile d'attirer les talents logiciels nécessaires qui viendraient programmer des appareils embarqués dans un environnement C rudimentaire.

Pour surmonter cela, certaines entreprises pensent qu'offrir à cette nouvelle génération de développeurs un environnement qui leur est familier aidera. C'est l'une des raisons pour lesquelles Wind River adopte un environnement Visual Studio Code. VS Code a connu une croissance rapide de popularité depuis son lancement. Tous ceux à qui nous avons parlé, du point de vue des nouveaux diplômés, connaissent bien VS Code, et nous voyons moins d'expérience avec d'anciens environnements comme Eclipse. Parfois, il faut être là où se trouve déjà votre audience.

RTInsights : Quels problèmes les entreprises rencontrent-elles lorsqu'elles tentent d'adopter des solutions DevOps ? Et quels sont les défis clés pour le domaine des appareils embarqués par rapport aux autres domaines ?

Morphew : Le plus grand défi est le changement culturel qui doit se produire au sein des entreprises. Et ce n'est pas nécessairement un défi spécifique à l'embarqué. Il est plus profondément ancré dans certaines pratiques de développement logiciel.

Vous avez de petites équipes, et dans de nombreux cas, des individus qui effectuent des tâches très spécifiques. Vous avez besoin d'un niveau de collaboration et de coopération avec le DevOps qui sort parfois les gens de leur zone de confort depuis plusieurs années. Il faut dire : « Tout le monde travaille ensemble. »

La partie Ops du DevOps pour l'embarqué est un défi car, dans un environnement DevOps traditionnel pour le cloud, l'Ops est assez standard. Vous gérez un site web ou développez une application qui fait quelque chose via une interface cloud. Quand vous parlez d'embarqué, vous parlez d'un appareil sur le terrain, et ce que cet appareil fait est spécifique à votre entreprise. Dans de nombreux cas, les fabricants d'appareils ne sont pas les entreprises qui les exploitent. Un fabricant d'équipement peut vendre son appareil à une grande entreprise électrique ou un grand fabricant. Ce sont ces entreprises qui exploitent les appareils. Parfois, il y a une assistance du fabricant de l'appareil, mais ce n'est pas une boucle complètement fermée comme vous pourriez le voir avec une solution cloud.

Il y a des problèmes de compatibilité des ensembles d'outils. Avoir un environnement de développement commun rencontre parfois de la résistance. Cela revient à certains des soutiens culturels et de gestion nécessaires pour implémenter ces systèmes.

Et puis il y a à nouveau le problème matériel. C'est un thème récurrent sur le marché de l'embarqué. Comment obtenir suffisamment de matériel pour construire les environnements d'automatisation nécessaires pour faire du DevOps une réalité ? C'est un défi permanent. En général, les clients qui réussissent ont un mélange de matériel et de simulation pour faire évoluer leurs processus de test.

RTInsights : Existe-t-il des outils qui faciliteraient la transition vers le DevOps ?

Morphew : Une chose qui aide les entreprises à traverser cette révolution est la disponibilité des outils. Beaucoup de ces outils sont open source ou ont des versions gratuites. Ce que l'on voyait souvent, c'était une consolidation autour d'une forme de gestion de code source, souvent une variante de Git. Maintenant, les organisations sont passées d'une solution très centrée sur la gestion de code source à l'inclusion de plus en plus d'outils de type DevOps dans leurs solutions. Cela aide les entreprises à faire la transition.

Il y a beaucoup de choix. On pourrait parfois dire qu'il y a trop de choix. Le défi que nous voyons chez les clients maintenant est : oui, il y a beaucoup d'outils. Comment les réunir dans une solution qui fonctionne pour moi ?

Aujourd'hui, de nombreuses entreprises lancent des projets où elles forment des équipes internes pour gérer leur transition vers un environnement de développement plus axé sur le numérique. Nous voyons une transition se produire maintenant dans l'espace embarqué, similaire à ce que nous avons vu avec d'autres transitions technologiques. Dans de nombreux cas, c'est très mentalité « faites-le vous-même » : « Construisons le système parfait pour nous, personnalisons-le selon nos besoins. » De tels efforts drainent de plus en plus de ressources de l'entreprise juste pour maintenir ces choses. Ce n'est pas nécessairement là qu'elles veulent investir. Cette approche évoluera probablement vers une où les gens cherchent à faire maintenir plus de leur environnement par une autre entreprise au fil du temps.

Un autre domaine où les entreprises peuvent finalement se simplifier la vie est d'avoir des séparations claires entre le développement d'applications et la maintenance des plateformes logicielles sur lesquelles elles tournent. Avant, vous aviez une petite équipe qui faisait les deux, et l'application et la plateforme se mélangeaient. Mais maintenant, vous avez besoin de cette séparation claire pour modulariser votre logiciel et avoir des gens qui travaillent sur ce pour quoi ils ont les meilleures compétences.

RTInsights : Quels sont les moteurs de l'industrie pour des solutions qui facilitent le développement et le test de logiciels pour appareils embarqués ?

Morphew : Il y a la convergence des mondes IT et OT. Vous avez des appareils connectés à Internet. C'est un gros moteur pour les entreprises de réexaminer comment elles livrent le logiciel. Aussi, il y a plusieurs industries où vous avez des exigences de conformité pour mettre à jour le logiciel dans les appareils. Vous voyez cela dans le domaine médical, où vous devez maintenant prouver que vous pouvez mettre à jour votre appareil si une vulnérabilité de sécurité est découverte. Cela peut être un scénario de vie ou de mort. Vous devez être capable de prouver que vous pouvez résoudre un tel problème s'il survient.

De tels moteurs poussent les entreprises à examiner les processus qu'elles utilisent concernant leur capacité à faire des mises à jour à distance. Ce que nous voyons, c'est que beaucoup de grandes entreprises ressentent la menace de ces entreprises nouvelles et montantes, nativement numériques. Il y a même des termes pour le décrire. Vous entendez le terme « teslafication ». Ils disent qu'ils doivent être plus comme Tesla et être une entreprise très, très axée sur le logiciel, par opposition à la pensée brique et mortier, acier et fer plus associée au matériel. De plus en plus, ils doivent différencier leur produit sur le logiciel qui tourne sur les choses qu'ils construisent.

La pandémie a également accéléré cette tendance. Vous avez la plupart de la main-d'œuvre axée sur le logiciel qui travaille depuis chez elle. Et dans de nombreux cas, un nombre significatif d'employés ne retourneront pas au bureau après que ce soit fini. C'est un grand changement. Donc, vous devez changer la façon de penser le travail pour rendre cette situation productive pour les développeurs. C'est un défi. Cela crie, dans une certaine mesure, le besoin de plus d'outils de collaboration et de plus de standardisation en termes de façon dont les choses se font parce que vous n'avez pas beaucoup de gens qui travaillent en face-à-face et collaborent de la manière plus traditionnelle.

RTInsights : Passons à un autre sujet, pourquoi les itérations logicielles rapides sont-elles devenues un avantage concurrentiel critique dans chaque industrie ? Et comment cela se rapporte-t-il au besoin de tests automatisés ?

Morphew : J'ai traversé plusieurs projets qui sont passés d'un modèle en cascade à un modèle plus agile. Cette capacité à faire des tests continus, des tests automatisés est souvent le facteur limitant en termes d'augmentation de votre productivité. Si vous allez courir vite et que vous voulez toujours maintenir votre qualité, c'est une nécessité. C'est un domaine particulier où avoir un jumeau numérique de votre appareil final vous permet de faire beaucoup de tests dessus, et vous pouvez le faire à grande échelle.

L'une des grandes avancées que nous voyons en termes de DevOps applicable à l'embarqué est la capacité à prendre une simulation de l'appareil embarqué et à l'utiliser à grande échelle dans un environnement cloud. De cette façon, vous pouvez avoir cent tests qui s'exécutent simultanément. Vous n'êtes limité que par les ressources cloud. C'est l'une des transformations que nous voyons un certain nombre d'entreprises traverser et quelque chose qu'elles valorisent finalement assez haut.

Nous avons eu une activité de simulation chez Wind River pendant de nombreuses années. Certains des premiers adoptants faisaient beaucoup de cela sur leurs serveurs, en augmentant de grands nombres de simulations. Mais quand vous le déplacez dans le cloud, vous n'avez pas à acheter de nouveaux serveurs tous les six mois.

Vous avez le contrôle sur le type de matériel que vous utilisez et sa quantité. Vous pouvez l'augmenter et le diminuer selon ce dont vous avez besoin à un moment donné, plutôt que d'avoir la dépense en capital de gros matériel et d'équipes IT pour le maintenir. Actuellement, nous voyons un équilibre ou un environnement cloud hybride, où une partie des tests est faite localement sur site, et une partie dans un cloud public.

RTInsights : Y a-t-il d'autres points que vous voulez aborder que nous avons omis ?

Morphew : Quand vous parlez de DevOps et de déplacer le développement logiciel embarqué vers un environnement plus cloud-native, cloud-centré, il y a plusieurs choses que j'ai vues personnellement en tant que gestionnaire de produit qui sont de grands changements.

L'un d'eux est la collaboration. J'essayais de compléter une construction Linux. Je ne suis pas un ingénieur Linux chevronné. J'avais des problèmes pour faire fonctionner une construction correctement. Et pendant que je faisais cela, l'un de nos architectes logiciels Linux a vu que j'avais eu plusieurs constructions échouées. Il m'a contacté via une application de messagerie instantanée et a dit : « Hé, j'ai vu que tu as des problèmes, j'ai regardé, et tu as juste besoin de changer le réglage, et ce sera bon. Et je viens de le corriger pour toi. »

Si je développais dans un environnement différent où j'avais un logiciel installé sur mon PC, personne ne saurait jamais que j'ai des problèmes. J'aurais dû aller demander. De plus, je n'aurais probablement pas pu recréer ce même scénario. Le plus probable, c'est que je serais resté bloqué toute la journée. Et j'aurais peut-être juste abandonné après un moment. Donc, la capacité d'avoir un accès rapide à un logiciel que vous n'avez pas à installer localement, et de pouvoir jouer dans un bac à sable commun, pour moi, a été une grande révélation sur la façon dont cela change votre façon de travailler, juste en ayant essentiellement ces actifs partagés au sein de votre équipe.

RTInsights : Quelque chose d'autre ?

Morphew : La chose vers laquelle nous regardons dans un avenir pas trop lointain est d'avoir des boucles de rétroaction numériques où vous récupérez des données de l'appareil, des données de votre environnement de développement, et vous les réinjectez pour améliorer votre logiciel. L'IA et l'apprentissage automatique entrent en jeu ici aussi. Quel genre d'informations puis-je obtenir de ces appareils ? Comment puis-je l'analyser potentiellement avec un modèle ou un moteur de type big data à grande échelle cloud, et ensuite réinjecter cela dans le développement logiciel futur ? Cela pourrait m'aider à optimiser un système dans son ensemble.