Usando DevOps para enfrentar desafios de software incorporado

O DevOps é considerado a melhor forma de atender às demandas do mercado de software embarcado por mais aplicativos e novos recursos, todos disponibilizados em tempos mais curtos.

Uma tempestade perfeita está se formando para o desenvolvimento de software de dispositivos incorporados. Os dispositivos incorporados estão se proliferando, principalmente porque novas opções de conectividade, como 5G, possibilitam aplicativos inovadores de dispositivos conectados, e seu uso está se expandindo, aproveitando os novos recursos de análise e inteligência artificial. Ao mesmo tempo, as necessidades do ciclo de vida do dispositivo, como responder a ataques cibernéticos em evolução, tornam necessário criar e implantar rapidamente alterações de software.

Essas condições impõem novas demandas ao pessoal de desenvolvimento e operações. Cada vez mais, o DevOps é considerado a melhor forma de atender às demandas do mercado por mais aplicativos e novos recursos, todos disponibilizados em tempos mais curtos. A RTInsights conversou recentemente com Graham Morphew, Diretor Sênior de Gerenciamento de Produto da Wind River. Discutimos os desafios do desenvolvimento de software de dispositivos incorporados, as diferenças entre DevOps para ambientes tradicionais e dispositivos incorporados e muito mais.

Aqui está um resumo da nossa conversa.

RTInsights:como o DevOps para dispositivos incorporados é diferente das abordagens tradicionais do DevOps para o desenvolvimento de software?

Morphew: Quando você observa o DevOps tradicional em um ambiente corporativo de TI, você tem um ambiente de execução onipresente. Você está rodando em servidores Intel na nuvem ou tem algo rodando em um PC Intel. Embutido é muito diferente. Seu ambiente de execução final geralmente é uma arquitetura diferente daquela que você está usando para desenvolvimento. Existem mais desafios devido à diversidade do hardware final e como você os implementa. Por exemplo, ao criar software para um ambiente baseado em nuvem, você sabe que está em um ambiente Google Cloud, Azure ou AWS. Quando você está construindo software incorporado, a diversidade de escolha para o ambiente de implantação é quase infinita, e você também pode ter dispositivos em locais remotos.

Portanto, há muitas diferenças em termos de como você pensa sobre o software e como essas diferenças se traduzem em desafios de implementação de DevOps.

Você deve lidar com hardware especializado, compilação cruzada, depuração cruzada, pegadas de memória e problemas de segurança. Você não tem os recursos quase ilimitados ao seu alcance, como teria em um ambiente de nuvem. Há uma ilha de execução que você precisa ter em mente ao projetar esses sistemas. Você também tem segurança para se preocupar. Você não necessariamente tem controle físico da segurança dos dispositivos. Você pode ter que lidar com adulteração física do dispositivo.

Outro desafio é que os dados desses dispositivos são mais difíceis de coletar. Em um ambiente DevOps, você deseja um loop de feedback contínuo. Isso é fácil se o desenvolvimento estiver em servidores que estão sob seu controle. Quando você está falando sobre dispositivos, eles provavelmente serão distribuídos remotamente e podem não estar online o tempo todo. Assim, muitos problemas diferentes entram em jogo ao comparar seu DevOps tradicional e DevOps para software incorporado.

RTInsights:Por que a comunidade de dispositivos incorporados migrará para DevOps? Por que está se tornando atraente e o que está acontecendo nos mercados para impulsionar isso?

Morphew: Com o software incorporado, há uma necessidade crescente de atualizações mais frequentes e de maior qualidade. Para chegar lá, você precisa de automação para ajudá-lo ao longo do caminho. A automação desempenhará um grande papel no futuro do software incorporado DevOpsand. Se você voltar uma década ou duas, havia muito foco no hardware que conduzia os recursos do dispositivo. Agora, muito, muito mais da tecnologia de diferenciação entre os fornecedores de dispositivos é o software.

Outro fator que empurra as empresas para DevOps para sistemas embarcados é algo que vemos bastante em Wind River:a mudança demográfica do desenvolvimento de software.

