Diez mandamientos para migrar a la nube y no fracasar

Permanentemente escuchamos a los lideres de las organizaciones que hablan desde un pseudo entendimiento y plantean "porque no llevamos todo nuestro data center a la nube" pero la respuesta es mucho más compleja. 

A excepción de las startups del último tiempo, que nacieron como nativas digitales, hacer una buena migración (desde lo técnico y lo eficiente económicamente) es mucho más difícil de lo que muchos creen, ya que requiere un estado de maduración y capacitación de todos los equipos intervinientes que es mas bien un "state of art" que una serie de procesos repetibles automáticamente. Sin duda las bondades de la nube están muy claras, agilidad de disponibilidad de recursos, flexibilidad, costos iniciales bajos, etc. la idea de este artículo es exponer en un lenguaje claro y coloquial algunas dificultades que pueden venir en forma de sorpresa si no son tratadas debidamente.

En base a muchísimas investigaciones, lectura de papers, libros, documentos, etc y sobre todo experiencia propia y el intercambio con otros colegas les dejo un decálogo con los diez mandamientos para migración a la nube inteligente y sustentable Esto es independiente del hyperscalers que elijas, pero en especial me centré en los mas importantes, que son: AWS, AZURE, GCP, y algunos otros proveedores de nube menos relevantes que andan por ahí.

