DevOps Inzetten om Uitdagingen in Embedded Software te Overwinnen

DevOps wordt beschouwd als de beste manier om aan de marktvraag te voldoen voor meer applicaties en nieuwe functies, allemaal beschikbaar in kortere tijd.

Een perfecte storm ontwaakt voor embedded software-ontwikkeling. Embedded apparaten nemen toe, met name doordat nieuwe connectiviteitsopties zoals 5G innovatieve toepassingen voor verbonden apparaten mogelijk maken, en hun gebruik breidt zich uit door nieuwe analytics- en AI-mogelijkheden. Tegelijkertijd maken levenscyclusbehoeften van apparaten, zoals het reageren op evolutie van cyberaanvallen, het noodzakelijk om softwarewijzigingen snel te maken en te deployen.

Deze omstandigheden leggen nieuwe eisen aan ontwikkel- en operationele teams. Steeds vaker wordt DevOps gezien als de beste manier om aan de marktvraag te voldoen voor meer applicaties en nieuwe functies, allemaal beschikbaar in kortere tijd. RTInsights sprak recentelijk met Graham Morphew, Senior Director of Product Management bij Wind River. We bespraken de uitdagingen van embedded software-ontwikkeling, de verschillen tussen DevOps voor traditionele omgevingen en embedded apparaten, en meer.

Hier is een samenvatting van ons gesprek.

RTInsights: Hoe verschilt DevOps voor embedded apparaten van traditionele DevOps-benaderingen?

Morphew: Als je kijkt naar traditionele DevOps in een IT-enterprise-omgeving, heb je een alomtegenwoordige uitvoeringsomgeving. Je draait ofwel op Intel-servers in de cloud, of je hebt iets draaien op een Intel-pc. Embedded is heel anders. Je einduitvoeringsomgeving is meestal een andere architectuur dan die je voor ontwikkeling gebruikt. Er zijn meer uitdagingen door de diversiteit van de eindhardware en hoe je daar naar deployt. Bijvoorbeeld, als je software bouwt voor een cloud-omgeving, weet je dat het in Google Cloud, Azure of AWS terechtkomt. Bij embedded software is de keuze voor deploymentsomgevingen bijna oneindig, en je kunt ook apparaten op afgelegen locaties hebben.

Er zijn dus veel verschillen in hoe je over de software nadenkt en hoe die verschillen vertalen naar implementatie-uitdagingen.

Je moet rekening houden met gespecialiseerde hardware, cross-compileren, cross-debuggen, geheugenvoetafdrukken en beveiligingskwesties. Je hebt niet de bijna onbeperkte middelen ter beschikking zoals in een cloudomgeving. Er is een 'eiland van uitvoering' waar je rekening mee moet houden bij het ontwerpen van deze systemen. Je hebt ook beveiliging te berücksichtigen. Je hebt niet noodzakelijk fysieke controle over de beveiliging van de apparaten. Je moet rekening kunnen houden met fysieke manipulatie van het apparaat.

Een andere uitdaging is dat data van deze apparaten moeilijker te verzamelen is. In een DevOps-omgeving wil je een continue feedbacklus. Dat is makkelijk als ontwikkeling op servers gebeurt die onder jouw controle staan. Bij apparaten zijn die waarschijnlijk op afstand gedistribueerd en niet altijd online. Dus veel verschillende kwesties spelen een rol bij de vergelijking van traditionele DevOps en DevOps voor embedded software.

RTInsights: Waarom zal de embedded-gemeenschap naar DevOps toe bewegen? Waarom wordt het aantrekkelijk, en wat drijft dit in de markt?

Morphew: Bij embedded software is er een groeiende behoefte aan vaker updates en hogere kwaliteit. Om daar te komen, heb je automatisering nodig die je op weg helpt. Automatisering zal een grote rol spelen in de toekomst van DevOps en embedded software. Als je tien of twintig jaar teruggaat, lag de focus op hardware die de capaciteiten van het apparaat aanstuurde. Nu is veel, veel meer van de differentierende technologie bij apparatenleveranciers software.

