Uso de DevOps para abordar los desafíos del software integrado

DevOps se considera la mejor manera de satisfacer las demandas del mercado de software integrado de más aplicaciones y nuevas funciones, todo disponible en tiempos más cortos.

Se está gestando una tormenta perfecta para el desarrollo de software de dispositivos integrados. Los dispositivos integrados están proliferando, particularmente porque las nuevas opciones de conectividad, como 5G, hacen posibles las aplicaciones innovadoras de dispositivos conectados, y su uso se está expandiendo, aprovechando las nuevas capacidades de análisis e inteligencia artificial. Al mismo tiempo, las necesidades del ciclo de vida del dispositivo, como responder a los ataques cibernéticos en evolución, hacen que sea necesario crear e implementar cambios de software rápidamente.

Estas condiciones imponen nuevas exigencias al personal de desarrollo y operaciones. Cada vez más, DevOps se considera la mejor manera de satisfacer las demandas del mercado de más aplicaciones y nuevas funciones, todo disponible en tiempos más cortos. RTInsights se reunió recientemente con Graham Morphew, director sénior de gestión de productos de Wind River. Discutimos los desafíos del desarrollo de software para dispositivos integrados, las diferencias entre DevOps para entornos tradicionales y dispositivos integrados, y más.

Aquí hay un resumen de nuestra conversación.

RTInsights:¿En qué se diferencia DevOps para dispositivos integrados de los enfoques tradicionales de DevOps para desarrollar software?

Morphew: Cuando observa DevOps tradicional en un entorno empresarial de TI, tiene un entorno de ejecución ubicuo. O está ejecutando en servidores Intel en la nube, o tiene algo ejecutándose en una PC Intel. Embedded es muy diferente. Su entorno de ejecución final suele ser una arquitectura diferente a la que está utilizando para el desarrollo. Hay más desafíos debido a la diversidad del hardware final y cómo se implementa en ellos. Por ejemplo, cuando crea software para un entorno basado en la nube, sabe que va a funcionar en un entorno de Google Cloud, Azure o AWS. Cuando crea software integrado, la diversidad de opciones para el entorno de implementación es casi infinita y también puede tener dispositivos en ubicaciones remotas.

Por lo tanto, existen muchas diferencias en términos de cómo piensa sobre el software y cómo estas diferencias se traducen en desafíos de implementación de DevOps.

Debe lidiar con hardware especializado, compilación cruzada, depuración cruzada, huellas de memoria y problemas de seguridad. No tiene los recursos casi ilimitados a su alcance como lo haría en un entorno de nube. Hay una isla de ejecución que debe tener en cuenta al diseñar estos sistemas. También tienes que preocuparte por la seguridad. No necesariamente tiene el control físico de la seguridad de los dispositivos. Es posible que deba lidiar con la manipulación física del dispositivo.

Otro desafío es que los datos de estos dispositivos son más difíciles de recopilar. En un entorno DevOps, desea un bucle de retroalimentación continuo. Eso es fácil si el desarrollo se realiza en servidores que están bajo su control. Cuando habla de dispositivos, es probable que se distribuyan de forma remota y es posible que no estén en línea todo el tiempo. Por lo tanto, muchos problemas diferentes entran en juego al comparar sus DevOps tradicionales y DevOps para software integrado.

RTInsights:¿Por qué la comunidad de dispositivos integrados se moverá hacia DevOps? ¿Por qué se está volviendo convincente y qué está sucediendo en los mercados para impulsar esto?

Morfeo: Con el software incorporado, existe una creciente necesidad de actualizaciones más frecuentes y de mayor calidad. Para llegar allí, necesita automatización que lo ayude en el camino. La automatización jugará un papel importante en el futuro de DevOps y el software integrado. Si retrocedes una década o dos, había mucho enfoque en el hardware que impulsaba las capacidades del dispositivo. Ahora, mucho, mucho más de la tecnología que diferencia a los proveedores de dispositivos es el software.

Otro factor que empuja a las empresas hacia DevOps para sistemas integrados es algo que vemos bastante en Wind River:la demografía cambiante del desarrollo de software.

