DevOps: desarrollo y operaciones

Desarrollo y entrega de soluciones

En los primeros días, las soluciones se asociaban con la correcta tecnología. La clave era la tecnología, la solución era la tecnología y el negocio esperaba y pagaba por la tecnología. Los tiempos han cambiado. Bueno, al menos para aquellos de nosotros que lo notamos. Hoy en día, la tecnología casi nunca es un problema importante. Técnicamente, tenemos un mundo menos complicado. A lo largo de los años, hemos llegado a comprender que la tecnología es básicamente una disposición de procesamiento, memoria, redes y almacenamiento. Hemos dominado la utilización mediante la virtualización. Entendemos que la escala horizontal es «mejor» que la escala vertical y que podemos entregar el PMNS más fácilmente en productos convergentes e hiperconvergentes que también contienen la solución de software. Hemos automatizado muchas de las actividades clave para permitir la reducción de tiempo y costos.

El paradigma de la nube apareció y nos facilitó la vida al ayudarnos a convertirnos en agentes de servicios en lugar de administradores de servidores o ingenieros de redes. Para el cliente, ahora somos Service Brokers; bueno, deberíamos estarlo. Deberíamos estar experimentando ciclos de adquisición más cortos dado que las aplicaciones y los servicios (las soluciones) se entregan desde un catálogo de servicios. Aunque esto puede ser cierto en el modelo de implementación de nube pública y el modelo de entrega de software como servicio (SaaS), cuando se trata de adquisiciones de nube privada, parece que todavía estamos estancados en el pasado y sufrimos retrasos innecesarios. A pesar de que cada vez son más las empresas que utilizan los servicios de nube pública, la actividad de poner los servidores, las aplicaciones y los servicios «allí arriba» sigue siendo difícil. Todo el trabajo que se requiere para diseñar y entregar un entorno alojado en la nube pública todavía está impregnado de prácticas de trabajo anticuadas.

A pesar de todo este cambio y aprendizaje, el diseño y la implementación de la solución sigue siendo un trabajo espinoso y produce montañas de documentación (algunas necesarias, otras inútiles), diagramas de Gant interminables y reuniones interminables que intentan poner la solución en su lugar y entregarla. ¿Por qué es esto?

Desarrollo y entrega de aplicaciones

Los desarrolladores de aplicaciones suelen vivir en un mundo propio. Hasta cierto punto, eso sigue siendo cierto. Las empresas de desarrollo de aplicaciones no suelen tener ingenieros de redes, arquitectos técnicos y pymes de almacenamiento en los scrums matutinos. Las aplicaciones se desarrollan de forma aislada y separada de las soluciones técnicas que deberán crearse para alojar, proporcionar recursos y dar soporte a la aplicación.

En la mayoría de los casos, una aplicación se desarrolla por una de dos razones. Proporcionar una solución para un cliente externo o proporcionar una aplicación para el negocio con la que pueda ganar dinero. Por ejemplo, una empresa debe pagar salarios. Para hacer eso, necesita una aplicación que pueda pagar los salarios, calcular la información de impuestos y pensiones e ingresar datos en una base de datos y luego imprimir un recibo de pago, todo de acuerdo con el marco legal establecido en las ‘reglas de compromiso’ de los Servicios de Ingresos. Una empresa de desarrollo de aplicaciones asumirá ese desafío y, a través de una serie de iteraciones, entregará una aplicación que cumpla con todos los requisitos legislativos y del cliente. Para una empresa que quiere ganar dinero con una aplicación, el escenario es muy similar al de un cliente externo. La diferencia es financiera en que la empresa tiene que justificar el costo de tener desarrolladores en el personal que crea la aplicación. Ese costo se compara con una previsión de ingresos por el eventual despliegue de la aplicación como servicio para la empresa.

En ambos ejemplos hay constantes que pueden dificultar la marcha. De la misma manera que las soluciones técnicas se ven afectadas por las personas, los procesos y la política, el desarrollo de aplicaciones se ve afectado por una práctica aislacionista. ¿Por qué es esto?

¿Por qué es esto?

En toda la TI, desde la infraestructura del centro de datos hasta las aplicaciones y la nube, existe un problema que afecta la ejecución fluida y conjunta de un proyecto y son los «silos de actividad».

El silo ha sido durante mucho tiempo la marca negra de la tecnología de la información. Nos acostumbramos tanto a operar en silos que no nos cuestionamos si tal arreglo era productivo y rentable. De hecho, incluso ahora, la mayoría de las organizaciones de TI operan utilizando silos. Solución y desarrollo de forma aislada.