1. LA NUBE NO ES PARA TODO: Si tenes tu data center propio seguramente hay cosas que hacen sentido no migrar, ya sea por latencia, confidencialidad, costos, eficiencia de los enlaces que tenes contratados, porque son aplicaciones "legacy" etc. Lo primero que necesitas un buen assesment y una buena planificación. Clasificá, ordená, priorizá, detecta donde tenes los quick-wins (ej sacarse migrar un server que no tiene soporte de hardware, etc) y seguir migrando paso a paso. Cada migración tiene que tener un sentido y un porqué. Una frase que me gusta para representar este enfoque equivocado es: "Cuando la única herramienta que conoces es el martillo, todos tus problemas se parecen a un clavo".
2. NO PODES OPERAR EN LA NUBE TAL CUAL COMO OPERABAS ANTES: cada cosa que haces en la nube se paga, todo, absolutamente todo. Seguramente nunca te pusiste a calcular cuantos GB de transferencia tenia una placa de red de un server X, pero por más que salga 0,00001 USD por cada GB hay que pensar que todo tiene un costo, eso antes ni lo tenias medido. Hay que mirarlo con lupa. Los hypersacaler tienen herramientas que ayudan, pero hay que ponerlo en la rutina de tareas, a veces las calculadoras pueden ser complejas de utilizar. También vas a tener que replantearte el ancho de banda de tus enlaces. Les recomiendo el AWS Cloud Adoption Framework (ESP)  Es el muy completo y te cuenta como hacer un buen camino a la nube. Conozco muchos casos de empresas que vuelve de la nube al on-premise por no planificar adecuadamente y encontrarse con facturas sorprendentes a fin de mes.
3. SE NECESITAN NUEVOS SKILLS EN EL EQUIPO: Gestionar la nube es complejo, si venias de un entorno simple, ahora vas a tener mucha mas granularidad que administrar, permisos entre redes, permisos de usuarios, grupos, auditorias, controles de costos, servers, etc, etc. Es mas complejo. necesitas adquirir nuevas capacidades, no es rocket science, pero si no te capacitas, la vas a pasar mal. Se necesita perfeccionar los skills de seguridad de todos los equipos de IT.
4. LA NUBE NO ES PERFECTA: Si bien los proveedores ofrecen excelentes capacidades de disponibilidad, si queres una aplicación REALMENTE alta disponibilidad ES TU responsabilidad en el diseño de la arquitectura de la solución para que realmente sea alta disponibilidad, ya que no todos los recursos son redundantes por default en la nube, entonces debes agregar recursos en distintas zonas y el diseño de la arquitectura debe estar acorde.
5. LA MAGIA ESTA EN LOS MICROSERVICIOS: la nube comienza a ser eficiente cuando haces uso de las tecnologías mas avanzadas, mientras tanto es caro. Tenes opciones de "apagar el server cuando no lo usas" pero una vez mas vuelve el concepto de operar la nube a "conciencia de costos". Tener encendido un server 24x7 en la nube igual que en tu data center funciona, pero no es eficiente. Seguramente vas a tener que rehacer aplicaciones.
6. APROVECHÁ LA TECNOLOGÍA DISPONIBLE: no reinventes la rueda, siempre pensá en utilizar las herramientas que ya tenes en la nube, son agiles y fáciles de implementar (también agiles de adquirir, comparado con un proceso administrativo de cualquier organización standard). Revisá en las herramientas existen en la nube, probablemente ya haya disponibles soluciones pueden ser fáciles y rápidas de implementar para tu negocio. Mantenete actualizado con los servicios que van saliendo, porque permanentemente se publican nuevas herramientas.
7. RESERVAR LOS RECURSOS MINIMOS: en el viejo mundo cuando nos pedían un server antes pensábamos en xx CPU,  xx GB de RAM, xx TB de disco, proyectando en crecimiento a xx años, etc. Acá tenés que pensarlo exactamente al revés, reservá la instancia mínima y después vas creciendo a demanda, y después preparate para pelearte con los app owner que te van a venir con el manual de instalación de su producto para hacerlos entender que tienen que salir de su standard y pensar en un modelo que sea escalable, seguramente vaya a tener que hacer que su app escale a demanda requerirá un desarrollo por parte de ellos, pero es la única forma que la nube sea productiva. 
8. NO EXISTE UNA NUBE PERFECTA PARA TODOS LOS USOS: Para las empresas grandes el futuro es hibrido y multinube. Hibrido porque hay cosas que nunca saldrán del on-prem (excepto que te decidas por AWS Outpost o Azure HCI) y multinube porque cada una tiene sus virtudes donde se destaca sobre el resto. En relación a los costos no se sacan mayores diferencias ya que en líneas generales están muy parejos, pero si hay algunas salvedades tecnológicas que vale la pena remarcar por características distintivas de cada una:
1. AWS: se destaca por la su solvencia en innovación tecnológica de vanguardia, granularidad para elegir alternativas mas eficientes en costos y disponibilidad de talentos en el mercado con conocimientos de la plataforma.
2. Azure: ventaja competitiva en licenciamiento, que se traduce en eficiencia de costo y el apalancamiento que le da los clientes corporativos que ya están usando la suite de Office 365 y en especial Azure AD.
3. GCP: Integraciones y herramientas de desarrollo/web. Big Data, analítica, Machine learning y la baja latencia de sus servicios basados en kubernetes.
9.  LOS DATOS EN LA NUBE SON TU RESPONSABLIDAD: Todos los hyperscalers tienen modelo de responsabilidad compartida, despendiendo del tipo de servicio que consumas varían los grados de responsabilidad, pero siempre el responsable de los datos sos VOS! No te relajes. Revisá  permanentemente la integración de tu estrategia de backups en la nube.
10. LOS ERRORES CUESTAN PLATA (Y MUCHA) En un entorno tradicional, un desarrollador o un proveedor se equivocaba, dejaban un proceso corriendo mal, una base de datos ejecutando una consulta ineficiente, con una recursividad que causara un loop o algo similar (incluso en un ambiente de test) un viernes a la noche y a lo sumo el lunes a la mañana tenias el server colgado, lo reiniciabas y listo. Acá el tema es distinto, acá pagas y mucho, una query mal programada en test puede terminar en una facturación de miles de dólares (lo he visto). Viene la factura y a pagarla. Muchas empresas fueron a la nube sin una buena estrategia y "terminaron volviendo al onpremise" para correr algunas de sus cargas, con la gran dificultad que eso representa. Si bien es cierto que tener herramientas de analisis de costos, alertas, forcasting, etc, etc, lo malo es que muchas veces son post-mortem, el gasto ya se realizó. Lamentablemente aún no implementaron el concept de "quotas" sobre recursos. También comparto el link de FinOps, una ONG creada por The Linux Foundation con el fin crear conciencia en el uso eficiente de las tecnologías nube. 

