DevOps en el mundo de la nube nativa: colisionan dos de los términos más importantes de la tecnología

¿Cómo luce DevOps para el desarrollo nativo de la nube?

DevOps es el más antiguo de los dos y ha sido popular durante más de una década. Pero su antigüedad no necesariamente ha aportado claridad a lo que en verdad significa y es en la práctica. Por lógica, si agregamos lo más nuevo, que incluso se entiende menos, la nube nativa y la confusión aumentan.

Es probable que, por este motivo, nos hayamos dado cuenta de que, sin un punto de inicio acordado en lo que respecta a las definiciones, estas conversaciones pueden desviarse del tema. Antes de analizar cómo funcionan juntos, necesitamos establecer lo que significan o lo que no.

Comencemos por DevOps. DevOps no es un servicio, un producto ni un puesto de trabajo. Es un modelo operativo que combina las funciones de desarrollo e infraestructura en equipos multifuncionales, facultados por la automatización y coordinados por metodologías ágiles. Luego, a un alto nivel, el desarrollo “nativo de la nube” significa crear módulos en su pila de aplicaciones y aprovechar los microservicios para crear una arquitectura sin servidor y optimizar los recursos. Se trata de desarrollar o modernizar aplicaciones para aprovechar y maximizar los atributos más importantes del cómputo en la nube en torno a la escalabilidad, la confiabilidad y la automatización.

Y aquí es donde se unen DevOps y la nube nativa. Porque lo que es moderno y nativo de la nube hoy puede no serlo en cinco años. Los hiperescaladores presentan nuevos servicios todo el tiempo y la tecnología avanza rápido.

DevOps bien hecho le permite mejorar constantemente la forma en que desarrolla sus aplicaciones y sus equipos, lo que lo mantiene a la par con las nuevas tecnologías casi a medida que surgen.

Hay tres requisitos en el camino hacia un verdadero estado de DevOps

Alcanzar un verdadero estado de DevOps, sobre todo cuando también se trata de usar los servicios de la nube nativa, es emprender un recorrido. Y, probablemente, se trate de uno largo. Pero hay tres requisitos que vemos que confluyen una y otra vez para formar las bases del éxito.

Primero, necesita dejar de lado toda idea equivocada sobre la naturaleza de DevOps y cómo se implementa. Las empresas no crean un equipo de DevOps ni compran una solución de proveedores y automatizan de inmediato sus procesos. Quitan los silos y las barreras entre los equipos para combinar disciplinas y así posibilitar una compresión y un propósito compartidos. Para comenzar a adoptar realmente DevOps y las metodologías ágiles relacionadas dentro de su desarrollo nativo de la nube, cada uno de estos equipos debe tener habilidades que le permitan asumir la responsabilidad total de su parte del producto o servicio.

En segundo lugar, debe contar con todas las partes interesadas adecuadas desde el comienzo de su recorrido. A menudo, una parte interesada influyente ha escuchado “DevOps” en una presentación y, cuando regresa a la oficina, dice “desde ahora hacemos DevOps”. Ese entusiasmo es estupendo, pero si no involucra a la gente correcta, es decir, a aquellos que lideran los equipos de desarrollo, de aplicaciones, de bases de datos y de infraestructura, entonces el comienzo va a ser difícil.

Por último, permita que los programadores y los propietarios de las aplicaciones impulsen los requisitos de arquitectura. Ellos sabrán qué tecnologías necesitan y qué necesitan en su pila de aplicaciones para realizar la implementación. Sin embargo, los equipos de infraestructura deberían orientarlos para que adopten PaaS y SaaS por defecto. Muchas veces, los equipos llegan aquí desde un lugar en el que usan instancias y VM. Pero si alguien quiere una VM, o una base de datos Mongo o Redis, entonces en un mundo de DevOps, el equipo de infraestructura debe encontrar y recomendar los reemplazos nativos de la nube. (Si después de haber investigado o a medida que surgen necesidades de desarrollo adicionales, necesita volver a las VM, en ese caso está bien).

¿Cómo luce el verdadero DevOps para el desarrollo nativo de la nube cuando las empresas realizan nuevos lanzamientos?

