En los últimos años, DevOps y DevSecOps han revolucionado la forma en que muchas empresas abordan el desarrollo y la gestión de software. De hecho, los términos se han utilizado con tanta frecuencia que se han convertido en un eufemismo para el desarrollo de software bien planificado y ejecutado.

Si bien es importante reconocer el valor de DevOps y DevSecOps, no son paradigmas únicos, monolíticos y permanentes. Ambos enfoques se están desarrollando dentro de sí mismos, y el aspecto de DevSecOps puede ir evolucionando con el tiempo

Vamos a hablar sobre esta tendencia y comentaremos 8 puntos clave que están impulsando y cambiando la adopción de DevOps, DevSecOps y una serie de enfoques relacionados para el desarrollo y la gestión.

 

El crecimiento de DevOps y DevSecOps

Estos enfoques se han vuelto muy populares entre la mayoría de los desarrolladores y gerentes y la razón es sencilla: no solo brindan una forma más integrada de administrar el riesgo de ciberseguridad, sino que también pueden hacer que los procesos y equipos de desarrollo sean mucho más ágiles. Esto se debe a que DevOps distribuye eficazmente las tareas necesarias entre los equipos operativos y de desarrollo. Con menos gente trabajando, más eficientes pueden ser.

A pesar de los desafíos de adoptar estos enfoques, se considera que los posibles beneficios que se pueden lograr justifican este riesgo. Para la mayoría de los equipos de desarrollo, esto significará primero pasar a un proceso de DevOps y luego evolucionar a DevSecOps.

Más allá de los beneficios operativos que se pueden obtener durante esta transición, existen otras ventajas. Uno de los efectos que a menudo se pasan por alto de cuán extendido se ha vuelto DevOps es que, para muchos desarrolladores, se ha convertido en la forma de trabajo predeterminada. Una especialista del área dice, en resumen, que “DevOps se ha vuelto de repente tan omnipresente en los círculos de ingeniería de software que se le perdonará si no se dio cuenta de que el término no existía hasta 2009 … DevOps se extiende más allá las herramientas y las mejores prácticas necesarias para lograr su implementación. La introducción exitosa de DevOps exige un cambio de cultura y mentalidad”. Y en Gravity damos fe de que esto es cierto. Nuestra dinámica de trabajo se basa en una estrategia DevOps desde el primer minuto y, en ocasiones, ayudamos a las empresas a adoptar esta cultura.

 

Microservicios

La transición a DevOps va acompañada de una transición paralela consciente de arquitecturas monolíticas y hacia aquellas que se componen de una red de componentes más pequeños y ágiles.

Hay varias formas en las que esta tendencia general se manifiesta en la práctica. La creciente popularidad del uso de contenedores, evidencia que la implementación de software ahora se maneja generalmente a través de jerarquías de contenedores. En un nivel más amplio, estas nuevas arquitecturas son síntomas de un cambio más amplio desde los servidores y sistemas centralizados hacia los microservicios, una forma de diseñar aplicaciones de software como conjuntos de servicios implementables de forma independiente.

Esta tendencia no ha estado exenta de críticas y, a menudo, puede presentar tantos desafíos para las organizaciones como oportunidades. Pero con enfoques más sólidos y maduros para la gestión de la seguridad de múltiples nubes que se desarrollan continuamente, la dirección general de viaje aquí parece inevitable.

 

Cloud Cloud y más Cloud

El uso de una estrategia de Microservicios basa en contenedores también ha ayudado a acelerar una tendencia relacionada, y que se ha estado ejecutando durante casi una década: el desarrollo y la administración de software en la nube como enfoque predeterminado.

Cuando DevOps se estaba desarrollando por primera vez como un paradigma de codificación y gestión, uno de los principales problemas de planificación de la transición era crear servicios en la nube a los que pudieran acceder de forma eficiente y segura equipos con necesidades muy diferentes: desarrolladores, personal de operaciones e incluso departamentos de atención al cliente. Ahora que existen varios servicios bien diseñados para satisfacer esta necesidad, podemos planificar el software que se ejecuta en la nube de forma predeterminada, pero esto es una consecuencia del éxito del modelo DevOps, más que un requisito previo para su aparición.

 

Orquestado de Contenedores

A un nivel más específico, la influencia del uso de contenedores en el desarrollo continuo de DevOps y DevSecOps es difícil de exagerar. Y para la mayoría de las empresas, el orquestado de contenedores es sinónimo de Kubernetes.

La popularidad de Kubernetes, junto con Docker como parte de una infraestructura en contenedores, está directamente relacionada con algunos de los cambios que detallamos anteriormente. De hecho, los contenedores se han vuelto tan cruciales para el tipo de enfoques descentralizados y masivamente paralelos que ahora se utilizan para el desarrollo de software que es difícil imaginar DevOps sin ellos.

Kubernetes facilita la construcción de una infraestructura basada no en un control centralizado, sino en una anarquía creativa cuidadosamente supervisada. La mayoría de los equipos de DevOps ahora permiten que incluso los miembros más jóvenes de sus equipos hagan lo que se habría considerado como grandes cambios en los repositorios de software activos, pero la contenedorización significa que estos cambios están respaldados por una detección continua, lo que garantiza que sea significativamente más rápido para los equipos administrar las actualizaciones.

 

