DevOps gebruiken om uitdagingen op het gebied van embedded software aan te pakken

Er is een perfecte storm op komst voor de ontwikkeling van embedded device-software. Ingebedde apparaten nemen in opkomst, vooral omdat nieuwe connectiviteitsopties, zoals 5G, innovatieve toepassingen voor verbonden apparaten mogelijk maken, en het gebruik ervan toeneemt, waarbij wordt geprofiteerd van nieuwe analyse- en kunstmatige intelligentiemogelijkheden. Tegelijkertijd maken de levenscyclusbehoeften van het apparaat, zoals het reageren op zich ontwikkelende cyberaanvallen, het noodzakelijk om snel softwarewijzigingen door te voeren en te implementeren.

Deze voorwaarden stellen nieuwe eisen aan de ontwikkelings- en operationele medewerkers. DevOps wordt steeds vaker beschouwd als de beste manier om te voldoen aan de vraag van de markt naar meer toepassingen en nieuwe functies, die allemaal in kortere tijden beschikbaar worden gesteld. RTInsights ging onlangs om tafel zitten met Graham Morphew, Senior Director of Product Management bij Wind River. We bespraken de uitdagingen van de ontwikkeling van embedded-device-software, de verschillen tussen DevOps voor traditionele omgevingen en embedded devices, en meer.

Hier is een samenvatting van ons gesprek.

RTInsights:hoe verschilt DevOps voor embedded devices van traditionele DevOps-benaderingen voor het ontwikkelen van software?

Morphew: Als je kijkt naar traditionele DevOps in een IT-bedrijfsomgeving, dan heb je een alomtegenwoordige uitvoeringsomgeving. Je draait ofwel op Intel-servers in de cloud, of je hebt iets draaiends op een Intel-pc. Ingebed is heel anders. Uw einduitvoeringsomgeving is meestal een andere architectuur dan degene die u gebruikt voor ontwikkeling. Er zijn meer uitdagingen vanwege de diversiteit van de eindhardware en hoe u deze inzet. Als je bijvoorbeeld software bouwt voor een cloudomgeving, weet je dat het in een Google Cloud-, Azure- of AWS-omgeving gaat. Wanneer u embedded software bouwt, is de keuze voor implementatieomgevingen bijna oneindig, en u kunt ook apparaten op externe locaties hebben.

Er zijn dus veel verschillen in hoe u over de software denkt en hoe deze verschillen zich vertalen in de implementatie-uitdagingen van DevOps.

U heeft te maken met gespecialiseerde hardware, cross-compiling, cross-debugging, geheugenvoetafdruk en beveiligingsproblemen. Je hebt niet de bijna onbeperkte bronnen binnen handbereik zoals je zou doen in een cloudomgeving. Er is een eiland van uitvoering waarmee u rekening moet houden bij het ontwerpen van deze systemen. Je hebt ook beveiliging om je zorgen over te maken. U hebt niet per se fysieke controle over de beveiliging van de apparaten. Mogelijk hebt u te maken met fysieke manipulatie van het apparaat.

Een andere uitdaging is dat de gegevens van deze apparaten moeilijker te verzamelen zijn. In een DevOps-omgeving wil je een continue feedbackloop. Dat is gemakkelijk als de ontwikkeling plaatsvindt op servers die onder uw controle staan. Als je het over apparaten hebt, worden ze waarschijnlijk op afstand gedistribueerd en zijn ze mogelijk niet altijd online. Er spelen dus veel verschillende problemen bij het vergelijken van uw traditionele DevOps en DevOps voor embedded software.

RTInsights:waarom zal de embedded device community richting DevOps gaan? Waarom wordt het dwingend en wat gebeurt er op de markten om dit te stimuleren?

Morphew: Met embedded software is er een groeiende behoefte aan frequentere updates en hogere kwaliteit. Om daar te komen, heb je automatisering nodig om je op weg te helpen. Automatisering zal een grote rol spelen in de toekomst van DevOps en embedded software. Als je een decennium of twee teruggaat, was er veel aandacht voor de hardware die de mogelijkheden van het apparaat aanstuurde. Nu is veel, veel meer van de onderscheidende technologie tussen apparaatverkopers software.

Een andere factor die bedrijven naar DevOps voor embedded systemen duwt, is iets dat we bij Wind River nogal eens zien:de veranderende demografie van softwareontwikkeling.