Hay dos campos muy distintos. Tiene a sus desarrolladores tradicionales de software embebido y nuevos graduados o desarrolladores ingresando al dominio de dispositivos inteligentes desde otros dominios de software. Los desarrolladores tradicionales tienden a ser mayores y muchos se están jubilando. Al igual que yo, hay personas que ingresaron al mercado después de la universidad en un momento en el que mirarías manuales de hardware, registros de programas y cosas por el estilo. Eso no es algo en lo que los programas universitarios dediquen mucho tiempo ahora.

Tengo un hijo que ahora está en edad universitaria. Está programando en Python. Acaba de aprender C por primera vez, y eso fue una gran revelación. Python ofrece niveles mucho más altos de abstracción.

DevOps puede ayudar a superar esta obstrucción entre el entorno de la aplicación y querer hacer que parezca un entorno familiar para los desarrolladores de software de dispositivos. La necesidad de hacer esto es que las empresas que fabrican dispositivos tienen problemas para adquirir nuevos talentos de desarrollo de software.

Estaba hablando con alguien que habíamos contratado recientemente como pasante y nos dijo que muchos de sus compañeros de clase quieren ir a Silicon Valley y trabajar para compañías como Facebook, Google, Apple y Tesla. Para las empresas en los segmentos industrial, aeroespacial y de defensa, puede ser un desafío mayor atraer el talento de software necesario que vendría y programaría dispositivos integrados en un entorno C rudimentario.

Para superar esto, algunas empresas piensan que brindar a la nueva generación de desarrolladores de software un entorno con el que estén familiarizados ayudará. Y esa es una de las razones por las que Wind River está adoptando un entorno de Visual Studio Code. Visual Studio Code es un entorno que ha experimentado un rápido crecimiento en popularidad desde que salió al mercado. Todas las personas con las que hablamos, provenientes de una nueva perspectiva de posgrado, están muy familiarizadas con VS Code, y vemos menos experiencia del nuevo desarrollador con entornos más antiguos como Eclipse. Entonces, a veces tienes que estar donde tu audiencia ya está.

RTInsights:¿Qué problemas tienen las empresas cuando intentan adoptar soluciones DevOps? ¿Y cuáles son los desafíos clave para el ámbito de los dispositivos integrados en comparación con otros dominios?

Morphew: El mayor desafío es el cambio cultural que tiene que ocurrir dentro de las empresas. Y esto no es necesariamente un desafío específico integrado. Está más profundamente arraigado en algunas prácticas de desarrollo de software.

Tiene equipos pequeños y, en muchos casos, personas que realizan tareas muy específicas. Necesita un nivel de colaboración y cooperación con DevOps que a veces saca a las personas del ámbito en el que se han sentido cómodos durante varios años. Tienes que decir:"Todos están trabajando juntos".

La parte de operaciones de DevOps para sistemas integrados es un desafío porque, en un entorno tradicional de DevOps para la nube, Opsis es bastante estándar. Está ejecutando un sitio web o desarrollando una aplicación que hace algo a través de una interfaz basada en la nube. Cuando habla de integrado, se refiere a un dispositivo en el campo, y lo que hace ese dispositivo es específico de su empresa. En muchos casos, los fabricantes de dispositivos no son las empresas que operan los dispositivos. Un fabricante de equipos puede estar vendiendo su dispositivo a una gran compañía eléctrica oa un gran fabricante. Esas empresas son las que operan los dispositivos. A veces hay asistencia del fabricante del dispositivo, pero no es un ciclo completamente cerrado de la forma en que podría verse con una solución basada en la nube.

Hay problemas de compatibilidad con el conjunto de herramientas. Tener un entorno de desarrollo común a veces encuentra resistencia. Así que eso vuelve a parte del respaldo cultural y de gestión que necesita para implementar estos sistemas.

Y luego está el problema del hardware otra vez. Es un tema común en el mercado integrado. ¿Cómo se obtiene suficiente hardware para construir los entornos de automatización necesarios para hacer que DevOps sea una realidad? Ese es un desafío continuo. Por lo general, los clientes exitosos tienen una combinación de hardware y simulación para ampliar sus procesos de prueba.

