Rediseñando para una innovación ininterrumpida

Numerosas empresas construyen sus propios servicios de software empleando arquitecturas monolíticas.

Esta estrategia tiene ventajas: diseñar e implementar sistemas monolíticos suele ser sencillo al principio. A medida que las aplicaciones se vuelven cada vez más sofisticadas, puede resultar difícil mantener la productividad de los desarrolladores y la velocidad de implementación, lo que da como resultado sistemas cuya implementación es costosa, requiere mucho tiempo y es peligrosa. Este documento demuestra cómo rediseñar sus aplicaciones para un paradigma nativo de la nube que le permita acelerar la entrega de nuevas funciones incluso cuando sus equipos se expanden, al mismo tiempo que aumenta la calidad del software y logra mayores niveles de confiabilidad y disponibilidad.

A medida que los servicios y los equipos responsables de ellos se expanden, tienden a volverse más difíciles de adaptar y administrar, así como más complicados. Se vuelve más difícil realizar pruebas e implementaciones, agregar nuevas funciones y mantener la estabilidad y la disponibilidad.

Según una investigación realizada por el equipo DORA de Google, es posible que empresas de todos los tamaños y en todas las disciplinas alcancen altos niveles de rendimiento en la entrega de software, estabilidad del servicio y disponibilidad del servicio. Los equipos de alto rendimiento pueden implementar varias veces al día, entregar cambios a producción en menos de un día, restaurar el servicio en menos de una hora y lograr tasas de fallas de cambio de entre el 0 y el 15 %.

Además, los grandes trabajadores pueden mejorar la productividad de los desarrolladores, medida según la cantidad de implementaciones por desarrollador por día, incluso mientras amplían sus equipos.

¿Qué es una arquitectura de nube nativa?

La creación, prueba e implementación de aplicaciones monolíticas debe realizarse como una sola entidad. Con frecuencia, el sistema operativo, el middleware y la pila de lenguajes de una aplicación se modifican o configuran individualmente. Los scripts y procedimientos para el desarrollo, prueba e implementación de aplicaciones suelen ser exclusivos de cada aplicación. Esto es sencillo y eficaz para aplicaciones nuevas, pero a medida que estos sistemas se expanden, se vuelve más difícil modificarlos, probarlos, implementarlos y ejecutarlos.

Además, a medida que los sistemas se expanden, también lo hacen la cantidad y la complejidad de los equipos responsables de desarrollar, probar, implementar y operar el servicio. Es común, pero erróneo, dividir a los equipos por función, lo que da como resultado transferencias entre equipos que aumentan los plazos de entrega y los tamaños de los lotes y dan como resultado una considerable repetición del trabajo. La investigación realizada por DORA indica que los equipos de alto rendimiento tienen el doble de probabilidades de crear e implementar software que un solo equipo multifuncional.

Entre los síntomas de esta condición se encuentran:

• Procesos de construcción largos y frecuentemente interrumpidos
• Ciclos de prueba e integración poco frecuentes
• Se requiere un mayor esfuerzo para respaldar los procesos de construcción y prueba
• Disminución de la productividad del desarrollador
• Procesos de implementación dolorosos que deben realizarse fuera del horario comercial, lo que requiere un tiempo de inactividad programado
• Esfuerzo considerable en la gestión de la configuración de los entornos de prueba y producción.

Transición a la nube nativa

Numerosas empresas han implementado una metodología “lift-and-shift” para migrar sus servicios a la nube.

En este método no son necesarias pequeñas modificaciones del sistema y la nube se maneja esencialmente como un centro de datos convencional, aunque uno que ofrece API, servicios y herramientas de administración muy superiores a los de los centros de datos convencionales.

Sin embargo, el modelo lift-and-shift por sí solo no ofrece ninguna de las ventajas del modelo nativo de la nube comentado anteriormente.

Debido al costo y la dificultad de la transición de sus aplicaciones a una arquitectura nativa de la nube, que incluye replantear todo, desde el diseño de la aplicación hasta las operaciones de producción y todo el ciclo de vida de la entrega del software, muchas empresas se detienen en la fase de "lift and shift". Esta aprensión está justificada: varias grandes corporaciones han llevado a cabo iniciativas de reestructuración de plataformas de "big bang" que han durado varios años y que no han tenido éxito.

La respuesta es adoptar un enfoque progresivo, iterativo y evolutivo para rediseñar sus sistemas para que sean nativos de la nube, lo que permite que los equipos aprendan a operar con éxito en este nuevo paradigma mientras continúan produciendo nuevas funcionalidades: esta es una estrategia de "moverse y mejorar".

La aplicación de la higuera estranguladora es un motivo destacado en la arquitectura evolutiva. En lugar de reconstruir los sistemas desde cero, se deben desarrollar nuevas funciones de una manera contemporánea y nativa de la nube, pero hacer que se comuniquen con el antiguo programa monolítico para la funcionalidad existente. Se debe cambiar la funcionalidad actual gradualmente con el tiempo, según sea necesario para la integridad conceptual de los nuevos servicios.

Descargue el informe técnico de Google Cloud para obtener más información sobre la reestructuración para una innovación continua, solo en Whitepapers Online.