Er zijn twee zeer verschillende kampen. Je hebt je traditionele embedded software-ontwikkelaars en pas afgestudeerden of ontwikkelaars die vanuit andere softwaredomeinen het domein van intelligente apparaten betreden. De traditionele ontwikkelaars zijn meestal ouder en velen gaan met pensioen. Net als ik zijn er mensen die na hun studie op de markt kwamen in een tijd dat je naar hardwarehandleidingen, programmaregisters en dergelijke dingen keek. Dat is gewoon niet iets waar universiteitsopleidingen nu veel tijd aan besteden.

Ik heb een zoon die nu college-leeftijd heeft. Hij programmeert in Python. Hij leerde net C voor de eerste keer, en dat was een grote eye-opener. Python biedt veel hogere abstractieniveaus.

DevOps kan helpen om deze belemmering tussen de applicatieomgeving en de wens om die als een vertrouwde omgeving te laten lijken voor ontwikkelaars van apparaatsoftware te overwinnen. De noodzaak om dit te doen is dat bedrijven die apparaten bouwen, moeite hebben om nieuw softwareontwikkelingstalent te verwerven.

Ik sprak met iemand die we onlangs als stagiair hadden aangenomen, en hij vertelde ons dat veel van zijn klasgenoten naar Silicon Valley willen gaan en voor bedrijven als Facebook, Google, Apple en Tesla willen werken. Voor bedrijven in de industriële of lucht- en ruimtevaart- en defensiesegmenten kan het een grotere uitdaging zijn om het benodigde softwaretalent aan te trekken en embedded apparaten te programmeren in een rudimentaire C-omgeving.

Om dit te verhelpen, denken sommige bedrijven dat het helpt om die nieuwe generatie softwareontwikkelaars een omgeving te geven waarmee ze vertrouwd zijn. En dat is een van de redenen waarom Wind River een Visual Studio Code-omgeving adopteert. Visual Studio Code is een omgeving die sinds het op de markt is gekomen een snelle groei in populariteit heeft doorgemaakt. Iedereen met wie we hebben gesproken, vanuit een nieuw grad-perspectief, is zeer bekend met VS Code, en we zien minder ervaring van de nieuwe ontwikkelaar met oudere omgevingen zoals Eclipse. Dus soms moet je zijn waar je publiek al is.

RTinsights:welke problemen hebben bedrijven als ze DevOps-oplossingen proberen te adopteren? En wat zijn de belangrijkste uitdagingen voor het domein van embedded apparaten versus andere domeinen?

Morphew: De grootste uitdaging is de cultuuromslag die binnen bedrijven moet plaatsvinden. En dit is niet per se een embedded-specifieke uitdaging. Het is dieper geworteld in sommige softwareontwikkelingspraktijken.

Je hebt kleine teams en in veel gevallen heb je individuen die heel specifieke taken uitvoeren. Je hebt een niveau van samenwerking en samenwerking met DevOps nodig dat mensen soms uit het rijk haalt waar ze zich al een aantal jaren vertrouwd mee voelen. Je moet zeggen:"Iedereen werkt samen."

Het Ops-gedeelte van DevOps voor embedded is een uitdaging omdat, in een traditionele DevOps-omgeving voor de cloud, de Opsis vrij standaard is. U runt een website of ontwikkelt een applicatie die iets doet via een cloudgebaseerde interface. Als je het hebt over embedded, heb je het over een apparaat in het veld en wat dat apparaat doet, is specifiek voor jouw bedrijf. In veel gevallen zijn de apparaatfabrikanten niet de bedrijven die de apparaten bedienen. Een fabrikant van apparatuur kan zijn apparaat verkopen aan een groot elektriciteitsbedrijf of een grote fabrikant. Die bedrijven zijn degenen die de apparaten bedienen. Soms is er hulp van de fabrikant van het apparaat, maar het is geen volledig gesloten circuit zoals je zou kunnen zien bij een cloudgebaseerde oplossing.

Er zijn compatibiliteitsproblemen met toolset. Het hebben van een gemeenschappelijke ontwikkelomgeving stuit soms op weerstand. Dus dat komt terug op een deel van de culturele en managementondersteuning die je nodig hebt om deze systemen te implementeren.

En dan is er weer het hardwareprobleem. Het is een veelvoorkomend thema in de embedded markt. Hoe krijg je voldoende hardware om de automatiseringsomgevingen uit te bouwen die nodig zijn om DevOps realiteit te maken? Dat is een voortdurende uitdaging. Succesvolle klanten hebben doorgaans een mix van hardware en simulatie om hun testprocessen op te schalen.

