Aprovechar DevOps para superar los desafíos del software embebido

DevOps se considera la mejor forma de satisfacer las demandas del mercado de software embebido: más aplicaciones y nuevas funciones, disponibles en plazos más cortos.

La tormenta perfecta en el desarrollo de software embebido

Los dispositivos embebidos están proliferando, especialmente porque nuevas opciones de conectividad como 5G hacen posibles aplicaciones innovadoras de dispositivos conectados, y su uso se expande aprovechando nuevas capacidades de analítica e inteligencia artificial. Al mismo tiempo, las necesidades del ciclo de vida del dispositivo, como responder a ciberataques en evolución, hacen necesario crear e implementar cambios de software rápidamente.

Estas condiciones imponen nuevas demandas al personal de desarrollo y operaciones. Cada vez más, DevOps se considera la mejor forma de satisfacer las demandas del mercado. RTInsights conversó recientemente con Graham Morphew, Director Senior de Gestión de Producto en Wind River, sobre los desafíos del desarrollo de software para dispositivos embebidos, las diferencias entre DevOps para entornos tradicionales y dispositivos embebidos, y más.

Diferencias clave: DevOps tradicional vs. embebido

Morphew: En DevOps tradicional en un entorno empresarial de TI, tienes un entorno de ejecución ubicuo: servidores Intel en la nube o PC Intel. Lo embebido es muy diferente. Tu entorno de ejecución final suele ser una arquitectura distinta a la de desarrollo. Hay más desafíos debido a la diversidad del hardware final y cómo se despliega en él. Por ejemplo, al construir software para la nube, sabes que irá a Google Cloud, Azure o AWS. En software embebido, la diversidad de entornos de despliegue es casi infinita, y puedes tener dispositivos en ubicaciones remotas.

Debes lidiar con hardware especializado, compilación cruzada, depuración cruzada, huellas de memoria y problemas de seguridad. No tienes recursos casi ilimitados como en la nube. Hay una "isla de ejecución" que debes tener en cuenta al diseñar estos sistemas. También está la seguridad: no necesariamente tienes control físico de la seguridad de los dispositivos; puedes enfrentarte a manipulación física.

Otro desafío: los datos de estos dispositivos son más difíciles de recopilar. En DevOps quieres un bucle de retroalimentación continua. Es fácil si el desarrollo está en servidores bajo tu control. Con dispositivos distribuidos remotamente, que pueden no estar siempre en línea, surgen muchos problemas diferentes.

¿Por qué la comunidad embebida se mueve hacia DevOps?

Morphew: Hay una necesidad creciente de actualizaciones más frecuentes y mayor calidad en software embebido. Para lograrlo, necesitas automatización. La automatización jugará un papel importante en el futuro de DevOps y software embebido. Hace una o dos décadas, el foco estaba en el hardware impulsando las capacidades del dispositivo. Ahora, gran parte de la tecnología diferenciadora entre proveedores es software.

Otro factor es el cambio demográfico en el desarrollo de software. Hay dos bandos distintos: desarrolladores embebidos tradicionales y nuevos graduados que entran al dominio de dispositivos inteligentes desde otros dominios de software. Los tradicionales tienden a ser mayores y muchos se jubilan. Los programas universitarios ya no dedican mucho tiempo a manuales de hardware y programación de registros.

DevOps puede ayudar a superar esta barrera entre el entorno de aplicación y el deseo de que parezca familiar a los desarrolladores de software de dispositivos. Las empresas que construyen dispositivos tienen dificultades para adquirir nuevo talento de desarrollo de software. Muchos recién graduados quieren ir a Silicon Valley a trabajar para Facebook, Google, Apple, Tesla. Para empresas en segmentos industriales o aeroespaciales y de defensa, puede ser más difícil atraer talento que programe en C rudimentario.

Para superar esto, algunas empresas piensan que dar a la nueva generación un entorno familiar ayudará. Por eso Wind River adopta un entorno Visual Studio Code. VS Code ha visto un crecimiento rápido en popularidad; casi todos los nuevos graduados lo conocen bien, y vemos menos experiencia con entornos antiguos como Eclipse. A veces tienes que estar donde tu audiencia ya está.

Problemas al adoptar DevOps y desafíos clave

Morphew: El mayor desafío es el cambio cultural que debe ocurrir dentro de las empresas. No es necesariamente específico de lo embebido; está arraigado en prácticas de desarrollo. Tienes equipos pequeños e individuos que hacen tareas muy específicas. Necesitas un nivel de colaboración y cooperación con DevOps que a veces saca a la gente de su zona de confort. Tienes que decir: "Todos trabajan juntos".

La parte de Ops en DevOps para lo embebido es un desafío porque, en la nube, Ops es bastante estándar. En lo embebido, hablas de un dispositivo en el campo, y lo que hace es específico de tu empresa. A menudo, los fabricantes de dispositivos no son quienes los operan. Un fabricante de equipos puede vender su dispositivo a una gran eléctrica o fabricante. Esas empresas operan los dispositivos. A veces hay asistencia del fabricante, pero no es un circuito completamente cerrado como en la nube.

Hay problemas de compatibilidad de herramientas. Tener un entorno de desarrollo común a veces encuentra resistencia. Y vuelve el tema del hardware: ¿cómo conseguir suficiente hardware para construir los entornos de automatización que DevOps necesita? Es un desafío continuo. Los clientes exitosos suelen tener una mezcla de hardware y simulación para escalar sus procesos de prueba.

Herramientas para facilitar la transición