Een andere factor die bedrijven naar DevOps voor embedded systemen duwt, is iets wat we bij Wind River veel zien: de veranderende demografie van software-ontwikkeling.

Er zijn twee heel duidelijke kampen. Je hebt je traditionele embedded software-ontwikkelaars en nieuwe afgestudeerden of ontwikkelaars die vanuit andere software-domeinen de domein van intelligente apparaten betreden. De traditionele ontwikkelaars zijn ouder, en velen gaan met pensioen. Als ik, zijn er mensen die na college op de markt kwamen op een moment dat je hardwarehandleidingen bestudeerde, registers programmeerde, en dergelijke. Dat is niet iets waar college-opleidingen nu veel tijd aan besteden.

Ik heb een zoon die nu student is. Hij programmeert in Python. Hij leerde pas recent C, en dat was een groot openbarende ervaring. Python biedt veel hogere abstractieniveaus.

DevOps kan helpen deze obstructie tussen de applicatieomgeving en de wens om die eruit te laten zien als een vertrouwde omgeving voor ontwikkelaars van device-software te overwinnen. De noodzaak hiervoor is dat bedrijven die apparaten bouwen, moeite hebben om nieuwe software-ontwikkelaarstalent te werven.

Ik sprak recent met iemand die we als stage lieten lopen, en hij vertelde dat veel van zijn klasgenoten naar Silicon Valley willen gaan en werken voor bedrijven als Facebook, Google, Apple en Tesla. Voor bedrijven in de industriële of luchtvaart- en defensesectoren kan het meer uitdaging zijn om het benodigde softwaretalent te trekken dat zou komen programmeren in een rudimentaire C-omgeving.

Om dit te overwinnen, denken sommige bedrijven dat het geven van die nieuwe generatie software-ontwikkelaars een omgeving waar ze bekend mee zijn, zal helpen. En dat is een van de redenen waarom Wind River een Visual Studio Code-omgeving adopteert. Visual Studio Code is een omgeving die een snelle groei in populariteit heeft gezien sinds de marktinvoering. Iedereen met wie we spraken, vanuit het perspectief van een recente afgestudeerde, is erg bekend met VS Code, en we zien minder ervaring bij nieuwe ontwikkelaars met oudere omgevingen als Eclipse. Soms moet je daar zijn waar je publiek al is.

RTInsights: Welke problemen hebben bedrijven wanneer ze DevOps-oplossingen proberen te adopteren? En wat zijn de sleuteluitdagingen voor het embedded-domein versus andere domeinen?

Morphew: De grootste uitdaging is de cultuurverandering die binnen bedrijven moet plaatsvinden. En dit is niet noodzakelijk een embedded-specifieke uitdaging. Het zit dieper ingeworteld in sommige software-ontwikkelpraktijken.

Je hebt kleine teams, en in veel gevallen heb je individuen die heel specifieke taken doen. Je hebt een niveau van samenwerking en samenwerking met DevOps nodig dat mensen soms uit hun comfortzone haalt waar ze al jaren in zitten. Je moet zeggen: "Iedereen werkt samen."

Het Ops-deel van DevOps voor embedded is een uitdaging omdat, in een traditionele DevOps-omgeving voor de cloud, Ops pretty standaard is. Je runt een website of ontwikkelt een applicatie die iets doet via een cloud-interface. Als je over embedded praat, praat je 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 exploiteren. Een apparatenfabrikant kan zijn apparaat verkopen aan een groot elektriciteitsbedrijf of een grote fabrikant. Die bedrijven zijn degene die de apparaten exploiteren. Soms is er assistentie van de apparaatfabrikant, maar het is geen volledig gesloten lus zoals je bij een cloud-oplossing zou zien.

Er zijn toolset-compatibiliteitskwesties. Een gemeenschappelijke ontwikkelomgeving loopt soms tegen weerstand aan. Dus dat komt terug op een aantal culturele en management-ondersteuning die je nodig hebt om deze systemen te implementeren.

