La Guía para Migrar a la nube con Integración

Para empezar, veamos algunas cifras interesantes: Gartner ha realizado un seguimiento del mercado IT durante muchos años, prediciendo que el doble de empresas utilizarían servicios en la nube en los últimos tres años. También registró que la cantidad total de dinero gastada en servicios en la nube se duplicó en el mismo periodo hasta alcanzar casi los 300.000 millones de euros al año. No obstante, la migración a la nube conlleva desafíos que hay que tener en cuenta. KPMG realizó una investigación hace un par de años en la que descubrió que el 54% de los Directores de IT afirmaban que la integración con el entorno existente era el mayor obstáculo para migrar a la nube. McKinsey preguntó recientemente a los CIO sobre sus proyectos de modernización de IT, en los que, evidentemente, la nube desempeña un papel importante. Descubrieron que el 80% de estos proyectos no han aportado la agilidad o los beneficios a nivel de negocio que se esperaban inicialmente. Entonces, si el cambio a la nube es tan difícil, ¿por qué las empresas lo llevan a cabo? ¿Y cómo es posible garantizar una mayor probabilidad de éxito?

En primer lugar, echemos un vistazo a las prioridades comunes de un CEO: no se enfocan en la tecnología, ni siquiera en la reducción de costes: de acuerdo con McKinsey, la principal prioridad de un CEO es el crecimiento de los ingresos, seguido de cerca por el aumento de la agilidad y la reducción del tiempo de comercialización. La mayoría de los CEO son conscientes de que la tecnología digital es un factor clave para lograr estos objetivos y esperan que los CIO de sus compañía contribuyan a alcanzarlos.

Sin embargo, en la mayoría de los casos, el CIO no puede permitirse el lujo de definir una nueva arquitectura moderna. Gastan hasta el 80% de su presupuesto anual en el mantenimiento de los sistemas existentes, lo que deja muy pocos recursos disponibles para la innovación. Los CIO con los que hablamos son conscientes de que la modernización del IT es necesaria, y de que las tecnologías en la nube deben formar parte de esa modernización. Sin embargo, a menudo resulta difícil saber por dónde empezar. ¿Qué opciones hay disponibles? ¿Y qué enfoque es el más adecuado para cada tipo de aplicación?

Veamos un par de modelos sencillos que te ayuden a estructurar el viaje a la nube de tu compañía. Básicamente, hay tres formas de trasladar las capacidades a la nube.

Arquitectura "tal cual"

En este caso, normalmente se toma una aplicación existente y se despliega tal cual en la Infrastructure-as-a-Service (o IaaS) en la nube. Este enfoque tiene múltiples ventajas: se consigue un traslado rápido a la nube. Además, el software ya no se ejecutará en un ordenador del datacenter que haya que operar, mantener, no habrá que hacer copias de seguridad ni actualizarlo. La principal desventaja es que se sigue tratando del mismo software y, por lo tanto, se sigue necesitando que se opere, parchee y depurarlo por su cuenta. Esta arquitectura "tal cual" no será flexible bajo presión ni tendrá alta disponibilidad.

Adopción del SaaS

La segunda opción consiste en adoptar las capacidades proporcionadas por una aplicación Software-as-a-Service o SaaS. Buenos ejemplos de ello son Salesforce, ServiceNow o Marketo. A medida que se traslada una función empresarial concreta a una aplicación SaaS, se puede desconectar o retirar una antigua aplicación on-premise. Las ventajas aquí son que las aplicaciones son nativas en la nube, con un pricing claro y sin esfuerzos operativos por tu parte. Como desventaja, hay que mencionar que estas aplicaciones SaaS a menudo son adoptadas también por la competencia, lo que significa que a veces no es posible establecer ventajas competitivas en cuanto al negocio con ellas.

Creación de soluciones nativas en la nube

La tercera opción consiste en crear aplicaciones nativas en la nube completamente nuevas utilizando las potentes capacidades que ofrece una platform-as-a-service (PaaS), como las pilas de AWS o Azure. Esto también te permitirá retirar aplicaciones on-premise obsoletas. Una ventaja clave de este enfoque es un time to market más rápido, lo cual facilita la innovación. Además, al crear aplicaciones desde cero, puedes aprovechar lo mejor las ventajas de los proveedores en la nube: por ejemplo, bases de datos as-a-service y un acceso fácil a almacenamiento de gran tamaño que pueden usarse como data lakes para su posterior análisis. Como desventajas, deberíamos citar el peligro de la dependencia de un proveedor específico y los costes, a menudo impredecibles, que además pueden dispararse si la solución no se diseña de forma cuidadosa.

