Migración de plataforma a la nube

Byron McNaughtResponsable sénior de marketing de soluciones | F5

Los arquitectos ayudan a definir las directrices de los procesos y las capacidades técnicas necesarias para ejecutar la estrategia digital de la empresa, lo que a menudo implica transformar las aplicaciones web y la infraestructura de API —puertas de enlace de API, mallas de servicios y portales para desarrolladores— en plataformas basadas en la nube.

En la práctica, existen los enfoques de «migración directa», «refactorización» (o «rediseño de la arquitectura») y «migración de plataforma», y la decisión sobre qué estrategia arquitectónica seguir depende de varios factores. Por ejemplo, qué grado de acoplamiento y cohesión puede implementarse de forma segura. El objetivo debe ser una API con una alta cohesión y un bajo acoplamiento, ya que proporciona una interfaz estable y un nivel de abstracción que protegen al sistema del efecto en cascada de los cambios de implementación que, de otro modo, serían necesarios al realizar un único cambio de diseño. Esto permite que las distintas partes de la arquitectura evolucionen de forma independiente.

Descomponer una aplicación monolítica existente en microservicios y migrarla a la nube es una opción sensata para modernizarla, ya que este enfoque permite a los proveedores y consumidores de API evolucionar sus sistemas de forma más eficaz.

A continuación, analizaremos un caso práctico hipotético en el que una organización moderniza un sistema heredado mediante su refactorización en una arquitectura basada en API y su migración a una nueva plataforma en la nube.

Evolución hacia un sistema basado en API

¿Qué significa modernizar un sistema heredado? Un paso habitual en cualquier proceso de transformación digital es ofrecer los puntos de contacto adecuados para que los clientes puedan realizar transacciones, lo que, como mínimo, implica crear una aplicación móvil. Pero hay mucho más. En la nueva economía digital, la presión por reducir el tiempo de comercialización ha incrementado rápidamente el número de integraciones con terceros, ya que las organizaciones optan por «crear, tomar prestado o comprar» para ampliar su presencia digital y su base de clientes.

Si analizamos en detalle cómo se lleva a cabo la modernización en la práctica, vemos que implica tanto procesos como tecnología; en concreto, automatizar el despliegue y la mejora de los sistemas para permitir la entrega y la verificación continuas (procesos), y transformar las aplicaciones web heredadas hacia arquitecturas orientadas a servicios y basadas en API (tecnología). Además, una infraestructura de API, como una puerta de enlace de API, ayuda a garantizar un despliegue eficaz en un entorno de nube mediante sólidas funciones de gestión del tráfico y seguridad.

A continuación, analizamos un caso práctico hipotético de una iniciativa digital de este tipo, que consta de dos fases:

1. Rediseño de un sistema heredado y una aplicación monolítica para convertirlos en una arquitectura basada en API
2. Utilizar la infraestructura de API para transformar el sistema en una plataforma en la nube

En nuestro ejemplo hipotético, un sistema de conferencias permite realizar funciones como crear una cuenta de asistente (crear una cuenta), consultar las sesiones disponibles (consultar las sesiones) y reservar la asistencia (reservar sesiones). El cliente interactúa con el sistema de conferencias mediante un navegador web. Por ejemplo, para reservar una sesión de la conferencia:

Entre bastidores, el cliente interactúa con una aplicación web que envía llamadas a la API de la aplicación de conferencias. Esta aplicación utiliza SQL para consultar el almacén de datos del backend:

Varios requisitos están impulsando la necesidad de modernizar el sistema de conferencias heredado:

1. Compatibilidad con una aplicación móvil
2. Expansión del servicio a los mercados internacionales
3. Reducción de los costes operativos del centro de datos privado que aloja actualmente el sistema

Se elabora un plan de alto nivel:

1. Exponer el servicio Attendee a los consumidores mediante una puerta de enlace de API
2. Refactorizar la funcionalidad de Sesiones (ver/reservar) mediante una malla de servicios
3. Migrar el servicio de asistentes a la nube

Se están tomando medidas para refactorizar el componente Attendee y convertirlo en un servicio independiente. El sistema de conferencias cuenta ahora con dos interfaces de tráfico:

1. El cliente y el sistema de conferencias (Norte-Sur)
2. El sistema de conferencias y el sistema de asistentes (Este-Oeste)

A continuación, se implementa una puerta de enlace de API para facilitar una gestión del tráfico escalable, fácil de mantener y segura, que incluye la terminación SSL/TLS, la autenticación y la limitación de solicitudes:

A continuación, se aprovisiona una malla de servicios para reutilizar la funcionalidad de Sesiones del sistema de conferencias heredado en un nuevo servicio de Sesiones. Una malla de servicios permite controlar el enrutamiento de forma granular, garantiza la fiabilidad y gestiona de manera eficiente el tráfico de las comunicaciones mediante API entre servicios, lo que facilita la consulta y reserva de las sesiones de un asistente:

Por último, ha llegado el momento de migrar el servicio Attendee y la puerta de enlace de API a la nube. Este enfoque evita tener que rehacer gran parte del trabajo y, al mismo tiempo, permite aprovechar los servicios nativos de la nube a medida que la organización abandona su infraestructura local actual:

Para poner en práctica esta guía y modernizar tus aplicaciones heredadas, consulta el eBook Domina la arquitectura de API para conocer las mejores prácticas para evolucionar hacia sistemas basados en API.

Sobre el autor

Byron McNaughtResponsable sénior de marketing de soluciones | F5

Más artículos de Byron McNaught