Cómo iniciar DevOps: una guía paso a paso

DevOps puede ser una gran desviación del status quo de una organización de TI. Siga estos siete pasos básicos para una transición gradual que el personal defenderá.

por Will Kelly

---

Necesita un enfoque sistemático para DevOps. Las empresas deben crear una transición paso a paso a DevOps, no desechar todo lo antiguo y traer todo lo nuevo a la vez.

La mayoría de las empresas tienen desarrolladores de software y administradores de sistemas experimentados que comprenden el ciclo de vida del desarrollo de software y las operaciones de TI. Todavía necesitan ayuda para determinar cómo poner en marcha una iniciativa.

Los siete pasos clave para iniciar DevOps van desde una planificación cuidadosa y metódica hasta la selección de herramientas, la automatización, los proyectos piloto y las oportunidades de aprendizaje continuo.

1. Cree una hoja de ruta de transformación de DevOps

Para adoptar DevOps, cree una hoja de ruta. El plan debe trazar cómo comenzar con DevOps, en un formato paso a paso. Una hoja de ruta permite a una organización coreografiar sus acciones por adelantado.

Publique la hoja de ruta y la documentación adjunta en una ubicación central donde las partes interesadas y los miembros del equipo puedan acceder al contenido cuando lo deseen. Por ejemplo, use Microsoft PowerPoint o Google Slides para documentar la hoja de ruta y publicar esas diapositivas en la plataforma de colaboración de la empresa . Incluya suficientes detalles para que la hoja de ruta sea fácil de entender, incluso sin un presentador. Resista la tentación de enviar las diapositivas por correo electrónico para asegurarse de que la hoja de ruta no se pierda entre los últimos correos electrónicos de RR.HH.

Las partes interesadas pueden ver la hoja de ruta y hacer preguntas sobre su función en el proceso de ejecución de su proyecto. Los equipos de TI pueden ver los próximos pasos en la transformación a medida que realizan cambios. Todos tienen la oportunidad de hacer preguntas y proporcionar comentarios sobre la hoja de ruta. No hay secretos, lo que ayuda a sofocar los rumores.

Una hoja de ruta de transformación de DevOps no es un proyecto único. Esté preparado para actualizar e iterar en la hoja de ruta a medida que su organización avanza en su viaje DevOps.

2. Seleccione una cadena de herramientas de DevOps

Para iniciar DevOps es fundamental elegir una cadena de herramientas , pero es solo un paso. DevOps no se puede comprar, independientemente de lo que diga el vendedor de gestión de repositorios o software de automatización amigable. La selección de herramientas es esencial para tener en cuenta los requisitos de los desarrolladores, así como las integraciones y las pilas de tecnología.

La selección y composición de la cadena de herramientas de DevOps también incluye un ejercicio de licencia y seguridad. Para las cadenas de herramientas basadas en la nube, las organizaciones deben crear un modelo de distribución de sus gastos (y montos) en todos sus proveedores de herramientas y proveedores de servicios en la nube . Una cadena de herramientas de DevOps puede convertirse en un vector para ataques man-in-the-middle y similares. Involucrar al equipo de seguridad durante las fases de debida diligencia e implementación de la nueva cadena de herramientas.

Las organizaciones de TI deben adoptar un enfoque de proyecto piloto al seleccionar una cadena de herramientas DevOps, en la que los equipos internos trabajen con los proveedores de herramientas, y posiblemente incluso con una empresa de servicios profesionales, para implementar la combinación correcta de herramientas que satisfaga sus requisitos de entrega a través de la capacitación y luego una primer proyecto manejable.

3. Implementar herramientas y estrategias para la transformación cultural.

Hay cierta comodidad con el status quo para algunos tipos de personalidad de los desarrolladores. DevOps interrumpe algunas estructuras de poder organizativo y político a medida que los desarrolladores obtienen poder en el proceso de entrega. Para enfrentar estos desafíos, implemente herramientas y estrategias que fomenten la transformación cultural en las partes de la empresa que experimentarán la mayoría de los cambios.

Para implementar herramientas para la cultura DevOps, siga estos pasos:

1. Abra la nueva cadena de herramientas de DevOps a los equipos de desarrollo, operaciones y seguridad.
2. Brinde capacitación en DevOps a los equipos de desarrollo y operaciones para enseñarles las habilidades necesarias para usar la nueva cadena de herramientas.
3. Capture y defina una estrategia de colaboración entre desarrolladores, operaciones, QA y equipos de seguridad para flujos de trabajo.
4. Capacite a las partes interesadas y las unidades de negocio en conceptos de DevOps para que el personal fuera del departamento de TI aprenda nuevas formas de interactuar con el desarrollo y cualquier nueva expectativa que el desarrollo de productos les imponga.
5. Cree documentación de procesos internos que capture los procesos de DevOps y publíquela en un repositorio central, como una wiki, para actualizaciones fáciles.

4. Automatizar procesos

La perspectiva de la automatización puede dar miedo en algunos entornos corporativos. Para disipar este miedo, considere un enfoque transparente y por fases para la automatización de DevOps .

Establezca objetivos de automatización por prioridad. Automatizar todos los procesos a la vez no es realista ni factible, para ninguna organización. Por ejemplo, al comenzar con las pruebas automatizadas, concéntrese primero en las pruebas de software y luego automatice las pruebas de seguridad. Si bien las pruebas automatizadas no pueden reemplazar la experiencia de un evaluador humano, un enfoque por fases permite a las organizaciones demostrar cómo la automatización puede aumentar las capacidades del personal.

Este enfoque también permite a los administradores de TI trabajar directamente con los equipos que sentirán los cambios derivados de la automatización de sus tareas. Aproveche esta oportunidad para explicar el razonamiento empresarial y ayudarlos a adaptar sus deberes laborales a la automatización.

5. Centrarse en los datos y el análisis

Las herramientas modernas de DevOps permiten a los equipos de TI aprovechar los datos procesables de su cadena de herramientas. Aprovechar esos datos es fundamental para el éxito de DevOps porque altera la forma en que los equipos de TI se comunican con las partes interesadas y entre los departamentos.

Configure informes de panel para las partes interesadas para que los líderes del proyecto no tengan que generar informes de gestión manualmente. Presente a las partes interesadas los paneles y cómo enviar comentarios al equipo de DevOps sobre los datos que reciben. Una mentalidad de “tablero primero, luego preguntas” puede requerir algunos ajustes culturales menores, especialmente en la administración.

6. Ejecutar un proyecto piloto

Un proyecto piloto DevOps permite a los equipos y partes interesadas para llevar a sus nuevas herramientas y procesos para dar una vuelta en un proyecto pequeño. Una escuela de pensamiento típica es elegir un proyecto interno sin un cliente adjunto, para reducir el riesgo si algo sale mal: un cliente dispuesto (y que paga) por el proyecto aumenta las apuestas para el equipo y el proyecto. Por otro lado, con un cliente cooperativo como parte del proyecto, los equipos de DevOps pueden recibir comentarios de fuera de su organización.

7. Prepárese para el aprendizaje y la mejora continuos

No existe un último paso tradicional en el proceso de inicio de DevOps. Así como el software sigue un proceso de integración / entrega continua, también lo hacen los procesos y herramientas de DevOps. Con el tiempo, los equipos aprenderán lecciones sobre cómo hacer algo mejor. Esas lecciones deben encontrar su camino de regreso a la estrategia de la organización. Los nuevos miembros del personal aportarán nuevas perspectivas y experiencias de empleadores y proyectos anteriores. Inevitablemente, los equipos también querrán incorporar algunos de sus aprendizajes y experiencia en el marco de DevOps.

Fuente: https://searchitoperations.techtarget.com/tip/How-to-start-DevOps-A-step-by-step-guide

Elabore una hoja de ruta de transformación de DevOps en torno a estos 5 hitos

A medida que las organizaciones se embarcan en un viaje de DevOps, pueden usar estos cinco hitos para garantizar que los miembros del equipo se mantengan en el camino correcto y colaboren de manera eficiente en el camino.

por Will Kelly

La creación de una hoja de ruta de transformación de DevOps es un ejercicio tanto táctico como estratégico. Las organizaciones deben trazar un rumbo con hitos concretos que reflejen los objetivos comerciales y tecnológicos.

Más allá de los cambios en los procesos del día a día, DevOps hace que una organización sea más ágil en su respuesta a un mercado en evolución. Las pruebas de seguridad iterativas que se realizan como parte de una iniciativa de DevOps también ayudan a las organizaciones a alcanzar los objetivos de cumplimiento .

Sin embargo, un cambio a DevOps, así como la capacidad de medir el éxito y el progreso de ese cambio, requiere un plan formal. Y se necesita más que una presentación de PowerPoint con gráficos multicolores para comunicar ese plan de manera efectiva a las partes interesadas comerciales, técnicas y de seguridad .