CAPACITARSE, CAPACITARSE, CAPACITARSE y SEGUIR CAPACITANDOSE. Los viejos SysAdmin deberán convertirse en los próximos DevOps. Para eso aprender a programar es una obligación.

BONUS TRACK: te dejo una comparativa de los nombre de los productos equivalentes en cada uno de los principales hyperscalers, como ya lo dije el futuro es multinube y tenemos muchos nombres que aprendernos, si si, son un montón de productos, aquí solo los mas importantes  --> muy buena cuenta para seguir @simonholdorf

Continuidad del negocio en el Data Center

Al desarrollar un plan de recuperación, el objetivo es regresar la operación del negocio al nivel en que estaba el día antes de la catástrofe. Si su negocio es tomar pedidos por medio de una línea telefónica y continuar con la entrega de productos, el esfuerzo de recuperación debería estar dirigido hacia el restablecimiento de la operación telefónica y la conexión del personal a los sistemas de procesamiento informático y telefónico, lo cual permitirá que continúen los envíos.
El plan final podrá incluir una instalación redundante en otro sitio remoto que tenga acceso a los datos obtenidos de las copias de seguridad. Si la operación no es tan crítica o la instalación redundante no ha sido considerada por razones presupuestarias, es imprescindible un buen plan de recuperación.
Cada hora perdida decidiendo sobre un enfoque o experimentando con diferentes técnicas es una hora de interrupción al negocio que genera pérdidas.
Las empresas deberán desarrollar un plan integral, de forma artesanal para así enfrentar las consecuencias el día del desastre, ya que no existe una solución única, sino que es propia de cada empresa, diseñada a medida.

Un BCP no es un plan del área de IT solamente, sino que involucra a toda la empresa por completo desde la restauración de servidores hasta las tareas operativas, ejecutivas y directivas.

En el plan interactúan las personas de la organización con la tecnología, los procesos y la infraestructura.
Ciclo de vida del Plan de Continuidad del Negocio:

• Análisis y planificación: cuando se inicia el proyecto se debe tener en consideración todo el negocio por completo, haciendo un estudio de necesidades y evaluando la situación actual. Luego, se debe hacer un minucioso análisis de riesgos del impacto al negocio (BIA, Business Impact Analysis), análisis de pérdidas, cuantificación de consecuencias, etcétera e identificar las aplicaciones críticas, que forman el núcleo operativo: inventarios de aplicaciones y servidores, diagramas de red e infraestructura. Adicionalmente, hay que identificar los posibles escenarios y análisis de amenazas. En esta etapa, se definirán bajo qué condiciones se activarán los procesos de contingencia y cómo será el camino que se tome para volver a la situación de operación normal.
• Diseño de solución: se buscará la manera en que se pueda llevar a cabo el plan de contingencia de manera integral desarrollando una estrategia de mitigación. Debe ser comunicado correctamente a todas las áreas, preferentemente siguiendo los estándares. Además se procederá con la elaboración de una lista de prioridades con un orden específico y se confeccionará un checklist para los equipos con identificación de contactos internos y proveedores clave. Se definirán los equipos y los procesos de recuperación así como la selección de la estrategia de backup y los objetivos de los tiempos de recuperación (RTO). Asimismo se establecerá el tiempo máximo de interrupción tolerable (MTPOD), el punto de recuperación objetivo (RPO), la forma de interactuar y los roles clave. 
• RPO: refleja el punto tolerable de restauración de los datos. Por ejemplo, se define si es aceptable contar con los datos de las 00:00 h del día en que ocurre el desastre, o si se prefiere las 00:00 h del último domingo de la semana en que ocurrió el desastre. Obviamente esto está relacionado con la solución de backup elegida, que será detallada más adelante en este capítulo.
• RTO: es el tiempo en que se desean tener los datos recuperados y disponibles. Por ejemplo, en cinco horas, diez horas, etcétera.
• MTPOD: es el tiempo aceptable de recuperación total. Luego de haber alcanzado el RTO, queda pendiente restaurar las operaciones al punto normal. Esto puede requerir configuraciones adicionales que agregan más tiempo a la restauración del servicio.
• Implementación: es el desarrollo del plan, incluye la puesta en marcha de un ejercicio de simulación, que quizás para empresas chicas o medianas pueda ser inviable por razones presupuestarias, pero que son realmente importantes, como los ejercicios de evacuación de incendios en los edificios, entrenamiento, documentación y capacitación. Es recomendable que todas las tareas sean coordinadas por un Comité de Crisis que debe estar previamente designado y conformado por personas que conozcan bien el negocio, tengan poder y capacidad para tomar decisiones.  Lo importante se debe anteponer a lo urgente, ya que una mala decisión puede ser contraproducente.
• Testeo y aceptación: en el momento de ejecución del ejercicio de simulación o cuando se  activa el BCP, realmente, la comunicación entre todas las partes tiene un rol fundamental para alcanzar el éxito. Se deberá hacer la verificación, corroborar los pasos correctos, determinar desvíos, identificar puntos débiles, análisis de costos y luego tomar medidas correctivas, llamadas lecciones aprendidas (lesson learned). Ellas realimentarán el proceso de diseño de la solución a fin de introducir mejoras.Es recomendado hacer una prueba completa de todo el BCP al menos una vez al año, aunque pueden hacerse pruebas parciales con menor frecuencia para probar nuevas tecnologías o soluciones parciales para ciertos eventos.
• Mantenimiento: se debe comunicar y mantener actualizado el plan aprobado, asegurando que el personal esté debidamente entrenado. Hay que mantener un monitoreo continuo para el establecimiento de políticas estratégicas, además de identificar nuevas tecnologías o cambios operativos, legales, regulatorios directivos que permitan mejorar el diseño de la solución.