El diseño de soluciones y el desarrollo de aplicaciones vieron la llegada de Lean and Agile como una forma realmente efectiva de operar y, sin embargo, los silos permanecieron. Las empresas operaban de forma ágil, pero mantenían la forma de hacer las cosas en silos. Extraño cuando lo piensas. Ágil significa flexible y capaz de cambiar sin traumas. Silo es un ‘pozo’ con lados altos que dificultan mucho el cambio. Entonces, en esencia, Agile y silo trabajaron juntos y dificultaron el cambio. Todavía lo hace.

Silo

A continuación, se muestra un ejemplo del mundo real de un entorno de TI tradicional basado en silos en el que se va a desarrollar e implementar una aplicación. El proceso puede diferir ligeramente en algunas empresas y los títulos de los puestos pueden no ser los mismos, pero esta ha sido mi experiencia trabajando para varias grandes corporaciones de TI y es reconocible como un procedimiento bastante común.

El desarrollador de aplicaciones crea una aplicación a partir de un concepto o de una solicitud. Se solicita a un arquitecto de servicios técnicos (TS) que cree un diseño de alto nivel (HLD) para la infraestructura de la aplicación. El TS Architect pasa el DAN al Arquitecto del Proyecto para que revise el diseño. El arquitecto del proyecto devuelve el DAN final al arquitecto TS. El TS Architect explica el diseño al desarrollador de la aplicación y cubre cualquier elemento que pueda comprometer la aplicación. Por lo general, esto se hace en forma aislada de otros expertos. El HLD se firma por alguien u otro y el arquitecto del proyecto se propone llevar a cabo una actividad de diligencia debida antes de crear el diseño de bajo nivel (LLD o Build Doc) para la infraestructura de la aplicación. El arquitecto del proyecto tiene que visitar varios expertos en la materia (PYMES) para cómputo, redes, almacenamiento y recuperación ante desastres (DR) para averiguar qué tecnologías y requisitos deberán estar en el LLD. Los detalles sobre protocolos, enrutamiento, seguridad y reglas de firewall pueden ser complejos y pueden afectar negativamente a la aplicación si no se planifican cuidadosamente. Para hacerlo bien, es necesario consultar a un experto en Análisis de impacto empresarial para asegurarse de que los problemas de seguridad y cumplimiento, si existen, se puedan tratar o mitigar. La mayoría de las aplicaciones se implementan en infraestructuras virtuales que requieren la participación de expertos en virtualización para ayudar a las tecnologías de aprovisionamiento y automatización. Con todo, el arquitecto de proyectos tiene que consultar con muchos silos diferentes de tecnología / expertos. En el curso de esta actividad, el Arquitecto tiene que regresar constantemente al desarrollador de la aplicación para verificar que lo que se está planificando para la infraestructura no «dañará» el diseño de la aplicación y hará que la aplicación sea ineficaz cuando se implemente. Por último, es necesario implementar el Service Wrap para respaldar la aplicación y cumplir con los requisitos no funcionales de los Acuerdos de nivel de servicio (SLA). Fácilmente podría haber veinte personas involucradas en este proceso. No he incluido la prueba y el desarrollo, ya que esto suele esperar hasta el final del proceso principal junto con las pruebas de aceptación del usuario (UAT). A veces hay un equipo separado que se encarga de esta parte, a veces lo lleva a cabo Operaciones. El diseño de la aplicación también incluye los niveles de dependencia que proporcionan las capas de middleware y base de datos. Es posible que sea necesario involucrar a muchas más personas cuando se incluyan esos servicios. Lo cierto es que cada pyme forma parte de un silo. El proyecto tiene que consultar todos estos silos. Algunas son útiles, otras no y hay muchas razones por las que ¡No! puede ser la respuesta a todas las preguntas y soluciones sugeridas.

Todos los silos y todas las personas involucradas hacen que todo el proyecto sea lento y costoso. La analogía es el juego de serpientes y escaleras.

DevOps

Aunque el ejemplo anterior es algo burdo, es una evaluación justa de cómo puede ser el desarrollo de aplicaciones de un extremo a otro. Todos en la industria saben que este es el estado de cosas «normal» y aceptan que no es perfecto. DevOps ha comenzado a aparecer en escena como la respuesta al enfoque tradicional de silos. DevOps intenta eliminar los silos y reemplazarlos con una actividad colaborativa e inclusiva que es el Proyecto. El desarrollo de aplicaciones y el diseño de soluciones se benefician de los principios de DevOps.