Si bien los detalles de una hoja de ruta de transformación de DevOps variarán entre las organizaciones, considere estos cinco hitos para definir y medir el progreso hacia una cultura de DevOps.

1. El proyecto de lanzamiento

Una transformación de DevOps no será llave en mano. Comience con un pequeño proyecto piloto que permita a los administradores iterar en los procesos de administración, automatización, colaboración y entrega con una interrupción mínima para el negocio.

Para el primer proyecto, apunte a aprender el proceso DevOps y recopile comentarios continuos de los miembros del equipo involucrados. Si bien es tentador utilizar un proyecto interno de la empresa como primer esfuerzo de DevOps, vincular algunos dólares del presupuesto al proyecto para alentar a las personas de todos los niveles a tomar en serio la transformación.

2. El inicio de la toma de decisiones compartida

Este hito en una hoja de ruta de transformación de DevOps es donde comienza la toma de decisiones compartida entre las partes interesadas y los desarrolladores. También es donde los equipos realizan mejoras en la comunicación administrada y la colaboración entre los equipos de desarrollo y operaciones.

El trabajo comienza a evolucionar de la automatización en silos a una automatización de la infraestructura más centralizada. Sin embargo, los procesos aún no están estandarizados en toda la organización.

Los líderes de equipo y otros gerentes pueden necesitar trabajar con sus equipos durante esta fase para facilitar la colaboración y servir como mentores durante la toma de decisiones. Es posible que algunos gerentes tengan que ajustar su estilo de gestión para adaptarse a estas necesidades.

3. Colaboración y estandarización refinadas

En este hito, los equipos comienzan a experimentar la madurez de DevOps . Existen herramientas y procesos para respaldar la colaboración total entre el desarrollo, las operaciones y las partes interesadas del negocio. Los procesos, datos, prácticas de comunicación y relaciones comienzan a encajar para solidificar la toma de decisiones y la responsabilidad compartidas. Cualquier vestigio de mando y control de arriba hacia abajo en la organización de desarrollo debería desaparecer en este hito.

Otro signo de una organización DevOps madura es la aplicación de procesos automatizados a lo largo del ciclo de vida de la entrega. Estos esfuerzos de automatización deben basarse en el trabajo necesario para cumplir los dos hitos anteriores. Las unidades de negocio deben colaborar para estandarizar los procesos en toda la organización, de modo que todos trabajen desde el mismo manual de DevOps. Esto requerirá tanto documentación como capacitación interna.

Concéntrese en incorporar el conocimiento en la cadena de herramientas de DevOps. Por ejemplo, considere la posibilidad de capacitarse justo a tiempo o incorpore redactores técnicos para documentar los procesos y las herramientas y luego publique la documentación en un repositorio centralizado. Otra opción es enviar a los miembros del equipo a la formación de certificación de proveedores de DevOps o la nube.

¿Quién impulsa la transformación?

El soporte para DevOps debe provenir de todos los niveles de la empresa, desde los desarrolladores de primera línea hasta el nivel C-suite.

Los líderes de desarrollo y sus equipos deben tener objetivos para mejorar la entrega, la colaboración y la retroalimentación. Dependiendo de la cultura corporativa, las organizaciones pueden tener dificultades para cumplir los objetivos de colaboración, en particular. Designe campeones de DevOps en toda la empresa para vender esfuerzos al personal de negocios y tecnología.

El CISO y el CIO podrían obtener una ventaja de seguridad a medida que se mueven de Waterfall a DevOps, ya que este último permite el parcheo del sistema de forma iterativa. También obtienen más información sobre la seguridad y el cumplimiento de los sistemas de TI bajo su protección.

Los ejecutivos de nivel C, desarrollo empresarial y crecimiento corporativo quieren expandir el negocio de la compañía y ganar más dinero para servir mejor a sus accionistas y clientes. DevOps les brinda una herramienta para acortar los ciclos de lanzamiento y equipa a los ejecutivos de ventas con herramientas y procesos para ofrecer más funciones a los clientes.

4. La capacidad de medir el progreso

DevOps requiere que las organizaciones recopilen y analicen métricas que rastrean el progreso hacia los objetivos operativos y comerciales. En esta etapa de una hoja de ruta de transformación de DevOps, implemente herramientas y procesos para identificar cuellos de botella en el ciclo de vida de la entrega de software. El propósito de esta fase es ganar visibilidad y previsibilidad sobre la entrega para mejorar la calidad y el rendimiento.