Existem dois campos muito distintos. Você tem seus desenvolvedores de software integrados tradicionais e recém-formados ou desenvolvedores entrando no domínio de dispositivos inteligentes de outros domínios de software. Os desenvolvedores tradicionais tendem a ser mais velhos, e muitos estão se aposentando. Como eu, há pessoas que entraram no mercado depois da faculdade em uma época em que você procurava manuais de hardware, registros de programas e coisas assim. Isso não é algo que os programas universitários gastam muito tempo agora.

Eu tenho um filho que está em idade universitária agora. Ele está programando em Python. Ele acabou de aprender C pela primeira vez, e isso foi uma grande surpresa. O Python oferece níveis muito mais altos de abstração.

O DevOps pode ajudar a superar essa obstrução entre o ambiente do aplicativo e o desejo de fazer com que pareça um ambiente familiar para os desenvolvedores de software do dispositivo. A necessidade de fazer isso é que as empresas que constroem dispositivos têm dificuldade em adquirir novos talentos de desenvolvimento de software.

Eu estava conversando com alguém que contratamos como estagiário recentemente, e ele nos disse que muitos de seus colegas querem ir para o Vale do Silício e trabalhar para empresas como Facebook, Google, Apple e Tesla. Para empresas nos segmentos industrial ou aeroespacial e de defesa, pode ser um desafio maior atrair o talento de software necessário que entraria e programaria dispositivos embarcados em um ambiente C rudimentar.

Para superar isso, algumas empresas acham que dar a essa nova geração de desenvolvedores de software um ambiente com o qual estão familiarizados ajudará. E essa é uma das razões pelas quais a Wind River está adotando um ambiente Visual Studio Code. O Visual Studio Code é um ambiente que teve um rápido crescimento em popularidade desde que chegou ao mercado. Todos com quem conversamos, vindos de uma nova perspectiva de graduação, estão muito familiarizados com o VS Code, e vemos menos experiência do novo desenvolvedor com ambientes mais antigos como o Eclipse. Então, às vezes você precisa estar onde seu público já está.

RTInsights:Quais problemas as empresas enfrentam quando tentam adotar soluções DevOps? E quais são os principais desafios para o reino de dispositivos incorporados em relação a outros domínios?

Morphew: O maior desafio é a mudança cultural que precisa acontecer dentro das empresas. E isso não é necessariamente um desafio específico incorporado. Está mais profundamente enraizado em algumas práticas de desenvolvimento de software.

Você tem equipes pequenas e, em muitos casos, indivíduos que realizam tarefas muito específicas. Você precisa de um nível de colaboração e cooperação com o DevOps que às vezes tire as pessoas do reino com o qual elas se sentiram confortáveis ​​por vários anos. Você tem que dizer:“Todos estão trabalhando juntos”.

A parte Ops do DevOps para incorporado é um desafio porque, em um ambiente tradicional de DevOps para a nuvem, o Opsis é bastante padrão. Você está executando um site ou desenvolvendo um aplicativo que faz algo por meio de uma interface baseada em nuvem. Quando você está falando de incorporado, está falando de um dispositivo em campo, e o que esse dispositivo faz é específico para sua empresa. Em muitos casos, os fabricantes dos dispositivos não são as empresas que operam os dispositivos. Um fabricante de equipamentos pode estar vendendo seu aparelho para uma grande empresa elétrica ou um grande fabricante. Essas empresas são as que operam os dispositivos. Às vezes, há assistência do fabricante do dispositivo, mas não é um ciclo completamente fechado como você pode ver com uma solução baseada em nuvem.

Há problemas de compatibilidade do conjunto de ferramentas. Ter um ambiente de desenvolvimento comum às vezes encontra resistência. Então, isso volta a alguns dos suportes culturais e gerenciais que você precisa para implementar esses sistemas.

E depois há o problema de hardware novamente. É um tema comum no mercado de embutidos. Como você obtém hardware suficiente para construir os ambientes de automação necessários para tornar o DevOps realidade? Isso é um desafio permanente. Normalmente, os clientes bem-sucedidos têm uma combinação de hardware e simulação para ampliar seus processos de teste.

