Utiliser DevOps pour relever les défis des logiciels embarqués

DevOps est considéré comme le meilleur moyen de répondre aux demandes du marché des logiciels embarqués pour plus d'applications et de nouvelles fonctionnalités, toutes disponibles dans des délais plus courts.

Une tempête parfaite se prépare pour le développement de logiciels pour appareils embarqués. Les appareils embarqués prolifèrent, en particulier à mesure que de nouvelles options de connectivité, telles que la 5G, rendent possibles des applications innovantes pour les appareils connectés, et leur utilisation se développe, tirant parti des nouvelles capacités d'analyse et d'intelligence artificielle. Dans le même temps, les besoins du cycle de vie des appareils, tels que la réponse à l'évolution des cyberattaques, rendent nécessaire la création et le déploiement rapides de modifications logicielles.

Ces conditions imposent de nouvelles exigences au personnel de développement et d'exploitation. De plus en plus, DevOps est considéré comme le meilleur moyen de répondre aux demandes du marché pour plus d'applications et de nouvelles fonctionnalités, toutes rendues disponibles dans des délais plus courts. RTInsights a récemment rencontré Graham Morphew, directeur principal de la gestion des produits chez Wind River. Nous avons discuté des défis du développement de logiciels pour appareils embarqués, des différences entre DevOps pour les environnements traditionnels et les appareils embarqués, et plus encore.

Voici un résumé de notre conversation.

RTInsights :En quoi DevOps pour les appareils embarqués est-il différent des approches DevOps traditionnelles pour le développement de logiciels ?

Morphew : Lorsque vous regardez DevOps traditionnel dans un environnement d'entreprise informatique, vous avez un environnement d'exécution omniprésent. Soit vous exécutez sur des serveurs Intel dans le cloud, soit vous avez quelque chose qui s'exécute sur un PC Intel. Embedded est très différent. Votre environnement d'exécution final est généralement une architecture différente de celle que vous utilisez 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 les déployez. Par exemple, lorsque vous créez un logiciel pour un environnement basé sur le cloud, vous savez que cela se passe dans un environnement Google Cloud, Azure ou AWS. Lorsque vous créez des logiciels embarqués, la diversité des choix d'environnement de déploiement est presque infinie, et vous pouvez également avoir des appareils dans des emplacements distants.

Il existe donc de nombreuses différences en termes de conception du logiciel et de la manière dont ces différences se traduisent en défis de mise en œuvre DevOps.

Vous devez faire face à du matériel spécialisé, à la compilation croisée, au débogage croisé, aux empreintes mémoire et aux problèmes de sécurité. Vous n'avez pas les ressources presque illimitées à portée de main comme vous le feriez dans un environnement cloud. Il y a un îlot d'exécution que vous devez garder à l'esprit lorsque vous concevez ces systèmes. Vous devez également vous soucier de la sécurité. Vous n'avez pas nécessairement le contrôle physique de la sécurité des appareils. Vous devrez peut-être faire face à une altération physique de l'appareil.

Un autre défi est que les données de ces appareils sont plus difficiles à collecter. Dans un environnement DevOps, vous souhaitez une boucle de rétroaction continue. C'est facile si le développement se fait sur des serveurs sous votre contrôle. Lorsque vous parlez d'appareils, ils seront probablement distribués à distance et ils ne seront peut-être pas en ligne tout le temps. Ainsi, de nombreux problèmes différents entrent en jeu lorsque vous comparez votre DevOps traditionnel et DevOps pour les logiciels embarqués.

RTInsights :pourquoi la communauté des appareils embarqués va-t-elle évoluer vers DevOps ? Pourquoi cela devient-il convaincant et que se passe-t-il sur les marchés pour y parvenir ?

Morphew : Avec les logiciels embarqués, il existe un besoin croissant de mises à jour plus fréquentes et de meilleure qualité. Pour y arriver, vous avez besoin d'automatisation pour vous aider tout au long du chemin. L'automatisation jouera un grand rôle dans l'avenir des logiciels embarqués DevOps et. Si vous revenez une décennie ou deux en arrière, on s'est beaucoup concentré sur le matériel qui pilote les capacités de l'appareil. Aujourd'hui, une grande partie de la technologie qui différencie les fournisseurs d'appareils est le logiciel.

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

Il y a deux camps bien distincts. Vous avez vos développeurs de logiciels embarqués traditionnels et de nouveaux diplômés ou développeurs entrant dans le domaine des appareils intelligents à partir d'autres domaines logiciels. Les développeurs traditionnels ont tendance à être plus âgés et beaucoup prennent leur retraite. Comme moi, il y a des gens qui sont arrivés sur le marché à la sortie de l'université à une époque où vous consultiez des manuels de matériel, des registres de programmes, etc. Ce n'est tout simplement pas quelque chose sur lequel les programmes universitaires passent beaucoup de temps maintenant.

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

DevOps peut aider à surmonter cet obstacle entre l'environnement de l'application et la volonté de faire en sorte que cet environnement ressemble à un environnement familier pour les développeurs de logiciels d'appareils. La nécessité de le faire est que les entreprises qui construisent des appareils ont du mal à acquérir de nouveaux talents en développement de logiciels.

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