Se recomienda tener un repositorio de versiones y además un documento de control de cambios entre las distintas versiones para ver de manera simple cuales fueron las mejoras introducidas.
Sin duda estas planificaciones requieren dedicación de recursos, tiempo, recolección de información, infraestructura, etcétera, que en definitiva es dinero, pero si la catástrofe ocurre las consecuencias económicas serían mucho peores.

RTO: Recovery Time Objective. Se mide en horas.
MTPOD: Maximum Tolerable Period of Distruption. Se mide en horas
RPO:Recovery Point Objective es el objetivo deseado de recuperación.

Hollywood ya sabe la importancia del Data Center

Una de las funciones básicas de un Data Center bien diseñado es eliminar los riesgos potenciales que causarían pérdidas evitables, y minimizar el impacto de las no evitables como las catástrofes naturales. Las empresas que sufren situaciones de desastre en sus sistemas, quedan con un daño irreversible que puede llevar a la compañía a su cierre parcial o, en algunos casos, definitivo.

Los guionistas de cine y  televisión ya son consientes que para eliminar completamente a "los malos", no solo basta con deshacerse de los personajes, sino que también deben destruir su Data Center.

Una investigación de la Universidad de Texas revela que de las empresas que sufren una pérdida masiva en sus sistemas de información, el 43% nunca vuelve a abrir, el 51% cierra antes de los dos años, y solo el 6% puede continuar con su actividad, enfrentando grandes pérdidas en sus sistemas de información.
Según otro informe de la Agencia Nacional de Archivos y Registros en Washington D.C. (National Archives and Records Administration), el 93% de los negocios que tienen una interrupción importante en sus Data Center por más de 10 días, quedan en bancarrota en menos de un año.
La contundencia de estos números deja a la vista cuán importante son los datos de las empresas para poder permanecer con las puertas abiertas.

Tratando de no spoilear películas, a continuación les dejo algunos casos donde para que "los buenos" derroten a "los malos" y tengamos un final feliz con nuestras panzas llenas de pochoclo (también llamadas palomitas), el protagonista debe destruir el Data Center enemigo para poder derrotarlo definitivamente.