RTInsights:zijn er tools die de overgang naar DevOps makkelijker maken?

Morphew: Een ding dat bedrijven helpt deze revolutie te doorstaan, is de beschikbaarheid van tools. Veel van deze tools zijn opensource of hebben gratis versies. Wat je vaak zou zien, was een consolidatie rond een of andere vorm van Broncodebeheer, vaak een smaak van Git. Nu zijn organisaties overgegaan van een zeer op broncodebeheer gerichte oplossing naar het opnemen van steeds meer DevOps-tools in hun oplossingen. Dat helpt bedrijven bij het maken van de overstap.

Er is veel keuze. Je zou kunnen beweren dat er soms te veel keuze is. De uitdaging die we klanten nu zien, is, ja, er zijn veel tools. Hoe breng ik ze samen in een oplossing die voor mij werkt?

Tegenwoordig starten veel bedrijven projecten waarbij ze intern teams vormen om hun overgang naar een meer digitaal gerichte ontwikkelomgeving te beheren. We zien nu een transitie plaatsvinden in de ingebedde ruimte, zoals we zagen bij andere technologische transities. In veel gevallen is het een doe-het-zelf-mentaliteit van:"Laten we het perfecte systeem voor ons bouwen, laten we het aanpassen aan onze behoeften." Dergelijke inspanningen onttrekken steeds meer middelen aan het bedrijf om deze zaken in de toekomst in stand te houden. Dat is niet per se waar ze willen investeren. Die aanpak zal zich waarschijnlijk ontwikkelen tot een aanpak waarbij mensen op zoek zijn naar een ander bedrijf dat in de loop van de tijd meer van hun omgeving onderhoudt.

Een ander gebied waar bedrijven uiteindelijk hun leven gemakkelijker kunnen maken, is een duidelijke scheiding tussen applicatieontwikkeling en het onderhouden van de softwareplatforms waarop ze draaien. Vroeger had je een klein team dat beide dingen deed, en de applicatie en het platform gingen in elkaar over. Maar nu heb je die duidelijke scheiding nodig om je software te modulariseren en mensen te laten werken aan datgene waarvoor ze de beste vaardigheden hebben.

RTinsights:wat zijn de drijfveren in de branche voor oplossingen die het gemakkelijker maken om software voor embedded apparaten te ontwikkelen en te testen?

Morphew :Er is de convergentie van de IT- en OT-werelden. Je hebt apparaten verbonden met internet. Dit is een grote drijfveer geweest voor bedrijven om opnieuw te onderzoeken hoe ze software leveren. Er zijn ook verschillende industrieën waar u compliance-gerelateerde vereisten hebt om de software in apparaten bij te werken. Dat zie je in de medische wereld, waar je nu moet bewijzen dat je je apparaat kunt updaten als er een beveiligingslek bekend wordt. Dit kan een scenario op leven of dood zijn. Je moet kunnen bewijzen dat je een dergelijk probleem kunt aanpakken als er een opduikt.

Dergelijke stuurprogramma's dwingen bedrijven om te kijken naar de processen die ze gebruiken met betrekking tot hun vermogen om updates op afstand uit te voeren. Wat we zien is dat veel grotere bedrijven de dreiging voelen van deze digitale, nieuwe en opkomende bedrijven. Er zijn zelfs termen die ze gebruiken om het te beschrijven. Je hoort de term Teslaficatie. Ze zeggen dat ze meer op Tesla moeten lijken en een heel, heel softwaregericht bedrijf moeten zijn, in tegenstelling tot het baksteen- en mortel-, staal- en ijzertype denken dat meer wordt geassocieerd met hardware. Meer en meer moeten ze hun product differentiëren op de software die draait op de dingen die ze aan het bouwen zijn.

De pandemie heeft deze trend ook versneld. De meeste op software gerichte werknemers werken vanuit huis. En in veel gevallen zal een aanzienlijk aantal werknemers niet meer naar kantoor terugkeren nadat dit voorbij is. Dat is een grote verschuiving. Je moet dus de manier waarop je denkt over werken veranderen om die situatie productief te maken voor ontwikkelaars. Dat is een uitdaging. Het schreeuwt tot op zekere hoogte om meer samenwerkingstools en meer standaardisatie in termen van hoe dingen worden gedaan, omdat er niet veel mensen zijn die face-to-face werken en op de meer traditionele manier samenwerken.