RTInsights:¿Existen herramientas que facilitarían la transición a DevOps?

Morfeo: Una cosa que ayuda a las empresas a superar esta revolución es la disponibilidad de herramientas. Muchas de estas herramientas son de código abierto o tienen versiones gratuitas. Lo que a menudo se veía era una consolidación en torno a algún tipo de Gestión de código fuente, a menudo un tipo de Git. Ahora, las organizaciones han pasado de tener una solución muy centrada en la gestión del código fuente a incluir más y más tipos de herramientas DevOps dentro de sus soluciones. Eso ayuda a las empresas a hacer la transición.

Hay muchas opciones. Puede argumentar que a veces hay demasiadas opciones. El desafío que vemos que tienen los clientes ahora es, sí, hay muchas herramientas. ¿Cómo los reúno en una solución que funcione para mí?

Hoy en día, muchas empresas están iniciando proyectos en los que forman equipos internamente para gestionar su transición a un entorno de desarrollo más centrado en lo digital. Vemos que está ocurriendo una transición ahora en el espacio integrado como lo que vimos con otras transiciones tecnológicas. En muchos casos, es en gran medida una mentalidad de "hazlo tú mismo" de "construyamos el sistema perfecto para nosotros, personalicémoslo según nuestras necesidades". Dichos esfuerzos están drenando más y más recursos de la empresa solo para mantener estas cosas en el futuro. Eso no es necesariamente donde quieren invertir. Es probable que ese enfoque evolucione a uno en el que las personas busquen que otra empresa mantenga más de su entorno con el tiempo.

Otra área donde, en última instancia, las empresas pueden hacer sus vidas más fáciles es tener separaciones claras entre el desarrollo de aplicaciones y el mantenimiento de las plataformas de software en las que se ejecutan. Solía ​​ser que tenía un pequeño equipo que hacía ambas cosas, y la aplicación y la plataforma se fusionaron entre sí. Pero ahora, necesita esa separación clara para modularizar su software y hacer que las personas trabajen en aquello para lo que tienen las mejores habilidades.

RTInsights:¿Cuáles son los impulsores de la industria para las soluciones que facilitan el desarrollo y la prueba de software para dispositivos integrados?

Morfeo :Existe la convergencia de los mundos de TI y OT. Tiene dispositivos conectados a Internet. Este ha sido un gran impulsor para que las empresas revisen cómo entregan el software. Además, hay varias industrias en las que tiene requisitos relacionados con el cumplimiento para actualizar el software en los dispositivos. Lo ve en el campo médico, donde ahora debe demostrar que puede actualizar su dispositivo si se conoce una vulnerabilidad de seguridad. Esto puede ser un escenario de vida o muerte. Debe poder demostrar que puede abordar dicho problema si surge uno.

Dichos impulsores están presionando a las empresas para que observen los procesos que están utilizando con respecto a su capacidad para realizar actualizaciones remotas. Lo que vemos es que muchas empresas más grandes sienten la amenaza de estas empresas nuevas y prometedoras nativas digitalmente. Incluso hay términos que usan para describirlo. Escuchas el término Teslaficación. Están diciendo que deben ser más como Tesla y ser un negocio muy, muy centrado en el software, a diferencia del tipo de pensamiento de ladrillo y mortero, acero y hierro que está más asociado con el hardware. Cada vez más, deben diferenciar su producto en el software que se ejecuta en las cosas que están construyendo.

La pandemia también ha acelerado esta tendencia. Tiene la mayor parte de la fuerza laboral centrada en el software trabajando desde casa. Y en muchos casos, un número significativo de empleados no van a volver a la oficina después de que esto termine. Ese es un gran cambio. Por lo tanto, debe cambiar su forma de pensar acerca del trabajo para que esa situación sea productiva para los desarrolladores. Eso es un desafío. Pide a gritos, hasta cierto punto, más herramientas de colaboración y más estandarización en términos de cómo se hacen las cosas porque no hay mucha gente trabajando cara a cara y colaborando de la manera más tradicional.