Lo más probable es que tu empresa apueste por una mezcla de estos tres caminos. Pero, ¿qué enfoque es el más adecuado para cada tipo de aplicación? Pues bien, Gartner nos ofrece otro buen modelo que puede ayudarnos en este sentido: el llamado modelo pace-layer.

En la base están los sistemas de registro. Son los sistemas fundamentales que hacen funcionar la compañía: la contabilidad, el sistema de RRHH o tu sistema de gestión del stock, por ejemplo. Estos sistemas incluyen todos los datos corporativos esenciales, que están muy controlados y no registran cambios frecuentes. Ninguna empresa puede permitirse correr riesgos con estos sistemas, pero tampoco superará a la competencia específicamente con ellos. Son aplicaciones muy estandarizadas que todas las empresas utilizan, pero también suelen estar muy personalizados para adaptarse a las características específicas de cada empresa.

Los sistemas de diferenciación forman la siguiente capa. Son los sistemas que permiten a tu compañía hacer lo que mejor hace, más rápido y más barato que la competencia. Son los que le aportan la ventaja competitiva. Por su propia naturaleza, están hechos a medida y, por supuesto, tu empresa querrá que sean más ágiles y adaptables que los sistemas de registro.

En la cima están los sistemas de innovación. Facilitan el desembarco en nuevos mercados y canales, y llevan a tu empresa a lugares donde la competencia no está presente aún. Requieren de la máxima velocidad y agilidad para tener éxito.

Si combinamos estos dos modelos, será más fácil decidir cuándo utilizar una u otra vía de acceso a la nube.

Los sistemas de registro son el núcleo de tu empresa y los vincularás así de forma muy conservadora. Es probable que estos sistemas permanezcan on-premise, ya que son críticos para la compañía. Aquí hablamos de sistemas ERP muy personalizados o del mainframe que no se ha modificado en años, pero que funciona bien y mantiene sus funciones básicas operando correctamente. Tienes la posibilidad de desplazar esos sistemas o incluso reemplazarlos uno a uno por soluciones SaaS, pero dada su criticidad, esas migraciones deberían realizarse cuidadosamente y, por lo general, serían las últimas en llevarse a cabo.

Los sistemas de diferenciación y los sistemas de innovación también pueden trasladarse, pero lo más beneficioso sería aprovechar toda la potencia de las plataformas PaaS modernas: proporcionan elementos para el almacenamiento masivo de datos, analíticas, IA, frameworks de interfaz de usuario (UI) y mucho más.

En la vida real, la migración de las aplicaciones corporativas no se producirá de golpe, sino que habrá un escenario muy diverso de aplicaciones y tipos de alojamiento en cada momento. Muchos de los sistemas de registro permanecerán on-premise durante mucho tiempo, mientras que la empresa adoptará rápidamente aplicaciones SaaS nuevas y atractivas para satisfacer todas las nuevas necesidades que vayan surgiendo. Y, por último, cualquier nuevo sistema de innovación debería estar directamente en las plataformas en la nube. De este modo, la infraestructura estará parcialmente on-premise, parcialmente en VM en la nube, parcialmente en aplicaciones SaaS y, además, parcialmente en aplicaciones de nueva creación en la nube.

Independientemente de dónde esté alojado el entorno corporativo, la integración seguirá siendo la pieza central que una todas las dependencias de la empresa. La necesidad de integrar no ha hecho más que aumentar con la proliferación de las aplicaciones SaaS, los sensores y dispositivos IoT y el desarrollo de aplicaciones móviles. A esto hay que sumarle el gran número de sistemas de registro: sistemas mainframe, legacy y personalizados.

El software de integración de tu compañía debería conectar los datos de todos los entornos, abarcar todos los dominios y llegar a todos los endpoints. Cuando el software comienza a alojarse fuera del datacenter, la integración empieza a abarcar entornos on-premise de ERM, CRM y mainframe, así como entornos en la nube, SaaS, dispositivos y sensores periféricos y partners B2B. Muy pronto tu empresa tendrá la necesidad de modernizar el software de integración por las mismas razones por las que migró otras soluciones previamente: una necesidad de agilidad, solidez y reducción de los costes operativos. Dado que la integración no aporta valor por sí misma, sino que conecta aplicaciones, tu compañía tendrá que evaluar dónde residen los datos importantes; en otras palabras, dónde está el core de tus datos.