RTInsights:we gaan verder met een ander probleem:waarom zijn snelle software-iteraties in elke branche een cruciaal, concurrentievoordeel geworden? En hoe verhoudt zich dat tot die behoefte aan geautomatiseerd testen?

Morphew: Ik heb verschillende projecten doorlopen die zijn overgegaan van een watervalmodel naar een meer agile model. Dat vermogen om continu te testen, geautomatiseerd testen is vaak de beperkende factor in termen van het verhogen van uw productiviteit. Als je snel wilt rennen en toch je kwaliteit wilt behouden, is dat een noodzaak. Dit is een specifiek gebied waar je met een digitale tweeling van je eindapparaat veel van het testen kunt doen, en je kunt het op schaal doen.

Een van de grote ontwikkelingen die we zien in termen van DevOps die van toepassing is op embedded, is de mogelijkheid om een ​​simulatie van het embedded apparaat te maken en het vervolgens op grote schaal te gebruiken in een cloudgebaseerde omgeving. Op die manier kun je honderd tests tegelijk laten lopen. U wordt alleen beperkt door cloudbronnen. Dat is een van de transformaties die we een aantal bedrijven zien doormaken en iets dat ze uiteindelijk vrij hoog waarderen.

We hebben al vele jaren een simulatiebedrijf bij WindRiver. Sommige van de early adopters deden dit veel op hun servers, waardoor grote aantallen simulaties werden opgeschaald. Maar als u het naar de cloud verplaatst, hoeft u niet elke zes maanden nieuwe servers te kopen.

Je hebt controle over het type hardware dat je gebruikt en de hoeveelheid ervan. Je kunt het op en neer bellen, afhankelijk van wat je op een bepaald moment nodig hebt, in plaats van de kapitaalkosten van grote hardware- en IT-teams te hebben om het te onderhouden. Op dit moment zien we een balans of een soort hybride cloudomgeving, waarbij een deel van de tests lokaal op locatie wordt gedaan en een deel in een openbare cloud.

RTinsights:zijn er nog andere punten die je wilt noemen die we hebben weggelaten?

Morphew: Als je het hebt over DevOps en het verplaatsen van embedded software-ontwikkeling naar een meer cloud-native, cloud-gerichte omgeving, zijn er verschillende dingen die ik persoonlijk als productmanager heb gezien die grote veranderingen zijn.

Een daarvan is samenwerking. Ik was aan het proberen om een ​​Linux-build te voltooien. Ik ben geen beproefde Linux-ingenieur. Ik had wat problemen om een ​​build correct te laten werken. En terwijl ik dit aan het doen was, kon een van onze Linux-softwarearchitecten zien dat ik verschillende mislukte builds had gehad. En hij nam contact met me op via een instant messaging-app en zei:"Hé, ik heb gezien dat je wat problemen hebt, ik heb even gekeken en je hoeft alleen maar de instelling te veranderen, en je komt goed. En ik ging gewoon door en repareerde het voor je.”

Als ik aan het ontwikkelen was in een andere omgeving waar ik software op mijn pc had geïnstalleerd, zou niemand ooit weten dat ik problemen had. Ik zou naar buiten moeten gaan om het te vragen. Ook zou ik hoogstwaarschijnlijk niet hetzelfde scenario kunnen recreëren. Hoogstwaarschijnlijk zou ik er de hele dag aan vast hebben gezeten. En misschien heb ik het na een tijdje gewoon opgegeven. Dus de mogelijkheid om snel toegang te krijgen tot software die je niet lokaal hoeft te installeren, en het kunnen spelen in een gemeenschappelijke sandbox, was voor mij een grote eye-opener over hoe deze verandering je laat zien, gewoon door in wezen dit soort van gedeelde middelen binnen uw team.

RTInsights:nog iets anders?

Morphew: Het enige waar we naar uitkijken in de niet al te verre toekomst, is om digitale feedbackloops te hebben waarbij je gegevens van het apparaat haalt, gegevens uit je ontwikkelomgeving haalt en die terugvoert om je software te verbeteren. AI en machine learning spelen hier ook een rol in. Wat voor informatie kan ik van deze apparaten krijgen? Hoe kan ik het potentieel analyseren met een groot cloud-schaal, big data-type van een model of engine, en dat vervolgens terugkoppelen naar toekomstige softwareontwikkeling? Dat zou me kunnen helpen om een ​​systeem als geheel te optimaliseren.