Migraciones al cloud en primera persona

El paradigma de administración de infraestructura en el cloud y las razones que pueden haber tras el mismo, son temas que frecuentemente se pueden encarar de una manera más fácil y operativa en el núcleo de una startup o bien aun de una compañía tradicional, al paso que en el campo de las administraciones públicas esto puede suponer un reto.

Este reto es el que ha afrontado la Universitat Jaume I de Castellón en su paso de un ambiente de administración on-premises a uno absolutamente gestionado en el cloud de Amazon y que el día de hoy os narramos como la primera experiencia de migración al cloud de una administración pública en españa.

No todo será como Netflix o bien LinkedIn administran su infraestructura :)

Motivaciones

Antes de seguir, vamos a meditar un instante sobre los factores que pueden motivar que nos propongamos un propósito como este.

A mi parecer y al lado de muchas que seguro vais a tener en psique, para mi son esenciales tres: Flexibilidad del modelo de consumo, foco en el core de negocio y ahorro de costos.

El llamado modelo de consumo no es más que exactamente el mismo modelo al que estamos habituados con la luz o bien el agua y que se fundamenta en transformar la computación en una commodity más. Así, si necesito más recursos los emplearé y voy a pagar por esta razón, y si en el próximo mes no tengo carga, puesto que reduciré el número de servidores provisionados (desarrollo flexible).

Por otro lado y esencial a mi modo de ver, tenemos la meta de sostener el foco en el core de negocio. Si nuestra actividad es la de entregar soporte a la administración, la investigación y la docencia en una universidad, entonces el e mail o bien la computación son males precisos de los que precisamos estar dotados, mas no representan necesariamente el principal objetivo de mi actividad. No son el core de mi negocio (si bien dependa de ellos para poder entregar un servicio de calidad).

Esto es una cosa que se ha ido entendiendo con el tiempo, dando sitio a múltiples casos de éxito de migración del e mail o bien de las herramientas de cooperación a plataformas de cloud público como es el caso de Google Aplicaciones. En este sentido, la Universitat Jaume I fue la primera universidad en llenar el proceso de migración del e-mail del profesorado y de los estudiantes a GMail en el año dos mil diez.

Mas en este planteamiento es conveniente tener en consideración que para poder verdaderamente liberarse de una parte esencial de la administración de la infraestructura, la solución a adoptar no debe ser un reflejo 1:1 de la arquitectura de que disponemos on-premises, sino debe diseñarse y ser reelaborada para aprovechar poco a poco más los servicios PaaS del distribuidor y su capacidad de desarrollo flexible y no quedarse en un modelo de IaaS en el que disponemos de máquinas virtuales que terminamos administrando del mismo modo .

Finalmente, están los factores económicos. El ahorro de costos y la sencillez de contratación es una cosa que tiene mucho peso en las organizaciones actuales. En este sentido debemos tener precaución con las aseveraciones del tipo El cloud es costoso y esto lo tendríamos igual en un distribuidor normal de máquinas virtuales (o bien con 4 PCs del MediaMarkt, que asimismo se puede llegar a escucharse …).

En este sentido y para contestar a esta aseveración, hay que tomar en consideración todos y cada uno de los factores que intervienen en el cómputo del costo de nuestra infraestructura on-premises. La cuestión es que debemos continuar sosteniendo el CPD, luz, licencias de VMWare, licencias de software de backup, cintas y almacenaje o bien aun las horas de dedicación del personal técnico que opera toda la infraestructura.

Si deseamos tener más pistas de cuanto nos costará el paso, AWS nos provee de 2 herramientas para hacer cálculos de costo. Por un lado, tenemos la conocida calculadora o bien simple monthly calculator, que es cualquier cosa menos simple, y por otro lado la AWS Total Cost of Ownership (TCO) Calculator que nos ayuda a calcular el costo equiparado de lo que costaría respecto a una instalación on-premises.

Si estáis considerando verdaderamente un cambio de este estilo en vuestra organización, mi única recomendación es que hagáis un análisis serio de costos.

Condicionantes

Nos vamos a centrar primordialmente en los condicionantes de tipo legal y en los relacionados con el equipo de profesionales preciso para poder llenar el proceso (las personas siempre y en toda circunstancia terminan siendo entre los factores determinantes para el éxito de cualquier proyecto).

Siendo una entidad pública, entre los primeros requisitos que nos hallamos 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 Anejo A del CCN-STIC-ochocientos veintitres de Seguridad en Ambientes Cloud, validando más tarde que cada distribuidor de cloud cumple con el checklist que allá se consigna (incluyendo la obligación de que los datos siempre y en todo momento radicarán en el espacio de la unión europea).

Por otro lado, si procuramos ir siempre y en toda circunstancia cara servicios en PaaS, el equipo que deba operar estos servicios va a deber de alguna forma amoldar su forma frecuente de trabajar a las nuevas necesidades. Si bien ya no es preciso instalar nuevo hardware en el CPD, instalar el sistema operativo y configurar la red o bien el filtrado de puertos, hay un nuevo conjunto de labores de automatización y provisión de servicios que aparecen en escena.

Hablamos por lo general del perfil que poco a poco más se identifica como DevOps y que se hace cargo de programar la infraestructura y 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 transforma en clave (salvo que contemos ya con un equipo de desarrolladores Full Stack, que no acostumbra a ser lo común).

En todo caso, la única garantía de éxito para proyectos de esta extensión es que todos los responsables de las diferentes áreas implicadas (comunicaciones, sistemas y aplicaciones) trabajen conjuntamente y ordenada.

Implantando la arquitectura diseñada