Dado que la finalidad de un software de integración es permitir la circulación de datos conectándolos y transformándolos, la carga de trabajo de integración, tiene que alinearse con dónde se encuentra el mayor volumen de datos. Si la mayoría de ellos siguen estando on-premise en ERPs y mainframes, trasladar la carga de trabajo de integración a la nube aportará, como es usual, beneficios operativos; no obstante, también aumentará la latencia entre los sistemas y hará más compleja la topología de red. Por otro lado, si tu empresa ya es una gran usuaria de software SaaS, como Salesforce o Workday, y aprovecha los data lakes de los hyperscalers (como AWS, Azure o Google) para almacenar todos los datos analíticos relevantes, entonces el core estará fuera de tu propio data center. En este caso, la migración de las cargas de trabajo de integración a la nube mejorará en gran medida la configuración global y la arquitectura de software.

Dado que en el mundo actual los datos pueden estar en cualquier parte (en el data center, en un hyperscaler de tu elección o en un SaaS), resulta obvio que una integración monolítica tipo "talla única" no se ajusta a las cargas de trabajo de la integración. Lo que se obtendrá es una dispersión de la arquitectura con flujos de integración independientes en función de las aplicaciones que deban conectarse. Estas son las opciones disponibles en esta nueva realidad.

Permanecer on-prem

Muchas organizaciones han resuelto desde el inicio el reto de la integración adoptando ESB (buses de servicios empresariales) y plataformas de integración, que se utilizan con frecuencia. En muchos casos, alimentan aplicaciones críticas para las organizaciones. Si las aplicaciones conectadas siguen estando en el datacenter, no tiene sentido trasladar las cargas de trabajo de integración a otro lugar sólo por los beneficios en costes operativos, ya que el mensaje subirá a la nube para volver al data center.

Realojar

Si los sistemas que se están integrando ya se han trasladado a la nube, es lógico que los workflows de integración también se trasladen. La forma más sencilla de conseguirlo es realojar las integraciones tal cual. Esto consiste en trasladar la arquitectura de integración a máquinas virtuales alojadas fuera del datacenter. Aunque se obtienen algunas ventajas operativas con este enfoque, esto no permitirá a tu compañía disponer de la escalabilidad y solidez de la nube y, por ello, tendrás que seguir siendo el encargado de la gestión del software.

Re-empaquetar

Otro tipo de realojamiento que puede permitirte aprovechar más la nube es el reempaquetado del software en contenedores. Los contenedores se utilizan como una forma de distribución empaquetada más estandarizada que contiene todas las dependencias necesarias y resulta mucho más ligera que una máquina virtual. Sólo reempaquetar el software como un contenedor, no permitirá a tu empresa obtener escalabilidad y alta disponibilidad, pero la movilidad del contenedor puede ayudarte a conseguir una migración más fácil: si un contenedor se ejecuta en el datacenter, se ejecutará de la misma manera en la nube.

Reempaquetar el software no es una tarea trivial que se resuelva con una instalación. Requerirá una remodelación completa de la forma en que se construye y opera una solución - desde un flujo CI/CD diferente hasta una nueva forma de monitorización y resolución de problemas.

Refactorizar

El reempaquetado en contenedores proporciona al software más movilidad y confianza mediante promoción, ya que todas las dependencias y herramientas se promueven con el código más reciente. Sin embargo, los contenedores por sí mismos no aportan una solución flexible que pueda actualizarse parcialmente sin tiempo de inactividad. Tampoco un time-to-market corto que permita lanzar nuevas ideas. Para lograr esos objetivos, tendrás que cambiar no solo la forma de empaquetar el software, sino también la arquitectura: un software monolítico no puede cumplir con los nuevos requisitos, por lo que debe modificarse en piezas más manejables que puedan funcionar de forma independiente como microservicios.

Los ESB están evolucionando desde que son considerados un monolito y las empresas están viendo así la necesidad de desplegar integraciones ligeras como microservicios. Esto ha llevado a la aparición de un tiempo de ejecución de microservicios (MSR) que se puede escalar muy rápidamente para satisfacer las necesidades de la empresa. Los MSR suelen desplegarse mediante contenedores, escalarse mediante un entorno de orquestación de contenedores como Kubernetes u OpenShift y, posteriormente, supervisarse mediante herramientas de código abierto como Prometheus. Esta arquitectura se basa en los principios del reempaquetado y conlleva grandes requisitos para las prácticas DevOps de tu empresa: será necesario automatizar completamente la promoción y el desarrollo/construcción/prueba/despliegue. Elegir esta opción también requiere disponer de conocimientos específicos y madurez en los procesos CI/CD por parte del equipo. Este enfoque puede considerarse la más difícil de todas las opciones, debido a los retos tecnológicos y operativos a los que se enfrentará tu compañía al adoptarlo.

