Perfomance en escenarios de migración OnPremise a entornos híbridos Cloud/OnPremise



Está fuera de lugar cuestionar la utilidad de un Cloud en cuanto la versatilidad y la rapidez con la que crear toda una infraestructura empresarial compleja desde cero, pero si que me atrevería a decir, que no está fuera de lugar cuestionarnos si bajo cualquier escenario es válido el uso de un Cloud.

Si hablamos de montar toda una infraestructura empresarial toda ella en Cloud, seguramente sería de aquellos que se lanzarían a la piscina sin pensármelo mucho. Normalmente, el tiempo de arranque de una infraestructura onPremise acostumbra a ser lento y más aún como más grande es la empresa.

Si hablamos de migrar una parte de una infraestructura OnPremise al Cloud y mantener la otra parte tal como se encuentra, seguramente también me lanzaría a la piscina pero no con el ímpetu del escenario anteriormente comentado y es aquí donde se inicia el debate de este post.

Un escenario híbrido Cloud/OnPremise me atrevería a decir que es donde tiene más encaje en empresas grandes dado que el core empresarial se sustenta en sistemas que llevan muchos años desarrollándose y que son en mayor o menor medida de difícil migración. Para ser más concretos, nos referimos a sistemas backend; bases de datos, entornos mainframe, sistemas a medida con tecnologías antiguas...

Los principales proveedores Cloud que existen en el mercado ya ofrecen sistemas para extender la red empresarial a sus sistemas, sea a través de VPN o con líneas dedicadas, factor que permite implantar estos escenarios híbridos.

Llegados a este punto, todo parece maravilloso, tengo sistemas OnPremise y puedo acceder a los otros sistemas Cloud como si todo se encontrará en una misma red empresarial. La afirmación es correcta pero hace falta darle un matiz.

De la misma manera que no se tarda lo mismo yendo de casa al trabajo o de casa a la otra punta del mundo, a nivel de infraestructuras ocurre lo mismo. Las separaciones geográficas entre los DataCenters OnPremise y los proporcionados por los proveedores pueden llegar a ser suficientemente elevadas como para que haya un impacto en los tiempos de respuesta de nuestros sistemas.

En mi experiencia, puedo decir que mediciones realizadas entre DataCenters OnPremise de España y DataCenters Cloud en Irlanda nos podemos mover entre los 35-50 milisegundos por viaje. Eso significa que si para una llamada a un servicio del Cloud, este tiene que consultar a un sistema OnPremise, significa que hay una request de Cloud a OnPremise y una response OnPremise a Cloud, por lo que son dos viajes entre DataCenters y el tiempo invertido en transporte se mueve entre los 70-100 milisegundos.

Otras pruebas realizadas entre DataCenters de España y otros Cloud en USA se mueven alrededor de los 100 milisegundos por viaje, por lo que el caso anterior para una simple llamada perderíamos 200 milisegundos únicamente en la comunicación entre DataCenters.

Los sistemas más complejos, para una simple llamada aplicativa requieren de realizar múltiples llamadas a Backend por lo que el número de saltos entre DataCenters crece bastante más y con ello los tiempos de respuesta que deberán asumir los clientes de nuestro sistema.

Por lo tanto, cuando nos encontremos ante un proyecto de migración a un entorno híbrido, es importante que pensemos que sistemas migraremos a Cloud y cuales dejaremos OnPremise, basándonos, entre otros factores, en la comunicación entre sistemas para minimizar en la medida de lo posible las llamadas entre DataCenters.

Siguiendo en esta línea cobran bastante fuerza lo que actualmente llamamos "arquitecturas reactivas" o lo que se ha llamado toda la vida "sistemas asíncronos", que permite que nuestros sistemas puedan integrarse con otros, seguir realizando acciones y bloquearse únicamente en el momento en que se requieran las respuestas a aquellas peticiones asíncronas para poder continuar con su lógica de negocio. Con estos sistemas, se consigue reducir los tiempos de respuesta y minimizar el impacto cuando nos encontramos en entornos híbridos, dado que si nuestro sistema puede continuar trabajando mientras espera la respuesta, el impacto del tiempo de transporte entre DataCenters se puede llegar a reducir drásticamente en determinados escenarios.

Otras medidas a tener en cuenta y que no son siempre posibles, son el uso de caches a nivel aplicativo o CDN (a nivel de contenido estático) para evitar esos viajes entre DataCenters, pero como ya hemos dicho, no son siempre viables las caches.

No hay una única solución válida y cada proyecto es un mundo, pero cuando nos encontremos ante una migración a entorno híbrido si que es importante que tengamos en cuenta la comunicación entre DataCenters cuando realizamos el diseño para evitarnos sorpresas desagradables a medio proyecto.


No hay comentarios