Pour surmonter cela, certaines entreprises pensent que donner à cette nouvelle génération de développeurs de logiciels un environnement avec lequel ils sont familiers aidera. Et c'est l'une des raisons pour lesquelles Wind River adopte un environnement Visual Studio Code. Visual Studio Code est un environnement qui a connu une croissance rapide en popularité depuis son arrivée sur le marché. Tous ceux à qui nous avons parlé, venant d'un nouveau point de vue de diplômé, connaissent très bien VS Code, et nous voyons moins d'expérience du nouveau développeur avec des environnements plus anciens comme Eclipse. Donc, parfois, vous devez être là où se trouve déjà votre public.

RTInsights :Quels problèmes les entreprises rencontrent-elles lorsqu'elles essaient d'adopter des solutions DevOps ? Et quels sont les principaux défis 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 de logiciels.

Vous avez de petites équipes et, dans de nombreux cas, vous avez des individus qui effectuent des tâches très spécifiques. Vous avez besoin d'un niveau de collaboration et de coopération avec DevOps qui éloigne parfois les gens du domaine avec lequel ils se sont familiarisés depuis un certain nombre d'années. Vous devez dire :"Tout le monde travaille ensemble".

La partie Ops de DevOps pour l'embarqué est un défi car, dans un environnement DevOps traditionnel pour le cloud, l'Opsis est assez standard. Vous exploitez un site Web ou développez une application qui fait quelque chose via une interface basée sur le cloud. Lorsque vous parlez d'embarqué, vous parlez d'un appareil sur le terrain, et ce que fait cet appareil est spécifique à votre entreprise. Dans de nombreux cas, les fabricants d'appareils ne sont pas les sociétés qui exploitent les appareils. Un fabricant d'équipement peut vendre son appareil à une grande entreprise d'électricité ou à un grand fabricant. Ces entreprises sont celles qui exploitent les appareils. Parfois, le fabricant de l'appareil bénéficie de l'assistance, mais il ne s'agit pas d'une boucle complètement fermée comme vous pourriez le voir avec une solution basée sur le cloud.

Il existe des problèmes de compatibilité des outils. Le fait d'avoir un environnement de développement commun rencontre parfois des résistances. Cela revient donc à une partie du soutien culturel et de gestion dont vous avez besoin pour mettre en œuvre ces systèmes.

Et puis il y a encore le problème du matériel. C'est un thème commun sur le marché de l'embarqué. Comment obtenir suffisamment de matériel pour créer les environnements d'automatisation nécessaires pour faire de DevOps une réalité ? C'est un défi permanent. En règle générale, les clients qui réussissent disposent d'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 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 vous verriez souvent était une consolidation autour d'une certaine saveur de gestion de code source, souvent une saveur de Git. Aujourd'hui, les organisations sont passées d'une solution très centrée sur la gestion du code source à l'inclusion de plus en plus de types d'outils DevOps dans leurs solutions. Cela aide les entreprises à faire la transition.

Il y a beaucoup de choix. Vous pourriez dire que parfois il y a trop de choix. Le défi que nous voyons les clients avoir maintenant est, oui, il existe de nombreux outils. Comment puis-je les rassembler dans une solution qui fonctionne pour moi ?

Aujourd'hui, de nombreuses entreprises démarrent des projets où elles forment des équipes en interne 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é comme ce que nous avons vu avec d'autres transitions technologiques. Dans de nombreux cas, c'est vraiment une mentalité de bricolage du type "Construisons le système parfait pour nous, adaptons-le à nos besoins". De tels efforts drainent de plus en plus de ressources de l'entreprise juste pour maintenir ces choses à l'avenir. Ce n'est pas nécessairement là qu'ils veulent investir. Cette approche évoluera probablement vers une approche où les gens chercheront à ce qu'une autre entreprise entretienne une plus grande partie de leur environnement au fil du temps.

Un autre domaine dans lequel, en fin de compte, les entreprises peuvent se simplifier la vie consiste à établir des séparations claires entre le développement d'applications et la maintenance des plates-formes logicielles sur lesquelles elles s'exécutent. Auparavant, vous aviez une petite équipe qui faisait les deux choses, et l'application et la plateforme fusionnaient l'une avec l'autre. Mais maintenant, vous avez besoin de cette séparation claire pour modulariser votre logiciel et faire en sorte que les gens travaillent sur ce pour quoi ils ont les meilleures compétences.

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

Morphew :Il y a la convergence des mondes IT et OT. Vous avez des appareils connectés à Internet. Cela a été un grand moteur pour que les entreprises réexaminent leur façon de fournir des logiciels. En outre, il existe plusieurs secteurs où vous avez des exigences liées à la conformité pour mettre à jour le logiciel des 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 connue. Cela peut être un scénario de vie ou de mort. Vous devez être en mesure de prouver que vous pouvez résoudre un tel problème si celui-ci se présente.