En dan is er nog het hardware-issue. Het is een terugkerend thema in de embedded-markt. Hoe krijg je genoeg hardware om de automatiseringsomgevingen op te bouwen die nodig zijn om DevOps werkelijkheid te maken? Dat is een lopende uitdaging. Typisch succesvolle klanten hebben een mix van hardware en simulatie om hun testprocessen op te schalen.

RTInsights: Zijn er tools die de overstap naar DevOps makkelijker maken?

Morphew: Één ding dat bedrijven helpt door deze revolutie heen is de beschikbaarheid van tools. Veel van deze tools zijn open source of hebben gratis versies. Wat je vaak zagen was een consolidatie rond een of andere vorm van Source Code Management, vaak een vorm van Git. Nu zijn organisaties gegaan van een heel SCM-centrische oplossing naar het includeren van steeds meer DevOps-tools in hun oplossingen. Dat helpt bedrijven bij de overstap.

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

Vandaag de dag starten veel bedrijven projecten waar ze intern teams vormen om hun overstap naar een meer digitaal-gefocuste ontwikkelomgeving te managen. We zien een overgang in de embedded-ruimte die lijkt op wat we zagen met andere technologische overgangen. In veel gevallen is het erg een doe-het-zelf-mentaliteit van: "Laten we het perfecte systeem voor ons bouwen, laten we het aanpassen aan onze behoeften." Dergelijke inspanningen putten steeds meer middelen uit het bedrijf om deze dingen gaande te houden. Dat is niet per se waar ze in willen investeren. Die benadering zal waarschijnlijk evolueren naar een waar mensen zoeken naar een ander bedrijf dat meer van hun omgeving over tijd beheert.

Een ander gebied waar bedrijven uiteindelijk hun leven makkelijker kunnen maken, is duidelijke scheiding tussen applicatieontwikkeling en het onderhouden van de softwareplatformen waarop ze draaien. Het was vroeger dat je een klein team had dat beide dingen deed, en de applicatie en platform in elkaar overgingen. Maar nu heb je die duidelijke scheiding nodig om je software te modulariseren en mensen te laten werken aan wat ze het beste kunnen.

RTInsights: Wat zijn de industriële drijfveren voor oplossingen die het makkelijker 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 die met het internet verbonden zijn. Dit is een grote drijfveer voor bedrijven om na te gaan hoe ze software leveren. Er zijn ook verschillende industrieën waar je compliance-gerelateerde eisen hebt om de software in apparaten te updaten. Je ziet dat in het medische veld, waar je nu moet bewijzen dat je je apparaat kunt updaten als een beveiligingskwetsbaarheid bekend wordt. Dit kan een kwestie van leven of dood zijn. Je moet kunnen bewijzen dat je zo'n probleem kunt aanpakken als het opduikt.

Zulke drijfveren duwen bedrijven om te kijken naar de processen die ze gebruiken wat betreft hun vermogen om remote updates te doen. Wat we zien is dat veel grotere bedrijven de dreigting voelen van deze digitaal-ingeboren nieuwe en opkomende bedrijven. Er zijn zelfs termen die ze gebruiken om het te beschrijven. Je hoort de term 'Teslafication'. Ze zeggen dat ze meer als Tesla moeten zijn en een heel, heel software-gefocust bedrijf, tegenover baksteen en mortar, staal en ijzer denkbeelden die meer geassocieerd worden met hardware. Steeds meer moeten ze hun product differentieren op de software die op de dingen draait die ze bouwen.

De pandemie heeft deze trend ook versneld. Je hebt het meeste software-gefocuste personeel thuiswerkend. En in veel gevallen zal een significante hoeveelheid werknemers na afloop niet naar het kantoor terugkeren. Dat is een grote shift. Dus je moet de manier veranderen waarop je over werk nadenkt om die situatie productief te maken voor ontwikkelaars. Dat is een uitdaging. Het roept om, in een zekere mate, meer samenwerkingshulpmiddelen en meer standaardisatie in hoe dingen gedaan worden, omdat je niet veel mensen hebt die face-to-face werken en samenwerken op de meer traditionele manier.