La recopilación y medición de datos también significa asignar tiempo en los procesos de entrega para mejorar el trabajo diario. Los objetivos durante esta fase deben girar en torno a la repetición de la captura y medición de datos de la cadena de herramientas de DevOps. Más allá de eso, trabaje para informar a los desarrolladores y las partes interesadas para asegurarse de que las personas adecuadas obtengan los datos procesables que necesitan.

5. Operaciones y optimización continua

En esta etapa del viaje de DevOps, los equipos han alcanzado un nivel de intercambio de conocimientos efectivo. Los miembros del equipo se sienten capacitados para tomar decisiones. Las opciones de herramientas están en su lugar. Sin embargo, no es momento de detenerse. Utilice este hito para dedicar tiempo y tareas de proyecto para continuar refinando y optimizando el ciclo de vida, las operaciones y la ciberseguridad de DevOps.

Fuente: https://searchitoperations.techtarget.com/tip/Craft-a-DevOps-transformation-roadmap-around-these-5-milestones

Cómo Kubernetes mejora las prácticas de DevOps

Kubernetes no es necesario para DevOps y no necesita un equipo de DevOps para adoptar la administración de contenedores de Kubernetes. Pero, aquí están todas las formas en que estos dos son mejores juntos.

por Will Kelly

El uso de Kubernetes en una cadena de herramientas de DevOps permite la orquestación distribuida para administrar la infraestructura y las configuraciones de manera consistente en múltiples entornos.

La implementación automatizada de aplicaciones y el escalado a través de la administración de contenedores agrega resistencia operativa a la velocidad de las canalizaciones de DevOps. Este beneficio es más evidente para las organizaciones que ejecutan múltiples plataformas, como en las instalaciones y en la nube pública. Las prácticas de implementación variarían de una a otra sin una tecnología como Kubernetes.

A continuación, se muestra cómo el uso de Kubernetes beneficia a la cadena de herramientas de DevOps, desde la mejora de la automatización y la escalabilidad hasta las técnicas de implementación avanzadas. Pero tenga en cuenta los riesgos, como su complejidad y la escasez actual de personal que lo entienda.

Los beneficios que Kubernetes aporta a DevOps

Un marco Agile es fundamental para el ciclo de entrega de DevOps de la mayoría de las organizaciones . Kubernetes para orquestación distribuida se adapta bien a las prácticas ágiles. Kubernetes es una arquitectura orientada a servicios y un marco orientado a objetos, lo que le permite admitir principios ágiles .

DevOps generalmente cubre cada paso en el ciclo de vida de un software, desde la planificación y creación hasta la implementación y monitoreo.

Kubernetes minimiza las consideraciones de infraestructura para la entrega de DevOps al tiempo que mejora la automatización, la escalabilidad y la resistencia de las aplicaciones. El uso de métricas para guiar la implementación de Kubernetes puede formar parte de una estrategia general de análisis o AIOps para la aplicación. Los equipos de DevOps pueden establecer políticas de resiliencia y escalado a través de Kubernetes y dedicar menos tiempo a administrar estos factores manualmente en producción.

Kubernetes permite a los administradores implementar aplicaciones en cualquier lugar sin preocuparse por la infraestructura subyacente. Este nivel de abstracción es una gran ventaja para las empresas que ejecutan contenedores. Un contenedor siempre se ejecuta de la misma manera en Kubernetes. Por ejemplo, una organización puede implementar aplicaciones con el mismo nivel de control, ya sea que los contenedores se ejecuten en una nube para que los trabajadores remotos accedan a ellos o en la infraestructura local.

Kubernetes trata todo como código. Las capas de infraestructura y aplicación se escriben como instrucciones de configuración declarativas y portátiles y se almacenan en un repositorio. Kubernetes administra estos recursos de configuración como artefactos versionados. Con Kubernetes, un cambio de configuración, como una actualización de mantenimiento, se escribe en el código y se implementa, en lugar de implementarse manualmente. Esta configuración ahorra tiempo a los especialistas en operaciones porque ya no tienen que realizar estas tareas rutinarias.

Kubernetes también permite técnicas de implementación sofisticadas, como pruebas en producción y reversiones de versiones. Los desarrolladores pueden implementar un cambio de código rápidamente, un elemento clave de una estrategia de DevOps.

Dentro de Kubernetes

