El paradigma de gestión de infraestructura en el cloud y las razones que pueden haber detrás del mismo, son temas que habitualmente se pueden afrontar de una forma más sencilla y operativa en el núcleo de una startup o incluso de una empresa tradicional, mientras que en el ámbito de las administraciones públicas esto puede suponer "todo un reto".
Este reto es el que ha afrontado la Universitat Jaume I de Castellón en su paso de un entorno de gestión on-premises a uno totalmente gestionado en el cloud de Amazon y que hoy os relatamos como la primera experiencia de migración al cloud de una administración pública en españa.
No todo va a ser como Netflix o LinkedIn gestionan su infraestructura :)
Motivaciones
Antes de nada, vamos a reflexionar un momento acerca de los factores que pueden motivar que nos planteemos un objetivo como este.
En mi opinión y al margen de muchas que seguro tendréis en mente, para mi son fundamentales tres: Flexibilidad del modelo de consumo, foco en el core de negocio y ahorro de costes.
El llamado modelo de consumo no es más que el mismo modelo al que estamos acostumbrados con la luz o el agua y que se basa en convertir la computación en una commodity más. De esta forma, si necesito más recursos los utilizaré y pagaré por ello, y si en el siguiente mes no tengo carga, pues reduciré el número de servidores provisionados (crecimiento elástico).
Por otra parte y fundamental en mi opinión, tenemos el objetivo de mantener el foco en el core de negocio. Si nuestra actividad es la de dar soporte a la gestión, la investigación y la docencia en una universidad, entonces el correo electrónico o la computación son "males necesarios" de los que necesitamos estar dotados, pero no representan necesariamente el objetivo principal de mi actividad. No son el core de mi negocio (aunque dependa de ellos para poder dar un servicio de calidad).
Esto es algo que se ha ido entendiendo con el tiempo, dando lugar a múltiples casos de éxito de migración del correo electrónico o de las herramientas de colaboración a plataformas de cloud público como es el caso de Google Apps. En este sentido, la Universitat Jaume I fue la primera universidad en completar el proceso de migración del correo electrónico del profesorado y de los estudiantes a GMail en el año 2010.
Pero en este planteamiento conviene tener en cuenta que para poder realmente liberarse de una parte importante de la gestión de la infraestructura, la solución a adoptar no tiene que ser un reflejo "1:1" de la arquitectura de que disponemos on-premises, sino que debe diseñarse y ser reformulada para aprovechar cada vez más los servicios PaaS del proveedor y su capacidad de crecimiento elástico y no quedarse en un modelo de IaaS en el que disponemos de máquinas virtuales que acabamos gestionando igualmente nosotros.
Por último, están los factores económicos. El ahorro de costes y la facilidad de contratación es algo que tiene mucho peso en las organizaciones actuales. En este sentido debemos tener cuidado con las afirmaciones del tipo "El cloud es caro y esto lo tendríamos igual en un proveedor normal de máquinas virtuales" (o con cuatro PCs del MediaMarkt, que también se puede llegar a escucharse ...).
En este sentido y para responder a esta afirmación, hay que tener en cuenta todos los factores que intervienen en el cómputo del coste de nuestra infraestructura on-premises. La cuestión es que tenemos que seguir manteniendo el CPD, luz, licencias de VMWare, licencias de software de backup, cintas y almacenamiento o incluso las horas de dedicación del personal técnico que opera toda la infraestructura.
Si queremos tener más pistas de cuanto nos va a costar el paso, AWS nos provee de dos herramientas para hacer cálculos de coste. Por una parte, tenemos la famosa calculadora o simple monthly calculator, que es cualquier cosa menos simple, y por otra parte la AWS Total Cost of Ownership (TCO) Calculator que nos ayuda a calcular el coste comparado de lo que costaría con respecto a una instalación on-premises.
Si estáis considerando realmente un cambio de este estilo en vuestra organización, mi única recomendación es que hagáis un análisis serio de costes.
Condicionantes
Nos centraremos principalmente en los condicionantes de tipo legal y en los relacionados con el equipo de profesionales necesario para poder completar el proceso (las personas siempre acaban siendo uno de los factores determinantes para el éxito de cualquier proyecto).
Al ser una entidad pública, uno de los primeros requisitos que nos encontramos es la obligación en el cumplimiento de la ley de protección de datos (LOPD), el esquema nacional de seguridad (ENS) y el esquema nacional de interoperabilidad (ENI). Para asegurarnos que cualquier solución de cloud cumple con estos requisitos debemos fijarnos en lo que se expone en el RD 1720/2007 y en el Anexo A del CCN-STIC-823 de Seguridad en Entornos Cloud, validando posteriormente que cada proveedor de cloud cumple con el checklist que allí se consigna (incluyendo la obligación de que los datos siempre residirán dentro del espacio de la unión europea).
Por otra parte, si intentamos ir siempre hacia servicios en PaaS, el equipo que tenga que operar estos servicios deberá de alguna manera adaptar su forma habitual de trabajar a las nuevas necesidades. Aunque ya no es necesario instalar nuevo hardware en el CPD, instalar el sistema operativo y configurar la red o el filtrado de puertos, hay todo un nuevo conjunto de tareas de automatización y provisión de servicios que aparecen en escena.
Estamos hablando en general del perfil que cada vez más se identifica como DevOps y que se encarga de programar la infraestructura y todos sus servicios relacionados, alineando los requisitos y las visiones tanto del área de desarrollo como de la de sistemas. El perfil de DevOps es un perfil que no existe en muchos equipos y que en estos casos se convierte en clave (a no ser que contemos ya con un equipo de desarrolladores Full Stack, que no suele ser lo habitual).
En cualquier caso, la única garantía de éxito para proyectos de esta envergadura es que todos y cada uno de los responsables de las distintas áreas implicadas (comunicaciones, sistemas y aplicaciones) trabajen de forma conjunta y coordinada.
Implantando la arquitectura diseñada
Aunque el entorno de gestión de partida pueda involucrar muchos servicios y máquinas, con el fin de que sirva como ejemplo nos vamos a centrar en los siguientes tipos de elementos a la hora de evaluar el impacto de un proceso de migración de estas características:
- Infraestructura de red.
- Base de datos corporativa.
- Servidores y frontales.
- Almacenamiento
- Y mucho mucho más ...
Infraestructura de red
Amazon implementa el concepto de Virtual Private Cloud (VPC) como base para construir nuestra estructura de red y así ir ubicando nuestros servicios en distintos segmentos expuestos a través de balanceadores hardware como es el caso de los Elastic Load Balancers (ELB).
Hay que tener en cuenta que para el acceso de administración o incluso de los servicios que se queden on-premises tras la migración, es interesante hacer uso de un tunel VPN contra AWS.
Ojo con este tipo de conexión, ya que necesitamos normalmente un hardware dedicado y una configuración muy concreta que Amazon nos proveerá. Nuestra experiencia en este respecto es que todo funciona mejor si el hardware que dediquemos al tunel está entre la lista de los soportados por Amazon y podemos cargar en él de forma directa las reglas que AWS nos genera.
Fuera de estos detalles, la configuración de red es bastante sencilla y raramente hay que hacer muchos ajustes a posteriori, por lo que esta parte no debería dar muchos dolores de cabeza.
Como característica adicional para aumentar la disponibilidad, podemos hacer uso de las distintas zonas de disponibilidad que no son más que extensiones desplegadas en datacenters distintos y separados lo suficiente para evitar caídas en caso de pérdida de servicio.
Base de datos
Entramos en el verdadero meollo de la cuestión, ya que habitualmente todos los aplicativos de gestión están conectados con la gran base de datos central. En estos escenarios tan data-centric, la base de datos es el núcleo de todas las operaciones y es el primer activo a considerar dentro del proceso de migración (si este no es tu escenario y no dependes de una gran base de datos relacional, antes de nada me gustaría decirte lo mucho que te envidio y, además, que Amazon ofrece un catálogo muy completo de NoSQL entre el que podemos encontrar un Redis en el servicio de ElasticCache o también un key-value/document database en DynamoDB).
Una de las primeras preguntas que debemos hacernos es si estamos dispuestos a asumir un periodo de parada o down time a la hora de realizar la migración de datos. Si nos lo podemos permitir y parar unas horas, el proceso de transferencia pasará por parar la base de datos central, realizar un export de todos los esquemas definidos, transferir este dump al servicio de Amazon de gestión de base de datos relacionales en PaaS que es RDS y posteriormente realizar allí el proceso de importación.
Por contra, si no queremos ningún tipo de tiempo de parada, una opción a evaluar es la del Data Migration Service de AWS que permite sincronizar datos entre instancias de base de datos, soportando PostgreSQL, MySQL y Oracle entre otras. Este escenario que parece el ideal, se vuelve un tanto complejo en el caso de que el esquema cambie a diario (muchas operaciones de DDL en producción) o si son cientos los esquemas de datos que se tendrían que sincronizar en DMS (distintas tareas de sincronización por cada esquema afectado).
Si nos decantamos por el primer escenario que incluye la parada de servicios, el primer problema con el que nos enfrentamos es la copia de una gran cantidad de datos desde nuestras instalaciones al cloud (en nuestro caso alrededor de 650GB de dump de base de datos).
En este sentido, si queremos transferir información de forma directa, podemos elegir entre dos posibles escenarios:
- Copiado de información directo a un bucket de S3. El comando de copia a S3 implementa nueva funcionalidad de transferencia en paralelo de información que, unida a la división del dump de exportación en ficheros de un tamaño menor durante el proceso de
exportde la base de datos hace que el tiempo total de transferencia se reduzca dramáticamente. - Transferencia de paquetes UDP con Tsunami. En este escenario necesitamos montar la parte servidora de Tsunami en una máquina EC2, aunque con las condiciones adecuadas de estabilidad de la conexión de red, podemos alcanzar velocidades de transferencia muy altas.
NOTA: Sólo una advertencia importante en estos casos de transferencia de grandes volúmenes de información: Es necesario elegir de forma adecuada la instancia de destino en EC2 ya que muchas no poseen las características de networking óptimas para un performance adecuado o el volumen EBS no está optimizado (ambas características se deben elegir a la hora de iniciar una nueva instancia en AWS). En la mayoría de los casos, es mucho más recomendable iniciar el proceso con una instancia de altas prestaciones para completar el proceso de migración lo más rápido posible y luego ajustar el tamaño a las necesidades reales del servicio, que hacerlo con una instancia pequeña con el fin de limitar el gasto desde el minuto cero.
Hay que tener en cuenta que, en el caso de Oracle, una vez que el dump de la base de datos llegue por completo a S3, se deberá copiar a una máquina EC2 y luego ser transferido a RDS para iniciar el proceso de import.
Servidores y frontales
Si nuestras aplicaciones son principalmente software legado corriendo en máquinas virtuales, poco tenemos que comentar. La idea es que estas puedan pasar de la forma más sencilla posible y no tengamos que realizar muchos cambios sobre estos entornos. De esta forma, el proceso siempre será el de convertir la máquinas virtuales VMWare en origen siguiendo la documentación de AWS e importarlas como AMIs en el entorno de Amazon. Ojo con las versiones de sistema operativo, ya que nos podemos llegar a encontrar con limitaciones por parte de Amazon ante instalaciones muy viejas.
En cualquier caso, la estrategia de migración consitirá en importar en AWS una SNAPSHOT de la máquina virtual que tenemos on-premises y luego preparar los scripts de sincronización de datos necesarios para que el sistema de ficheros de la instancia remota esté totalmente actualizado en el momento de hacer el cambio.
Para el caso de servicios nuevos, la idea sería crear nuevas máquinas en EC2 basadas en imágenes que tenemos disponibles en AWS, también llamadas AMIs (como la de AWS Linux basada en CentOS).
La alta disponibilidad la conseguimos en este caso haciendo uso de un balanceador hardware o ELB y la definición de un grupo de escalado que mantenga arrancadas como mínimo el número de instancias de esta AMI que nosotros queramos fijar. Si decimos que sean dos, en caso de que una instancia caiga, EC2 arrancará una nueva máquina basada en la imagen elegida.
Como aspecto avanzado, podemos definir eventos como por ejemplo para el caso en que la CPU supere el 80% durante tres periodos de comprobación seguidos. Ante esta situación podemos indicar que el número de instancias puede crecer por ejemplo hasta 4, destruyéndose posteriormente las que sobren hasta llegar al mínimo cuando la carga baje.
Por contra, si queremos conseguir un despliegue lo más PaaS posible, tener nuestras aplicaciones desplegadas en EC2 no nos dejará del todo satisfechos. Como alternativa tenemos varias opciones para dejar de ocuparnos de la capa del sistema operativo y de su operación si utilizamos servicios como:
- Elastic Beanstalk. Permite desplegar aplicaciones NodeJS, PHP, Python, Ruby, Java, Go o contenedores Docker sin tener que preocuparnos por el sistema host ni el servidor de aplicaciones en el que van a correr, ya que este lo proporciona AWS de forma transparente.
- Elastic Container Service (ECS). Nos ofrece un cluster de Docker donde desplegar nuestras aplicaciones si ya las tenemos "dockerizadas".
Hay que tener en cuenta que el uso de estos servicios no supone un coste extra en nuestra factura, ya que Amazon sólo nos cobrará por la parte de almacenamiento y hardware provisionado para poder dar soporte este servicio.
Almacenamiento
Por último, queda hablar del sistema de almacenamiento, el cual debemos planificar en función de la naturaleza de los datos a migrar.
Por una parte tenemos la información de la base de datos, la cual se cargará en RDS y se gestionará enteramente en un volumen que definiremos allí, de forma que será el propio RDS el que nos proveerá de SNAPSHOTS diarias y de un sistema muy sencillo de recuperación de las mismas en caso de querer restaurar una copia en otra instancia, recuperar datos o crear réplicas de lectura (no disponible para Oracle).
Por otra parte, tenemos el almacenamiento de bloques que utilizamos para los sistemas de ficheros de nuestras máquinas EC2, los cuales pueden ser locales a cada una de nuestras instancias o compartidos entre las mismas.
Si son locales, haremos uso normalmente de un volumen EBS (ojo a lo que comentábamos de que el tipo de instancia debe proveer EBS optimizado para que el rendimiento sea adecuado), mientras que cuando son compartidos, o bien montamos un servicio de NFS entre nuestras máquinas o bien probamos el nuevo servicio Elastic File System que se encuentra aún en preview en la región de Irlanda.
Por último, todo el resto de objetos a almacenar puede ir depositado en un bucket de S3 y, activando las políticas necesarias, pasar a ser archivado en Glacier para su conservación (servicio de archivado mucho más barato y más durable, pero con un coste y tiempo de acceso mayor si necesito recuperarlo muy tempranamente).
Lo interesante de S3 es que los recursos allí almacenados se pueden servir directamente por HTTP sin necesidad de disponer de un servidor web, así que puede ser un mecanismo sencillo de distribución (el cual soporta también otros protocolos como BitTorrent).
Y mucho mucho más ...
Disculpadme si me he dejado fuera tantísimas cosas importantes como son la seguridad, el acceso mediante usuarios IAM, el API, la consola web, la autenticación de dos factores en las cuentas, la creación de roles de acceso y la posibilidad de asignarlos a máquinas a la hora de realizar operaciones de API, el registro de acciones de CloudTrail, la gestión de certificados y claves con Certificate Manager y CloudHSM, el envío de notificaciones mediante SNS, el servicio de DNS Route53 o las nuevas capacidades para ejecutar contenedores ... y mucho mucho más :)
Conclusiones
En la actualidad existen muchos factores que pueden justificar el paso de una infraestructura on-premises a una cloud, pero uno de los más importantes es el foco en nuestro core de negocio.
Las soluciones de cloud suponen un coste de inversión más alto que las de los proveedores tradicionales, pero a cambio nos ofrecen todo un conjunto de funciones de valor añadido que nos liberan de ciertas tareas de muy bajo nivel, lo que supone un ahorro de tiempo y esfuerzo.
Conocer bien tu infraestuctura te ayudará a realizar una buena planificación de un proceso de migración, pero ten en cuenta que deberás realizar cambios y ajustes previos para poder concluir el proceso con éxito.
Cuando concluyas el proceso y tengas todo tu entorno en el cloud, es muy probable que su arquitectura no sea la más adecuada para aprovechar las capacidades que ofrece el proveedor y minimizar los costes en su uso. Es por ello que el proceso de evolución debe seguir una vez completado el primer paso, haciendo que nuestra arquitectura sea cada vez más flexible y eficiente.
La adopción de herramientas y tecnologías que se están estandarizando en la industria en lugar que las específicas del proveedor puede ayudar a evitar el temido "vendor lock-in", de forma que siempre podamos ser capaces de cambiar de AWS a Google Cloud o volver a nuestro entorno on-premises si fuese necesario. En este sentido, podemos intentar apostar por herramientas de provisión como Ansible en lugar del API de AWS o Cloud Formation o, por ejemplo, por Docker y Kubernetes en lugar de Beanstalk y ECS.
En definitiva, la apuesta por el cloud está más que consolidada ... ¿Vas a apostar por ella?