Infraestructura ágil

Aunque estos movimientos hacia la flexibilidad son más familiares como parte del ciclo de vida del desarrollo de software, vale la pena recordar que tienen sus rutas fuera de esta disciplina. El deseo de flexibilidad en tiempo real en los procesos de producción se puede rastrear, de hecho, a tendencias similares en el diseño industrial y de fabricación que se han desarrollado durante décadas.

En los campos industrial y de fabricación, el diseño de infraestructura flexible ha tenido un nombre durante mucho tiempo: el enfoque “ágil”. Este enfoque destaca la importancia de una infraestructura altamente robusta, altamente conectada y, sin embargo, relativamente económica. También enseñó a las grandes empresas manufactureras el valor de muchas de las características de las empresas de software: colaboración, organización, diversificación de conjuntos de habilidades para lograr resiliencia, iteración rápida y procesos de trabajo de auto-mejora.

 

Automatización del usuario final

La promesa de DevOps no se limita a facilitar el trabajo de los desarrolladores y el personal de operaciones. Al reunir a ambos equipos en una sola unidad, también se espera que la comunicación entre ellos sea mucho más eficiente y que los procesos que involucran de manera inherente a ambos equipos también sean más efectivos.

Para la mayoría de las empresas, el proceso de colaboración más crítico que requiere la participación de ambos equipos es el software de envío. Por eso, en los últimos años, hemos visto el surgimiento de una nueva familia de herramientas de automatización que tienen como objetivo facilitar el lanzamiento y la implementación de nuevo software. La promesa, aquí, es que el proceso técnico de lanzamiento de nuevo software (o actualización de software existente) se puede automatizar por completo.

Esto no significa, que los equipos de desarrollo u operaciones no participarán en el lanzamiento de software. Pero sí significa que estos equipos pueden centrarse en lo que es importante, garantizar que el software cumpla con los requisitos de los consumidores y la gestión, en lugar de los detalles técnicos de cómo se enviará.

 

Resiliencia

Aunque DevOps y DevSecOps se desarrollaron principalmente como soluciones de gestión, también están teniendo efectos en cadena en la forma en que las empresas de software abordan la ciberseguridad a un nivel filosófico.

Como hemos señalado anteriormente, la gestión de incidentes en la era de DevOps es radicalmente diferente del tipo de gestión de crisis que ocurría antes. En los días en que se enviaban nuevas iteraciones de un paquete de software. Una vez al año, los desarrolladores tenían tiempo para probar rigurosamente cada versión en busca de vulnerabilidades de seguridad y, a menudo, muchos meses para corregir las que habían pasado por alto.

Ese ya no es el caso, pero no tiene por qué ser algo malo. Debido a los rápidos programas de lanzamiento que ha introducido la era DevOps, muchos analistas de seguridad ahora ven su trabajo como proporcionar resistencia al software, en lugar de protección per se. En lugar de la expectativa poco realista de que todas las vulnerabilidades de seguridad se pueden parchear, muchos equipos de DevSecOps ahora trabajan asumiendo que cada pieza de software será vulnerable y se centran en proteger otras piezas de software de las consecuencias de esto.

 

AI y ML

También tenemos herramientas de IA y ML. Aunque los equipos de DevSecOps todavía están trabajando en cómo usarlos a escala, parece casi inevitable que la IA eventualmente tenga un impacto enorme en DevOps.

Podría ser que la automatización avanzada que pueden proporcionar las herramientas de IA y ML permita que muchos equipos se olviden por completo de las operaciones en DevOps. En esta utopía imaginada, las operaciones serán manejadas completamente por IA, y los desarrolladores serán libres de marcar el código para su lanzamiento sin tener que lidiar con las complejidades de implementarlo realmente.

Las herramientas de IA y ML ciertamente son prometedoras cuando se trata de eliminar el repetitivo “trabajo manual” de la administración de software, por eso ya es normal escuchar hablar sobre MLOps… pero lo dejaremos para otro artículo.

 

Nuestras cobnclusiones

 

Un cambio cultural y técnico hacia un enfoque DevSecOps ayuda a las empresas a abordar las amenazas de seguridad de manera más eficaz, en tiempo real. Es importante ver a los equipos de seguridad como un activo valioso que ayuda a prevenir ralentizaciones en lugar de un obstáculo para la agilidad. Por ejemplo, la detección temprana de una aplicación mal diseñada que no se puede escalar en la nube ahorra tiempo, recursos y costos informáticos valiosos.

La escalabilidad en la nube requiere la incorporación de controles de seguridad a mayor escala. Es necesario el modelado continuo de amenazas y la gestión de compilaciones de sistemas a medida que las empresas impulsadas por la tecnología evolucionan a un ritmo rápido.

Recomendamos la incorporación de estas estrategias y nos ofrecemos para apoyar y acompañar a las compañías en este proceso de adopción.

José Julián Ariza V.

José Julián Ariza V.

Technology professional with 20-years background in the industry focused on innovation and implementation of technological solutions for businesses and individuals.