Si bien el ambiente de administración de partida pueda implicar muchos servicios y máquinas, con la intención de que sirva como un ejemplo nos centraremos en los próximos géneros de elementos en el momento de valorar el impacto de un proceso de migración de estas características:

Infraestructura de red.
Base de datos corporativa.
Servidores y frontales.
Almacenaje
Y mucho considerablemente más …

Infraestructura de red

Amazon incorpora el término de Virtual Private Cloud (VPC) como base para edificar nuestra estructura de red y de este modo ir situando nuestros servicios en diferentes segmentos expuestos por medio de balanceadores hardware como es el caso de los Elastic Cargar Balancers (ELB).

Hay que tomar en consideración que para el acceso de administración o bien aun de los servicios que se queden on-premises tras la migración, es interesante hacer empleo de un túnel VPN contra AWS.

Ojo con esta clase de conexión, en tanto que precisamos en general un hardware dedicado y una configuración muy específica que Amazon nos proveerá. Nuestra experiencia en este respecto es que todo marcha mejor si el hardware que dediquemos al túnel está entre la lista de los soportados por Amazon y podemos cargar en él de manera directa las reglas que AWS nos produce.

Fuera de estos detalles, la configuración de red es bastante fácil y extrañamente hay que hacer muchos ajustes a posteriori, con lo que esta parte no debería entregar muchos cefaleas.

Como característica auxiliar para acrecentar la disponibilidad, podemos hacer empleo de las diferentes zonas de disponibilidad que no son más que extensiones desplegadas en datacenters diferentes y separados lo bastante para eludir caídas en el caso de pérdida de servicio.

Base de datos

Entramos en el auténtico meollo de la cuestión, puesto que frecuentemente todos y cada uno de los aplicativos de administración están conectados con la enorme base de datos central. En estos escenarios tan data-centric, la base de datos es el núcleo de todas y cada una de las operaciones y es el primer activo a estimar en el proceso de migración (si este no es tu escenario y no dependes de una enorme base de datos relacional, antes de seguir me agradaría decirte lo mucho que te envidio y, además de esto, que Amazon ofrece un catálogo completísimo de NoSQL entre el que podemos localizar un Redis en el servicio de ElasticCache o bien asimismo un key-value/document base de datos en DynamoDB).

Entre las primeras preguntas que debemos hacernos es si estamos prestos a aceptar un periodo de parada o bien down time en el momento de efectuar la migración de datos. Si nos lo podemos permitir y parar unas horas, el proceso de transferencia va a pasar por parar la base de datos central, efectuar un export de todos y cada uno de los esquemas definidos, trasferir este dump al servicio de Amazon de administración de base de datos relacionales en PaaS que es RDS y más tarde efectuar allá el proceso de importación.

Por el contrario, si no deseamos ningún género de tiempo de parada, una alternativa a valorar es la del Data Migration Service de AWS que deja acompasar datos entre instancias de base de datos, aguantando PostgreSQL, MySQL y Oracle entre otras muchas. Este escenario que semeja el ideal, se vuelve un tanto complejo en caso de que el esquema cambie diariamente (muchas operaciones de DDL en producción) o bien si son cientos los esquemas de datos que se deberían acompasar en DMS (diferentes labores de sincronización por cada esquema perjudicado).

Si nos decantamos por el primer escenario que incluye la parada de servicios, el primer inconveniente con el que nos encaramos es la copia de un sinnúmero de datos desde nuestras instalaciones al cloud (en nuestro caso en torno a 650GB de dump de base de datos).

En este sentido, si deseamos trasferir información de manera directa, podemos seleccionar entre 2 posibles escenarios:

Copiado de información directo a un bucket de S3. El comando de copia a S3 incorpora nueva funcionalidad de transferencia paralelamente de información que, unida a la división del dump de exportación en archivos de un tamaño menor a lo largo del proceso de export de la base de datos hace que el tiempo total de transferencia se reduzca dramáticamente.
Transferencia de bultos UDP con Sunami. En este escenario precisamos montar la parte servidora de Sunami en una máquina EC2, si bien con las condiciones convenientes de estabilidad de la conexión de red, podemos lograr velocidades de transferencia altísimas.

NOTA: Solo una advertencia esencial en estos casos de transferencia de grandes volúmenes de información: Es preciso escoger de forma conveniente la instancia de destino en EC2 en tanto que muchas no tienen las peculiaridades de networking perfectas para un performance conveniente o bien el volumen EBS no está optimado (las dos peculiaridades se deben seleccionar en el momento de comenzar una nueva instancia en AWS). En la mayor parte de los casos, es considerablemente más aconsejable comenzar el proceso con una instancia de altas posibilidades para llenar el proceso de migración lo más veloz posible y después ajustar el tamaño a las necesidades reales del servicio, que hacerlo con una instancia pequeña con el propósito de limitar el gasto desde el minuto cero.

Hay que tener en consideración que, en el caso de Oracle, cuando el dump de la base de datos llegue por completo a S3, se va a deber copiar a una máquina EC2 y después ser transferido a RDS para empezar el proceso de import.

Servidores y frontales

Si nuestras aplicaciones son primordialmente software legado corriendo en máquinas virtuales, poco debemos comentar. La idea es que estas puedan pasar de la manera más fácil posible y no debamos efectuar muchos cambios sobre estos ambientes. De esta manera, el proceso siempre y en toda circunstancia va a ser el de transformar la máquinas virtuales VMWare en origen siguiendo la documentación de AWS y también importarlas como AMIs en el ambiente de Amazon. Ojo con las versiones de