RTInsights:Pasando a un tema diferente, ¿por qué las iteraciones rápidas de software se han convertido en una ventaja competitiva crítica en todas las industrias? ¿Y cómo se relaciona eso con la necesidad de pruebas automatizadas?

Morphew: He pasado por varios proyectos que pasaron de un modelo en cascada a un modelo más ágil. Esa capacidad de realizar pruebas continuas y automatizadas suele ser el factor limitante en términos de aumento de la productividad. Si vas a correr rápido y aún quieres mantener tu calidad, es una necesidad. Esta es un área particular en la que tener un gemelo digital de su dispositivo final le permite realizar muchas pruebas en él y puede hacerlo a escala.

Uno de los grandes avances que vemos en términos de la aplicación de DevOps a dispositivos integrados es la capacidad de tomar una simulación del dispositivo integrado y luego usarlo a escala en un entorno basado en la nube. De esa manera, puede tener cien pruebas ejecutándose simultáneamente. Solo está limitado por los recursos de la nube. Esa es una de las transformaciones que vemos en varias empresas y algo que, en última instancia, valoran mucho.

Hemos tenido un negocio de simulación en WindRiver durante muchos años. Algunos de los primeros usuarios estaban haciendo mucho de esto en sus servidores, escalando grandes cantidades de simulaciones. Pero cuando lo mueve a la nube, no tiene que comprar nuevos servidores cada seis meses.

Tiene control sobre el tipo de hardware que está utilizando y la cantidad. Puede marcarlo hacia arriba y hacia abajo según lo que necesite en un momento dado, en lugar de tener el gasto de capital de grandes equipos de hardware y TI para mantenerlo. En este momento, vemos un equilibrio o una especie de entorno de nube híbrida, donde algunas de las pruebas se realizan localmente en las instalaciones y otras en una nube pública.

RTInsights:¿Hay algún otro punto que quiera mencionar que hayamos dejado fuera?

Morphew: Cuando habla de DevOps y de trasladar el desarrollo de software integrado a un entorno más nativo de la nube y centrado en la nube, hay varias cosas que he visto personalmente como gerente de producto que son grandes cambios.

Uno de ellos es la colaboración. Estaba tratando de completar una compilación de Linux. No soy un ingeniero de Linux probado y verdadero. Estaba teniendo algunos problemas para que una compilación funcionara correctamente. Y mientras estaba haciendo esto, uno de nuestros arquitectos de software de Linux pudo ver que había fallado varias compilaciones. Y me contactó a través de una aplicación de mensajería instantánea y me dijo:"Oye, he visto que tienes algunos problemas, eché un vistazo, solo necesitas cambiar la configuración y estarás bien". Y seguí adelante y lo arreglé para ti”.

Si estuviera desarrollando en un entorno diferente donde tuviera software instalado en mi PC, nadie sabría que estaba teniendo problemas. Tendría que salir y preguntar. Además, lo más probable es que no pueda recrear ese mismo escenario. Lo más probable es que hubiera estado atrapado en él todo el día. Y, puede que me haya dado por vencido después de un tiempo. Por lo tanto, la capacidad de obtener acceso rápido a software que no tiene que instalar localmente y poder jugar en un espacio aislado común, para mí, fue una gran revelación sobre cómo funciona este cambio, simplemente por tener este tipo de de activos compartidos entre su equipo.

RTInsights:¿algo más?

Morfeo: Lo único que esperamos en un futuro no muy lejano es tener bucles de retroalimentación digital en los que extraiga datos del dispositivo, extraiga datos de su entorno de desarrollo y vuelva a alimentarlos para mejorar su software. La IA y el aprendizaje automático también juegan un papel en esto. ¿Qué tipo de información puedo obtener de estos dispositivos? ¿Cómo puedo analizarlo potencialmente con un tipo de modelo o motor de big data a gran escala en la nube y luego retroalimentarlo en el futuro desarrollo de software? Eso podría ayudarme a optimizar un sistema como un todo.