RTInsights:existem ferramentas que facilitariam a transição para o DevOps?

Morphew: Uma coisa que ajuda as empresas a passar por essa revolução é a disponibilidade de ferramentas. Muitas dessas ferramentas são de código aberto ou têm versões gratuitas. O que você veria frequentemente era uma consolidação em torno de algum tipo de gerenciamento de código-fonte, geralmente um sabor de Git. Agora, as organizações deixaram de ter uma solução muito centrada no gerenciamento de código-fonte para incluir cada vez mais tipos de ferramentas de DevOps em suas soluções. Isso ajuda as empresas a fazer a transição.

Há muita escolha. Você pode argumentar que às vezes há muita escolha. O desafio que vemos os clientes tendo agora é, sim, existem muitas ferramentas. Como faço para reuni-los em uma solução que funcione para mim?

Hoje, muitas empresas estão iniciando projetos nos quais estão formando equipes internamente para gerenciar sua transição para um ambiente de desenvolvimento mais focado no digital. Vemos uma transição acontecendo agora no espaço incorporado como o que vimos com outras transições tecnológicas. Em muitos casos, é uma mentalidade do tipo “faça você mesmo” de “vamos construir o sistema perfeito para nós, vamos personalizá-lo de acordo com nossas necessidades”. Esses esforços estão drenando cada vez mais recursos da empresa apenas para manter essas coisas no futuro. Não é necessariamente onde eles querem investir. Essa abordagem provavelmente evoluirá para uma em que as pessoas procuram que outra empresa mantenha mais de seu ambiente ao longo do tempo.

Outra área em que, em última análise, as empresas podem facilitar suas vidas é ter separações claras entre o desenvolvimento de aplicativos e a manutenção das plataformas de software em que estão sendo executadas. Antes, você tinha uma pequena equipe que fazia as duas coisas, e o aplicativo e a plataforma se fundiam. Mas agora, você precisa dessa separação clara para modularizar seu software e fazer com que as pessoas trabalhem no que elas têm as melhores habilidades.

RTInsights:quais são os drivers do setor para soluções que facilitam o desenvolvimento e teste de software para dispositivos incorporados?

Morphew :Há a convergência dos mundos de TI e OT. Você tem dispositivos conectados à Internet. Isso tem sido um grande motivador para as empresas reexaminarem como elas entregam software. Além disso, existem vários setores em que você tem requisitos relacionados à conformidade para atualizar o software nos dispositivos. Você vê isso na área médica, onde agora você deve provar que pode atualizar seu dispositivo se uma vulnerabilidade de segurança for conhecida. Este pode ser um cenário de vida ou morte. Você precisa ser capaz de provar que pode resolver esse problema, se surgir um.

Esses drivers estão levando as empresas a analisar os processos que estão usando em relação à capacidade de fazer atualizações remotas. O que vemos é que muitas empresas maiores sentem a ameaça dessas empresas novas e emergentes digitalmente nativas. Existem até termos que eles usam para descrevê-lo. Você ouve o termo Teslafication. Eles estão dizendo que precisam ser mais como Tesla e ser um negócio muito, muito focado em software, em oposição ao tipo de pensamento de tijolo e argamassa, aço e ferro que está mais associado a hardware. Cada vez mais, eles devem diferenciar seu produto no software que roda nas coisas que estão construindo.

A pandemia também acelerou essa tendência. Você tem a maior parte da força de trabalho focada em software trabalhando em casa. E, em muitos casos, um número significativo de funcionários não voltará ao escritório depois que isso terminar. Essa é uma grande mudança. Portanto, você precisa mudar a maneira como pensa sobre o trabalho para tornar essa situação produtiva para os desenvolvedores. Isso é desafio. Ele clama, até certo ponto, por mais ferramentas de colaboração e mais padronização em termos de como as coisas são feitas, porque você não tem muitas pessoas trabalhando cara a cara e colaborando da maneira mais tradicional.