• Terminator 2 (1991): Terminator personificado por Arnold Schwarzenegger junto con Sarah y John Connor logran convencer al científico  Miles Dyson que deben volar el laboratorio de investigación de Cyberdyne Systems, junto con toda la información existente con fin de destruir por completo a Skynet (los malos). Pese a que todo termina con una gran explosión, cuando los planes salen perfectos, los guionistas aprovechar a dejar puertas abiertas para futuras zagas. 
• Prision Break - Temp 4 (2009): Los hermanos Michael Scofield y Lincoln Burrow, luego de tres temporadas deciden que deben destruir a "Scylla" un repositorio de información ultrasecreto ultraprotegido que guarda los mayores pecados de los malos.
• Ant-Man (2015):  Dr. Hank Pym quiere evitar que una tecnología de avanzada que el mismo descubrió, caiga en las manos equivocadas debido a su gran potencial (en este caso Darren Cross). Para ello se propone destruir el Data Center de Pym Technologies (el laboratorio que el mismo creo) así como también todos los datos almacenados en los backups.

Los invito a dejar comentarios en este post de otras películas donde las destrucción del Data Center sea sinónimo de acabar con los malos.

Optimización del Flujo de Aire Frío

Cuando estamos en casa, pasando una cruda noche de invierno y tenemos frío, subimos la temperatura de la calefacción, y si seguimos con frío, encendemos otro otra estufa más..... y así seguimos, pero nos ponemos a pensar porque ? Analizamos por donde está entrando el frío? Quizás poniendo un burlete en el marco de la ventana o colocar una ventana doble resuelve el problema sin tener que consumir mas calorías para aclimatar.

Lo mismo ocurre en los Data Centers. No siempre que se detectan problemas de temperaturas la solución es bajar la temperatura del CRAC. El problema también puede ser la presión de aire. Por lo tanto aumentar o reducir la velocidad de circulación del aire frío puede ser la solución óptima. En los diseños donde el aire frío ingresa por debajo del piso técnico, el pasillo frío debe estar libre de obstrucciones, permitiendo una circulación libre. Es por ello que los cables de alimentación y comunicaciones deberán pasar por debajo del pasillo caliente.

Para asegurar la correcta refrigeración de los equipos, una de las claves está en descargar la cantidad justa de aire frío, dirigida hacia la fuente de calor, mediante rejillas en el piso técnico o por ventilación superior.
En el caso del piso técnico, se produce un cambio de presión dentro del piso falso, comparado con la presión externa. En función de este diferencial, aumenta o disminuye la velocidad de giro de los ventiladores EC de los climatizadores. En caso de tener un solo un pasillo frío encapsulado, se mide el diferencial de presión del interior del pasillo con la sala, usando esta señal para regular la velocidad de giro de los ventiladores.
En el piso del pasillo encapsulado están los elementos de control de caudal de aire frío, en función de la temperatura dentro de los Rack. La presión en el interior del pasillo encapsulado no debe superar un valor máximo para no exigir a los ventiladores en el interior de los servidores. En caso de tener múltiples pasillos encapsulados, se instala una regulación por pasillo y una de presión general del
piso falso. Al reducir el caudal de aire a la mitad, el consumo eléctrico es mucho menor. A mayor velocidad de circulación del aire, menor presión estática en las placas perforadas más cercanas a la unidad CRAC. Dicho control asegura que el aire sea el justo y necesario, permitiendo un ahorro significativo en el consumo eléctrico de los ventiladores. A continuación, se pueden ver las diferencias que existen entre un flujo correcto de aire y otros incorrectos.

El control de presión en pasillo frío encapsulado asegura que el aire fluya correctamente y se mantenga separado el frío del caliente, asegurando que el aire caliente reingrese a la unidad de enfriamiento sin pérdidas. De ser posible es recomendado mover la refrigeración más cerca de la carga, lo que permitirá ahorrar en potencia total de ventilación y proporcionará un tiempo de reacción más rápido si varían las cargas de los equipos en los Racks.

La eliminación del aire caliente puede estar provista por canalizaciones especiales ubicadas en el techo, que pueden ser selladas o no, ya que el aire caliente siempre tiende a subir a fin de permitir la expulsión de ese aire caliente hacia el exterior o para volver a introducirlo en la unidad CRAC. Si la temperatura de salida del aire caliente aumenta al reingresar a la unidad CRAC, el esfuerzo para
enfriarlo será mayor, y viceversa. Por otro lado, existe un problema frecuente en los Data Centers, ya que muchas veces se mueven equipos de un Rack a otro, dejando espacios libres y no se toman medidas para evitar la recirculación de aire caliente hacia el frente del Rack.
Instalado paneles ciegos (o también llamados de obturación) se impide que el aire caliente recircule hacia la parte delantera del Rack donde se encuentra la toma de aire frío para los equipos, haciendo un buen aprovechamiento de la capacidad de refrigeración