RTInsights: Laten we doorgaan naar een ander onderwerp, waarom zijn snelle software-iteraties een kritisch, competitief voordeel in elke industrie geworden? En hoe hangt dat samen met die behoefte aan geautomatiseerde testing?

Morphew: Ik heb verschillende projecten doorlopen die overgingen van een waterfall-model naar een meer agile model. Dat vermogen om continue testing te doen, geautomatiseerde testing, is vaak de beperkende factor in het verhogen van je productiviteit. Als je hard gaat rennen en je wilt nog steeds je kwaliteit behouden, is het een noodzaak. Dit is een specifiek gebied waar het hebben van een digitale tweeling van je eindapparaat je in staat stelt om veel van de testing erop te doen, en dat op schaal.

Een van de grote komsten die we zien wat betreft DevOps toepasbaar op embedded is het vermogen om een simulatie van het embedded apparaat te nemen en die dan op schaal in een cloud-omgeving te gebruiken. Op die manier kun je honderd tests simultaan draaien. Je wordt alleen beperkt door cloud-middelen. Dat is een van de transformaties die we een aantal bedrijven zien doorgaan en iets wat ze uiteindelijk heel hoog waarderen.

We hebben al jaren een simulatiebusiness bij Wind River. Sommige van de vroege adopters deden veel van dit op hun eigen servers, met opschaling van grote aantallen simulaties. Maar als je het naar de cloud verplaatst, hoef je niet elke zes maanden nieuwe servers te kopen.

Je hebt controle over het type hardware dat je gebruikt en de hoeveelheid. Je kunt het opdraaien en afdraaien afhankelijk van wat je op een gegeven moment nodig hebt, in plaats van de kapitaalkosten van grote hardware en IT-teams om het te onderhouden. Op dit moment zien we een balans of een soort hybride cloud-omgeving, waar een deel van de testing lokaal on-premises gedaan wordt, en een deel in een publieke cloud.

RTInsights: Zijn er nog andere punten die je wilt aanhalen die we over het hoofd hebben gezien?

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

Eén daarvan is samenwerking. Ik probeerde een Linux-build te voltooien. Ik ben geen doorgewinterde Linux-engineer. Ik had wat problemen om een build werkend te krijgen. En terwijl ik dit deed, kon een van onze Linux-software-architecten zien dat ik verschillende mislukte builds had. En hij contacteerde me via een instant messaging-app en zei: "Hey, ik heb gezien dat je problemen hebt, ik heb gekeken, en je hoeft alleen de instelling te veranderen, en het werkt. En ik heb het gewoon voor je gefixt."

Als ik in een andere omgeving zou ontwikkelen waar ik software lokaal op mijn pc had geïnstalleerd, zou niemand ooit weten dat ik problemen had. Ik zou eruit moeten gaan en vragen. Ook waarschijnlijk zou ik niet in staat zijn om hetzelfde scenario te reproduceren. Waarschijnlijk zat ik er de hele dag vast. En ik had misschien na een tijdje opgegeven. Dus het vermogen om snel toegang te krijgen tot software die je niet lokaal hoeft te installeren, en in een gezond sandbox te kunnen spelen, was voor mij een grote openbaring van hoe dit verandert hoe je werkt, gewoon door deze soort gedeelde assets onder je team te hebben.

RTInsights: Nog iets?

Morphew: Wat we naar de niet-te-verre toekomst uitkijken, is digitale feedbacklussen waarbij je data van het apparaat haalt, data uit je ontwikkelomgeving haalt, en die terugvoedt om je software te verbeteren. AI en machine learning spelen hierin ook een rol. Welke informatie kan ik van deze apparaten krijgen? Hoe kan ik die analyseren met een grootschalig cloud-, big data-model of engine, en dan terugvoeden in toekomstige software-ontwikkeling? Dat kan me helpen een systeem als geheel te optimaliseren.