Qué se debe hacer para eliminar los silos:

  • Cambiar la cultura laboral

  • Quita las paredes entre equipos (y quitas los silos)

Llaves:

  • Comunicación, colaboración, integración e intercambio de información

Fácil de decir y difícil de hacer.

A la mayoría de las PYME les gusta guardar su información para sí mismas. No es cierto para todos, pero sí para muchos. Es parte de la cultura tradicional que se ha desarrollado durante muchos años. Las prácticas laborales han dificultado el cambio. La gestión del cambio es una de las tareas más desafiantes en las que puede embarcarse cualquier empresa. La resistencia será resistente, ya que es importante que las personas renuncien a algo para ganar algo. Es imperativo dejar en claro cuáles son las ganancias. La gente cambiará sus actitudes y comportamientos, pero tienes que darles muy buenas razones para hacerlo. Descubrí que la realización de talleres multidisciplinarios para las PYME ha demostrado ser un método eficaz para fomentar el intercambio de información y la eliminación de esos «muros de pozo».

Explicar a los equipos qué es DevOps y qué se supone que debe lograr es la primera parte del proceso educativo. El segundo es lo que hay que hacer.

Establezca objetivos mensurables específicos:

  • Implementar una estructura organizativa que sea «plana». Si apoyamos la escala horizontal, ¿por qué no las organizaciones horizontales?

  • Cada App-Dev o Solution-Dev es un proyecto y el equipo es integral en todas las disciplinas.

  • Implementar intercambios y revisiones de información continuos

  • Asegúrese de que todos se registren en DevOps y comprendan el paradigma

Que es DevOps

Al igual que el paradigma de la nube, es simplemente otra forma de hacer algo. Al igual que Cloud, tiene diferentes definiciones dependiendo de con quién se esté hablando en ese momento.

Wikipedia dice: Debido a que DevOps es un cambio cultural y una colaboración entre el desarrollo y las operaciones, no existe una única herramienta DevOps, sino un conjunto o «cadena de herramientas» que consta de múltiples herramientas. Generalmente, las herramientas de DevOps encajan en una o más categorías, lo que refleja el proceso de desarrollo y entrega de software.

No creo que esto sea todo lo que es DevOps. La inferencia es que DevOps se ocupa solo del desarrollo y las operaciones de aplicaciones. No creo eso. Creo que DevOps es un paradigma y que, al igual que otros ‘estándares’ y paradigmas de TI, es relevante para todas las TI y no solo para las aplicaciones. Al eliminar las particiones entre cada práctica en la cadena y tener a todos los actores clave involucrados desde el primer día, como parte de un equipo inclusivo y colaborativo, el ciclo de desarrollo de aplicaciones y diseño de soluciones se convierte en un proceso continuo que no tiene que desviarse hacia consulte a cada experto requerido. Nadie necesita arrojar un documento por la pared al siguiente equipo. Cada documento está escrito dentro del proceso de colaboración y esto tiene que hacer que el documento sea más relevante y poderoso. Imagine que el equipo del proyecto está siempre en la misma sala desde el concepto hasta la implementación y que cada experto siempre está disponible para comentar y agregar a cada paso de ese proyecto. Cuánto mejor que el método tradicional, donde puede llevar días obtener una respuesta a una pregunta simple, o incluso encontrar a la persona adecuada para preguntar.

El mantra es: desarrollar, probar, implementar, monitorear, retroalimentar, etc. Esto suena orientado a la aplicación. De hecho, puede aplicarse al desarrollo de cualquier solución de TI. Al igual que ITIL, TOGAF y el modelo de referencia de siete capas, se puede aplicar a todas y cada una de las actividades de TI, desde el desarrollo hasta los servicios de soporte. DevOps nos pone a todos en la misma página desde el principio hasta el final.

No permita que su empresa implemente DevOps de forma aislada y solo como un marco para el desarrollo de aplicaciones. Hacer eso sería crear otro silo. Úselo para cada proyecto y como cultura predeterminada para todos sus equipos, sean o no desarrolladores, ingenieros, arquitectos u operaciones. Y, finalmente, no lo compliques. DevOps no necesita definiciones profundas y profundas o conversaciones largas y tediosas sobre qué es y cómo implementarlo. Solo hazlo.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)
Abrir chat