La clave es encontrar un equilibrio justo para tener la humedad en un rango óptimo. Los paneles ciegos en los Racks ayudan a disminuir la circulación del aire, manteniendo los pasillos fríos y calientes separados.

Diseño de pasillos y más.....

Han pasado más de 22 años desde que el Dr Robert Sullivan creó por primera vez el diseño de pasillo frío/pasillo caliente mientras trabajaba en como investigador para los laboratorios de IBM.
Años después formalizaría ese diseño para luego convertirlo prácticamente en un standard indiscutible al día de la fecha. En su trabajo "Alternating cold and hot aisles provides more reliable cooling for server farms" publicado en 2002 se explican como ubicar y orientar los racks en el Data Center para optimizar el uso de los sistemas de enfriamiento.

El diseño y la ubicación de los Racks dentro del área del Data Center es vital para lograr una optimización de eficiencia en la refrigeración.
Los Racks deben estar todos alineados formando pasillos opuestos unos con otros, enfrentando la parte delantera de una fila con la parte delantera de la otra. De esa forma, quedan diseñados pasillos intercalados: uno frío y uno caliente, alternadamente. El pasillo por donde sale el aire caliente de los Racks deberá estar en forma opuesta a la siguiente fila. Los equipos toman el aire frío por la parte frontal y expulsan el aire caliente por la parte trasera. 

En el gráfico, se muestra la disposición de los pasillos. El pasillo frío se encuentra refrigerado por el aire que ingresa por el frente de los Racks a través de las rejillas de ventilación (que pueden venir por debajo del piso técnico y de alimentación superior), y luego el aire caliente es expulsado por la parte trasera de los Racks, para reingresar a las unidades de enfriamiento, también conocidas como  CRAC (Computer Room Air Conditioning).

En estos dispositivos, monitorean y mantienen controlada tanto la temperatura como la humedad dentro del Data Center. Poseen una entrada por donde ingresa el aire caliente y una salida por donde expulsa el aire frío. Las unidades de enfriamiento deben estar coordinadas entre sí de forma tal que funcionen de modo sincronizado, haciendo un esfuerzo cooperativo, y donde la distribución de la carga es equitativa, maximizando así la vida útil de los componentes y balanceando la energía consumida.

Si estamos armado un Data Center desde cero, la mejor estrategia de optimización de espacio es inversa a la lógica convencional de diseñar primero las paredes, las columnas y puertas en un espacio vacío que luego será amoblado con cientos de equipos computacionales. Es decir, lo que se debería hacer en primer lugar, es diseñar la disposición de los Racks, ubicación de pasillos (fríos y calientes), equipos de refrigeración, etcétera.  Una vez dispuesto el diseño de la distribución de todos los elementos, es el momento de colocar las paredes, puertas y columnas en el plano. De esta forma, se logrará un máximo aprovechamiento del espacio físico, evitando así espacios muertos inutilizables.

Para tener un mejor rendimiento en los equipos de aire acondicionado, hay que disminuir el consumo eléctrico y mantener la temperatura controlada. Se recomienda hacer una aislación completa entre los pasillos, ya sea al comienzo o al final de los Racks, colocando puertas para poder acceder al pasillo aislado. Dicha separación de pasillos impide que el aire se mezcle, mejorando la temperatura y disminuyendo el consumo.

Sobre la base de las recomendaciones de la norma TIA/EIA-942, los pasillos fríos deben tener 1,20 m de ancho (hasta 0,9 es aceptado), y deberán tener una temperatura no mayor a los 25°C. Por otra parte, los pasillos calientes deben tener 0,9 m de ancho (hasta 0,6 es aceptado), funcionando a una temperatura que puede oscilar entre 36°C y 47°C, dependiendo de la carga y el uso de los Racks en ese pasillo.

En próximos artículos hablaremos de la importancia de la circulación del flujo del aire entrante y saliente.

.