Re-plataformar

Re-plataformar es aprovechar la plataforma de integración como servicio (iPaaS) para las cargas de trabajo. Se trata de una propuesta puramente en la nube que permite integraciones de nube a nube y de SaaS a SaaS fácilmente. Al utilizar la integración como SaaS, puedes olvidarte del aspecto operativo de esta capa de software: el software se actualizará automáticamente y podrá escalar bajo demanda. Es la opción natural a la hora de crear nuevas integraciones entre otros sistemas nativos de la nube o aplicaciones SaaS, y ofrece una gran cantidad de conectores y plantillas listos para este tipo de aplicaciones. Si las aplicaciones se trasladan a la nube, tiene sentido crear nuevos flujos de integración en el iPaaS para reemplazar el EBS on-premise.

Híbrido

Si las aplicaciones de tu compañía nunca volverán a alojarse en un único datacenter y siempre optas por un enfoque de integración híbrido en función de la criticidad del software o de las necesidades de innovación, las cargas de trabajo de integración estarán en línea con la arquitectura de datos y alinearán las aplicaciones lo más cerca posible en los diferentes entornos de alojamiento. Al final, tendrá una combinación de todas las opciones de integración mencionadas trabajando juntas de forma holística.

Ya hemos hablado de los factores que impulsan la migración del software a la nube, hacia dónde pueden encaminarse las aplicaciones, qué papel desempeña la integración en esta configuración y cuáles son las opciones de tu empresa con respecto a su coexistencia con el resto del entorno. Si estás leyendo este informe, eso quiere decir que probablemente ya estés inmerso en el viaje hacia la nube y te preguntes por dónde empezar en lo que respecta a la transformación en integración. Creemos que hay varios aspectos importantes que debes averiguar antes de empezar a trasladar las cargas de trabajo de integración fuera del datacenter. Para cada uno de estos aspectos, necesitas responder a algunas preguntas clave. Esta es la autoevaluación que todo el mundo debería hacer antes de marcar las acciones a seguir.

Visión: debes conocer cuáles son los factores que impulsan la migración dentro de tu compañía. Aunque esto puede variar según la empresa, hay varios motivos habituales: ¿ tu empresa está buscando una reducción de costes? ¿Más agilidad bajo presión? ¿Continuidad del negocio y solidez al realizar el mantenimiento? En cada uno de estos casos, debes buscar los beneficios a largo plazo e intentar alinearlos con los objetivos empresariales de la compañía.

Evaluación: ¿cuáles son los plazos que prevés para alcanzar los objetivos? ¿Has realizado un análisis del entorno de aplicaciones? ¿Has averiguado donde está el core?

Planificación: un buen número de clientes saltan directamente a esta fase limitándose a perseguir las últimas tendencias tecnológicas. Una vez hayas realizado las fases de visión y evaluación, tendrás una idea clara de qué estrategias de migración se adaptan mejor a determinados flujos de integración.

Ejecución: después de definir la visión y el plan para llevarla a cabo, hay que asegurarse de que se cuenta con las competencias y el tiempo necesarios para impulsar la transformación. No existe una ruta de migración perfecta ni un botón mágico para ejecutar el software desde la nube con una arquitectura moderna. Averigua cuál es la mejor forma de alcanzar los objetivos de tu empresa y define criterios cuantificables para medir su éxito.

Independientemente de dónde se trasladen las cargas de trabajo de integración, elegir cuidadosamente una estrategia de API que te ayude a modernizar fácilmente el entorno siempre es un buen primer paso. Si ya conoces el "core" de las cargas de trabajo de integración, a continuación podrás averiguar qué opciones se adaptan mejor a él. Nuestra recomendación es empezar con quick wins: el realojamiento ‘tal cual’ es una buena opción y te permitirá hacerte una idea de lo que significa operar en la nube. Puedes hacer un seguimiento de los costes operativos y de funcionamiento, así como vigilar cualquier problema oculto que pueda salir a la luz: topologías de red, aspectos legales relacionados con tus datos, lagunas de conocimiento en tu organización y muchos otros.

El siguiente quick win puede ser la replanificación, sobre todo si empiezas a crear integraciones entre aplicaciones SaaS totalmente nuevas. webMethods.io simplifica la creación de esos flujos de trabajo con una buena experiencia de usuario y reglas preparadas para muchos sistemas modernos.

Mientras tanto, tu organización puede adquirir gradualmente las habilidades para implementar y desplegar microservicios de integración en un entorno de orquestación de contenedores.

Como acabarás teniendo muchas integraciones diferentes, tendrás que prepararte para gestionar todas de forma escalable.