Ces pilotes poussent les entreprises à examiner les processus qu'elles utilisent en ce qui concerne leur capacité à effectuer des mises à jour à distance. Ce que nous voyons, c'est que beaucoup de grandes entreprises ressentent la menace de ces entreprises nouvelles et émergentes natives du numérique. Il y a même des termes qu'ils utilisent pour le décrire. Vous entendez le terme teslification. Ils disent qu'ils doivent ressembler davantage à Tesla et être une entreprise très, très axée sur les logiciels, par opposition au type de pensée brique et mortier, acier et fer qui est davantage associé au matériel. De plus en plus, ils doivent différencier leur produit sur le logiciel qui s'exécute 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 les logiciels qui travaille à domicile. Et dans de nombreux cas, un nombre important d'employés ne retourneront pas au bureau une fois que cela sera terminé. C'est un grand changement. Vous devez donc changer votre façon de travailler pour rendre cette situation productive pour les développeurs. C'est un défi. Il réclame, dans une certaine mesure, plus d'outils de collaboration et plus de standardisation en termes de manière de faire les choses, car vous n'avez pas beaucoup de personnes travaillant en face à face et collaborant de manière plus traditionnelle.

RTInsights :Passons à un autre problème :pourquoi les itérations logicielles rapides sont-elles devenues un avantage concurrentiel essentiel dans tous les secteurs ? Et comment cela est-il lié à ce 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é à effectuer 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é. Il s'agit d'un domaine particulier où le fait d'avoir un jumeau numérique de votre appareil final vous permet d'effectuer une grande partie des tests, et vous pouvez le faire à grande échelle.

L'un des grands progrès que nous voyons en termes d'application de DevOps à l'embarqué est la possibilité de faire une simulation de l'appareil embarqué, puis de l'utiliser à grande échelle dans un environnement basé sur le cloud. De cette façon, vous pouvez exécuter une centaine de tests simultanément. Vous n'êtes limité que par les ressources cloud. C'est l'une des transformations que traversent un certain nombre d'entreprises et quelque chose qu'elles apprécient finalement beaucoup.

Nous avons une entreprise de simulation à WindRiver depuis de nombreuses années. Certains des premiers utilisateurs faisaient beaucoup de cela sur leurs serveurs, augmentant un grand nombre de simulations. Mais lorsque vous le transférez vers le cloud, vous n'avez pas besoin d'acheter de nouveaux serveurs tous les six mois.

Vous contrôlez le type de matériel que vous utilisez et sa quantité. Vous pouvez l'augmenter et le réduire en fonction de ce dont vous avez besoin à tout moment, plutôt que d'avoir les dépenses en capital de grandes équipes matérielles et informatiques pour le maintenir. À l'heure actuelle, nous voyons un équilibre ou une sorte d'environnement de cloud hybride, où une partie des tests est effectuée localement sur site, et une partie dans un cloud public.

RTInsights :Y a-t-il d'autres points que vous souhaitez aborder et que nous n'avons pas pris en compte ?

Morphew : Lorsque vous parlez de DevOps et de déplacement du développement de logiciels embarqués vers un environnement plus natif et axé sur le cloud, il y a plusieurs choses que j'ai vues personnellement en tant que chef de produit qui sont de grands changements.

L'un d'eux est la collaboration. J'essayais de terminer une version Linux. Je ne suis pas un ingénieur Linux éprouvé. J'avais quelques problèmes pour faire fonctionner correctement un build. Et pendant que je faisais cela, l'un de nos architectes logiciels Linux a pu voir que j'avais eu plusieurs échecs de construction. Et il m'a contacté via une application de messagerie instantanée et m'a dit :"Hé, j'ai vu que vous aviez des problèmes, j'ai jeté un coup d'œil, et vous n'avez qu'à changer de réglage, et tout ira bien. Et je suis allé de l'avant et je l'ai réparé pour vous. »

Si je développais dans un environnement différent où j'avais un logiciel installé sur mon PC, personne ne saurait jamais que j'avais des problèmes. Je devrais sortir et demander. De plus, je ne serais probablement pas capable de recréer le même scénario. Très probablement, j'aurais été coincé dessus toute la journée. Et, j'ai peut-être abandonné au bout d'un moment. Ainsi, la possibilité d'accéder rapidement à des logiciels 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 ce changement montre que vous travaillez, simplement en ayant essentiellement ces types d'actifs partagés au sein de votre équipe.

RTInsights :autre chose ?

Morphew : La seule chose que nous attendons avec impatience dans un avenir pas trop lointain est d'avoir des boucles de rétroaction numériques où vous retirez des données de l'appareil, retirez des données de votre environnement de développement et réinjectez-les pour améliorer votre logiciel. L'IA et l'apprentissage automatique jouent également un rôle. Quel type d'informations puis-je obtenir de ces appareils ? Comment puis-je l'analyser potentiellement avec un type de modèle ou de moteur de données volumineuses à l'échelle du cloud, puis réintégrer cela dans le développement de logiciels futurs ? Cela pourrait m'aider à optimiser un système dans son ensemble.