Kubernetes ejecuta contenedores a través de pods y nodos . Una vaina opera uno o más contenedores. Los pods pueden funcionar en múltiplos para escalar y resistir fallas. Los nodos ejecutan las vainas. Los nodos generalmente se agrupan en un clúster, abstrayendo los recursos de hardware físico, ya sea en un centro de datos propio o en una nube pública.

Kubernetes puede ejecutarse como una solución híbrida, en las instalaciones o en la nube. La ejecución de Kubernetes en la nube ayuda a los equipos de DevOps remotos porque es fácil colaborar allí.

Kubernetes es una tecnología de código abierto. Originalmente fue creado por Google, pero ahora es administrado por Cloud Native Computing Foundation. Debido a que la herramienta sigue los estándares de código abierto, puede integrarse con diversas cadenas de herramientas y otros servicios en uso para una canalización de DevOps. Por ejemplo, muchas organizaciones de DevOps dependen de una cadena de herramientas de CI / CD que mueve automáticamente el código de un paso del proceso al siguiente, incluida la contenedorización.

Kubernetes no cambia de contenedor mientras operan. La inmutabilidad , una característica clave de Kubernetes, es un beneficio porque permite a los administradores de TI detener, volver a implementar y reiniciar un contenedor sobre la marcha con un efecto mínimo en los servicios, excepto en el que ejecuta el contenedor.

Kubernetes admite gráficos de Helm , que son paquetes de Kubernetes reutilizables que describen los recursos necesarios. Los especialistas en operaciones pueden utilizar gráficos de Helm para implementar varios proyectos con las mismas aplicaciones personalizadas. Sin esta opción de gestión de recursos, los desarrolladores tendrían que personalizar el software para cada entorno.

Los riesgos de Kubernetes para los equipos de DevOps

Kubernetes es una tecnología compleja, que puede convertirla en un riesgo en sí misma. Si bien el uso de Kubernetes aumentó al 48% en 2020 desde el 27% en 2018, según el Informe VMware State of Kubernetes , todavía hay una escasez de talento de Kubernetes en los principales mercados laborales. Para integrar DevOps y Kubernetes, no solo cree proyectos piloto o de prueba de concepto de Kubernetes. Invertir en formación en tecnología.

Las organizaciones también deben adaptarse a la forma en que Kubernetes extrae los recursos para compartirlos entre las implementaciones de contenedores. La tenencia múltiple se suma a la complejidad de los desafíos de implementación de servicios. Cada entorno tiene sus propios requisitos y controles de seguridad. Si cada línea de negocio de una empresa requiere su propio clúster de Kubernetes y servicios de soporte, como seguridad, para que un inquilino no monopolice los recursos del clúster y perjudique el rendimiento de otros inquilinos, las operaciones administrarán múltiples configuraciones de Kubernetes. Otra preocupación es que cada inquilino solo puede acceder a sus respectivos servicios, incluidas métricas, registros y metadatos. Estos factores significan que Kubernetes en la vida real, implementaciones a escala es un desafío.

El uso de recursos subóptimo también es un riesgo. El diseño deficiente y las precipitaciones locas hacia la nube animan a los equipos de TI a dedicar subconjuntos de CPU, memoria, espacio en disco y recursos de red a cada servicio. Estos silos estimulan el aprovisionamiento excesivo para soportar la carga de trabajo máxima anticipada. El sobreaprovisionamiento también aumenta el gasto en la nube o desperdicia espacio en el hardware propio, lo que genera problemas de presupuesto.

El futuro de la cadena de herramientas de DevOps para la orquestación

La cadena de herramientas de DevOps se conoce desde hace mucho tiempo como un centro de automatización, ya sea a través de herramientas de CI / CD, implementación con script o una combinación de ambos. Sin embargo, la automatización es solo una parte de la historia de la orquestación distribuida. El futuro de las cadenas de herramientas de DevOps se centra más decididamente en los híbridos, y admite aplicaciones heredadas que aún se encuentran en centros de datos, aplicaciones existentes en la nube y aplicaciones recién migradas a la nube. Estas aplicaciones, a su vez, admitirán oficinas cada vez más híbridas y fuerzas de trabajo remotas, incluidos los equipos de DevOps, que exigen aplicaciones receptivas independientemente de su ubicación de trabajo.

Para que la cadena de herramientas de DevOps sea un punto de orquestación centralizado, combine:

• Kubernetes;
• automatización de los servicios de flujo de trabajo;
• recursos en la nube; y
• Prácticas de DevOps y herramientas de automatización.

Fuente: https://searchitoperations.techtarget.com/tip/How-Kubernetes-enhances-DevOps-practices