Lo primero que hay que decir sobre los lanzamientos o las nuevas versiones con DevOps en el mundo nativo de la nube es que, si tiene éxito al combinar las dos cosas, entonces esas implementaciones importantes ya no se verán como eventos esenciales reales. Ha eliminado las dificultades, lo ha logrado gradualmente y el día del lanzamiento es solo la pieza final del rompecabezas. Llegar a eso, es liberador.

En las etapas finales, cuando se enfrente a esa fecha de lanzamiento, la máquina que haya desarrollado estará en plena actividad a medida que incorpore a cada equipo justo a tiempo para preparar la prueba de carga para el lanzamiento. Y eso funciona porque ha estado meses (y quizás más) trabajando en un plan en el que todos comprenden qué se necesita y cuándo, en términos de establecer el ambiente de desarrollo en X punto en el tiempo, la infraestructura en Y, para alcanzar el objetivo Z.

Es una sinfonía. La gente necesita saber su parte, cuándo debe actuar y cómo contribuye al contexto general. Cuando funciona, es hermoso. Cuando no, es discordante.

Cómo llegar: ¿es mejor asociarse o hacerlo solo?

Si está adoptando DevOps y la nube nativa asociándose con un tercero, debe encontrar personal del proveedor y capacidades que complementen y mejoren lo que ya tiene. Esto es clave: usted quiere complementar las habilidades que coinciden con su modelo operativo para crear esos equipos multifuncionales, no quiere generar dependencia con las partes externas. Por lo tanto, si tiene un equipo sólido de desarrollo y productos, pero necesita ayuda con la infraestructura, su socio debe integrarse como una extensión de ese equipo (en lugar de ser ese equipo). Esto se denomina enfoque de “trabajo en conjunto”.

Cuando lo haga solo, comience de a poco y repita el proceso. Habrá mucha deuda técnica por resolver y mucho aprendizaje sobre ambas cuestiones, por lo que se necesitará paciencia. Pero puede experimentar esa sensación ganadora desde el principio, al elegir primero lo que esté más al alcance y usarlo como una oportunidad para trabajar con las herramientas y hacer que todos se acostumbren a convivir. Eso podría significar automatizar un aspecto muy específico de la implementación, o considerar las necesidades comerciales con respecto a la disponibilidad, los respaldos y el monitoreo y planificar el primer proyecto a partir de eso.

El aprendizaje nunca se realiza con DevOps y la nube nativa, así que empiece ahora (o pronto, al menos)

Esto es un viaje y el destino no es un lugar fijo; siempre hay más por descubrir o nuevos desafíos por solucionar al establecer o mantener las capacidades de DevOps.

Las organizaciones en las primeras etapas de DevOps a menudo se enfrentan con los puntos débiles de la TI tradicional, como los costos altos, la subutilización de instancias y los problemas de disponibilidad. Pero al intentar resolver estos problemas de forma retroactiva, descubren que es mucho más difícil regresar y solucionarlos que lo que es considerarlos desde el principio. Por otro lado, las empresas en la última etapa de DevOps han demostrado ser ágiles y han logrado que sus equipos se comuniquen; tienen amplias capacidades en ambas cuestiones y una comprensión madura de su pila y sus herramientas. Sin embargo, siempre es posible optimizar los costos y el rendimiento.

Pero las empresas en la etapa inicial tienen más que aprender, por supuesto. Por lo tanto, vamos a concluir con los mejores consejos para los líderes en tecnología cuando se trata de comenzar su recorrido hacia DevOps y la nube nativa.

1. Sea cauto y tenga un propósito en lo que respecta a las herramientas y las normas que elige al empezar para estar seguro de evitar una futura deuda técnica. Hay muchas opciones disponibles y es fácil seguir agregándolas indefinidamente a su cadena de herramientas.
2. Entienda el lugar en el que se encuentra en su recorrido hacia la madurez de la nube y DevOps, y cree un plan para reparar cualquier problema primero. Pregúntese: ¿sigue considerando la nube solo como un lugar donde están sus instancias EC2 o sus VM? ¿O es solo el lugar donde se encuentran sus aplicaciones? ¿Cómo están estructurados sus equipos? ¿Se complementan entre sí o se ponen trabas?
3. Comience lo antes posible. La tecnología de la nube evoluciona todo el tiempo y cuanto más espere, mayor será la brecha por superar.

Join the Conversation: Find Solve on Twitter and LinkedIn, or follow along via RSS.

Stay on top of what's next in technology

Learn about tech trends, innovations and how technologists are working today.