Morphew: Una cosa que ayuda es la disponibilidad de herramientas, muchas de código abierto o con versiones gratuitas. Antes veías consolidación en torno a algún sistema de gestión de código fuente, a menudo Git. Ahora las organizaciones han pasado de centrarse solo en gestión de código a incluir más herramientas tipo DevOps. Eso ayuda a la transición.

Hay mucha elección; a veces demasiada. El desafío que vemos en clientes es: hay muchas herramientas, ¿cómo las junto en una solución que funcione para mí?

Hoy muchas empresas inician proyectos formando equipos internos para gestionar su transición a un entorno de desarrollo más enfocado digitalmente. Vemos una transición en el espacio embebido similar a otras transiciones tecnológicas. En muchos casos, es una mentalidad "hágalo usted mismo": "Construyamos el sistema perfecto para nosotros, personalicémoslo". Esos esfuerzos drenan recursos solo para mantenerlos. Ese enfoque probablemente evolucione hacia buscar que otra empresa mantenga más de su entorno con el tiempo.

Otra área donde las empresas pueden facilitarse la vida es tener separaciones claras entre desarrollo de aplicaciones y mantenimiento de las plataformas de software que ejecutan. Antes, un equipo pequeño hacía ambas cosas y la aplicación y plataforma se fusionaban. Ahora necesitas esa separación clara para modularizar tu software y que la gente trabaje en lo que mejor sabe.

Impulsores de la industria para soluciones de desarrollo y prueba

Morphew: Hay convergencia de mundos TI y OT. Dispositivos conectados a Internet. Esto ha sido un gran impulsor para que las empresas reexaminen cómo entregan software. También hay industrias con requisitos de cumplimiento para actualizar software en dispositivos. En el campo médico, ahora debes probar que puedes actualizar tu dispositivo si se conoce una vulnerabilidad de seguridad. Puede ser un escenario de vida o muerte.

Estos impulsores empujan a las empresas a examinar sus procesos respecto a su capacidad de actualizaciones remotas. Vemos que muchas empresas grandes sienten la amenaza de empresas nuevas nativas digitales. Hay términos para describirlo: "Teslafication". Dicen que necesitan ser más como Tesla: un negocio muy enfocado en software, en lugar de pensamiento de ladrillo, acero y hierro asociado al hardware. Cada vez más, deben diferenciar su producto en el software que corre en lo que construyen.

La pandemia también aceleró esta tendencia. La mayor parte de la fuerza laboral enfocada en software trabaja desde casa, y muchos no volverán a la oficina. Eso exige cambiar la forma de pensar el trabajo para que sea productivo para desarrolladores. Grita la necesidad de más herramientas de colaboración y estandarización, porque no tienes gente cara a cara colaborando de forma tradicional.

Iteraciones rápidas de software: ventaja competitiva y pruebas automatizadas

Morphew: He pasado por varios proyectos que transitaron de cascada a ágil. La capacidad de hacer pruebas continuas, automatizadas, es a menudo el factor limitante para aumentar productividad. Si vas a correr rápido y mantener calidad, es una necesidad. Aquí es donde tener un gemelo digital de tu dispositivo final te permite hacer muchas pruebas en él, y a escala.

Uno de los grandes avances para que DevOps sea aplicable a lo embebido es la capacidad de tomar una simulación del dispositivo embebido y usarla a escala en un entorno cloud. Así puedes tener cien pruebas simultáneas, limitado solo por recursos cloud. Es una transformación que varias empresas están atravesando y valoran altamente.

Wind River tiene negocio de simulación desde hace años. Algunos adoptantes tempranos hacían esto en sus servidores, escalando grandes números de simulaciones. Pero al moverlo a la nube, no tienes que comprar servidores nuevos cada seis meses. Tienes control sobre el tipo y cantidad de hardware. Puedes subir y bajar según necesites, en lugar de gasto de capital en hardware grande y equipos TI para mantenerlo. Ahora vemos un equilibrio o entorno híbrido cloud: algunas pruebas on-premise, otras en cloud público.

Colaboración y bucles de retroalimentación digital

Morphew: Cuando hablas de DevOps y mover desarrollo embebido a un entorno cloud-native, hay varios cambios grandes que he visto como gestor de producto.

Uno es la colaboración. Intentaba completar una compilación de Linux; no soy ingeniero de Linux experimentado. Tenía problemas para que funcionara. Mientras lo hacía, uno de nuestros arquitectos de software Linux vio que tenía varias compilaciones fallidas. Me contactó por mensajería instantánea: "Hey, vi que tienes problemas, eché un vistazo, solo necesitas cambiar este ajuste y listo. Y lo arreglé por ti".

Si estuviera en un entorno donde tengo software instalado en mi PC, nadie sabría que tengo problemas. Tendría que salir a preguntar. Probablemente no podría recrear el mismo escenario. Me habría quedado atascado todo el día, quizás habría renunciado. La capacidad de acceso rápido a software que no tienes que instalar localmente, y jugar en una "caja de arena" común, fue un gran descubrimiento de cómo esto cambia el trabajo, simplemente teniendo activos compartidos en el equipo.

Mirando al futuro no muy lejano: bucles de retroalimentación digital donde tomas datos del dispositivo, datos de tu entorno de desarrollo, y los retroalimentas para mejorar tu software. IA y machine learning juegan aquí. ¿Qué información puedo obtener de estos dispositivos? ¿Cómo analizarla potencialmente con un modelo de big data a escala cloud, y retroalimentarla al desarrollo futuro? Eso podría ayudarme a optimizar un sistema en su conjunto.