RTInsights:Passando para um problema diferente, por que as iterações rápidas de software se tornaram uma vantagem crítica e competitiva em todos os setores? E como isso se relaciona com a necessidade de testes automatizados?

Morphew: Já passei por vários projetos que fizeram a transição de um modelo em cascata para um modelo mais ágil. Essa capacidade de fazer testes contínuos, testes automatizados é muitas vezes o fator limitante em termos de aumento de sua produtividade. Se você vai correr rápido e ainda quer manter sua qualidade, é uma necessidade. Esta é uma área específica em que ter um gêmeo digital do seu dispositivo final permite que você faça muitos testes nele, e você pode fazê-lo em escala.

Um dos grandes adventos que vemos em termos de DevOps ser aplicável a incorporados é a capacidade de fazer uma simulação do dispositivo incorporado e usá-lo em escala em um ambiente baseado em nuvem. Dessa forma, você pode ter uma centena de testes rodando simultaneamente. Você está limitado apenas pelos recursos da nuvem. Essa é uma das transformações pelas quais vemos várias empresas passando e algo que elas valorizam bastante.

Temos um negócio de simulação na WindRiver há muitos anos. Alguns dos primeiros adotantes estavam fazendo muito isso em seus servidores, ampliando um grande número de simulações. Mas quando você o move para a nuvem, não precisa comprar novos servidores a cada seis meses.

Você tem controle sobre o tipo de hardware que está usando e a quantidade dele. Você pode discar para cima e para baixo dependendo do que você precisa a qualquer momento, em vez de ter a despesa de capital de grandes equipes de hardware e TI para mantê-lo. No momento, vemos um equilíbrio ou uma espécie de ambiente de nuvem híbrida, onde alguns dos testes são feitos localmente e outros em uma nuvem pública.

RTInsights:há algum outro ponto que você queira mencionar que deixamos de fora?

Morphew: Quando você fala sobre DevOps e a migração do desenvolvimento de software incorporado para um ambiente mais nativo e focado na nuvem, há várias coisas que eu vi pessoalmente como gerente de produto que são grandes mudanças.

Uma delas é a colaboração. Eu estava tentando completar uma compilação do Linux. Eu não sou um engenheiro Linux testado e comprovado. Eu estava tendo alguns problemas para fazer uma compilação funcionar corretamente. E enquanto eu estava fazendo isso, um de nossos arquitetos de software Linux pôde ver que eu tinha várias compilações com falha. E ele me contatou por um aplicativo de mensagens instantâneas e disse:“Ei, eu vi que você está tendo alguns problemas, eu dei uma olhada, e você só precisa mudar a configuração, e você ficará bem. E eu fui em frente e consertei para você.”

Se eu estivesse desenvolvendo em um ambiente diferente onde tivesse software instalado no meu PC, ninguém jamais saberia que eu estava tendo problemas. Eu teria que sair e perguntar. Além disso, eu provavelmente não seria capaz de recriar esse mesmo cenário. Muito provavelmente, eu teria ficado preso nela o dia todo. E, eu posso ter desistido depois de um tempo. Então, a capacidade de obter acesso rápido a software que você não precisa instalar localmente, e poder jogar em uma sandbox comum, para mim, foi uma grande revelação sobre como isso muda a forma como você trabalha, apenas de essencialmente ter esses tipos de ativos compartilhados entre sua equipe.

RTInsights:mais alguma coisa?

Morphew: A única coisa que esperamos em um futuro não muito distante é ter ciclos de feedback digital onde você está retirando dados do dispositivo, retirando dados de seu ambiente de desenvolvimento e alimentando-os de volta para melhorar seu software. A IA e o aprendizado de máquina também participam disso. Que tipo de informação posso obter desses dispositivos? Como posso analisá-lo potencialmente com um tipo de big data de grande escala de nuvem de um modelo ou mecanismo e, em seguida, alimentar isso de volta no desenvolvimento de software futuro? Isso poderia me ajudar a otimizar um sistema como um todo.