Arquitectura Nube
Me aventuro a afirmar que hoy en día es común escuchar acerca de Arquitectura para la Nube tanto en publicaciones relacionadas con tecnología; como en proyectos de transformación digital y las reuniones derivadas entre los equipos que participan.
Coloquemos como ejemplo las células ágiles que trabajan en proyectos de migración de infraestructura y/o servicios hacia la Nube en cualquiera de sus modalidades; o simplemente desarrollando aplicaciones nativas para dar respuesta a las necesidades actuales del negocio.
También están aquellos equipos de operación encargados de dar continuidad a la infraestructura y los procesos, para quienes conocer acerca de la Nube y su tecnología subyacente es prácticamente mandatorio.
Está el área financiera que debe velar por los costes presentes y futuros que resultan de la operación, las licencias y los contratos por servicios.
También el área legal que debe velar que tanto servicios como procesos estén en línea con las regulaciones internas de la organización, y externas de las instituciones legales donde se esté desplegando.
Y por supuesto todas las áreas de negocios y de productos quienes son los encargados de la planificación a largo plazo y por ende deben tener un conocimiento base.
Por mi cuenta, he tenido la fortuna de trabajar en un par de programas de transformación digital hacia la Nube que requirieron la gestión de todos los puntos que he mencionado anteriormente, y otros pocos más. Y decidí escribir algo sobre esto y traspasara parte de mi experiencia en el Blog.
Principios de la arquitectura en la Nube
Soy fiel creyente de que la tecnología debe estar alineada con las necesidades del negocio en todo tipo de organización. El grado de alineamiento dependerá por supuesto del contexto en el cual se desarrollará el proyecto; la necesidad del negocio que debe ser cubierta, el presupuesto existente, y otros puntos más.
Actualizar soluciones World Class, infraestructura y redes de datos, o simplemente desarrollar aplicaciones debe responder a necesidades presentes y futuras cuya resolución irá en beneficio del requirente; y no ser un fin en sí mismo. Estoy dejando fuera algunos casos de borde como por ejemplo los proyectos normativos.
Es por lo dicho que la gestión de mis proyectos TI comienza con cuatro principios que, por homologación, aplican perfectamente para la Nube.
No están escritos en piedra, son simplemente una lista de buenas prácticas que me ha dado buenos resultados hasta hoy, y que tengo el placer de compartir en esta entrada.
1. Áreas involucradas y sus responsables
Una sabia decisión es tener a mano una lista de todas las áreas que participarán en el proyecto y el nombre de sus responsables. Si el proyecto o programa tendrá una duración mayor a 6 meses suelo armar una matriz de responsabilidades. En otros casos una simple lista bastará.
Involucrar a los responsables desde el inicio tiene muchos beneficios: se crea clima de equipo y de confianza que no se logra enviando correos con solicitudes; permite a los responsables organizar su calendario con antelación; se discute y alinean los distintos puntos de vista; se visibiliza las dependencias técnicas y humanas; se resuelven consultas y se toma nota de riesgos.
Tomar nota que menciono a todas las áreas involucradas. Puede que algunas no requieran participar en todas las reuniones, pero debiesen estar al menos en el kick off y copiadas en la comunicación. Especialmente las de «negocio«: muchas veces las dejamos afuera y luego aspectos legales y normativos nos bloquean e impactan la fecha de salida.
2. Requerimientos funcionales
Existen diversas maneras de llamarlos, no obstante, el objetivo es el mismo: la lista de las necesidades que serán cubiertas con los entregables del proyecto.
Una buena costumbre es revisarla junto al equipo técnico, tomar nota de las dudas y sugerencias que nacerán, para finalmente trabajar con los responsables del negocio en una nueva versión.
Esta revisión debe tomar un tiempo prudente que permita refinar los requerimientos prioritarios a la par de no impactar demasiado el inicio del diseño de alto nivel. En mi experiencia y para un proyecto de 6 meses, considero razonable al menos dos revisiones entre todos los equipos, durante 1 a 2 semanas máximo.
Aquellos requerimientos no bloqueantes y que requieran más tiempo deberán ser documentados, y en caso de ser necesario tomar acuerdos entre las partes. Lo perfecto es enemigo de lo bueno.
Durante la gestión del proyecto surgirán nuevas preguntas, e incluso nuevos requerimientos, lo que es totalmente normal. Las decisiones en esos casos dependerán del contexto y se deberá revisar caso a caso.
3. Aplicaciones e infraestructura en existencia
El mensaje aquí es no reinventar la rueda. Tomar debida nota de la infraestructura, servicios y aplicaciones productivas antes de comenzar el diseño de alto nivel que funcionará como base para lo que será implementado en la Nube.
Las dependencias, los requerimientos acordados, el presupuesto definido y las fechas requeridas condicionan sin lugar a dudas el producto final. ¿Tiene la actual arquitectura capacidad para soportar la nueva? ¿Qué es necesario re hacer y qué puedo continuar utilizando? ¿Tengo el presupuesto para desarrollar todo el diseño en mente? ¿Es necesario para cumplir los requerimientos?
Tengo consciencia de que este es un trabajo amargo, pero créanme, es absolutamente necesario. Como profesional siempre apunto a mejorar el estándar, y por lo mismo cuesta racionalizar que se debe conceder y muchas veces convivir con un híbrido que está lejos de satisfacernos.
No obstante, la realidad es que tiempo e inversión son finitos, y debemos diseñar en función a estas dos dolorosas verdades.
4. Tecnología en la Nube
Este punto lo aplico para proyectos de gran envergadura, donde se esté evaluando un recambio tecnológico ya sea de infraestructura, software, aplicaciones, o todos. Dicho esto, no provoca daño aplicarlo a cualquier proyecto y evaluar el resultado.
Aquí mi sugerencia es el análisis y documentación a muy alto nivel de la posible tecnología que se verá involucrada en el proyecto, validando que tanto el equipo TI (o la organización) están preparados para su aplicación.
¿Tenemos el conocimiento necesario en el equipo? ¿Serán requeridas nuevas licencias? ¿Está preparada la actual arquitectura para interactuar con la nueva? ¿Nuestra red será capaza de gestionar el aumento de tráfico? ¿Poseemos el nivel de seguridad suficiente requerido para transferir datos críticos?
En mi experiencia esta evaluación es necesaria antes del diseño de alto nivel. Dibujar el plano sin saber de si se contará con los materiales o el conocimiento puede dañar el proyecto a medio andar.
Consideraciones para soluciones nativas en la Nube
En los párrafos anteriores he cubierto aspectos generales, buenas prácticas si se quiere decir, que desde mi punto de vista y experiencia se debe tomar al iniciar un proyecto en la Nube.
Es posible que haya olvidado algún punto relevante (que gatillaría una actualización de esta entrada); o que simplemente no los haya desarrollado con la profundidad necesaria. No obstante, y para no convertir eso en un testamento, mi intención a partir de ahora es poner el foco en aspectos específicos y no tan generales.
¿Por qué son relevantes? Quienes hemos desarrollado o gestionado proyectos afines, sabemos que aplicaciones diseñadas específicamente para la plataforma donde serán ejecutadas son más eficientes que cuando no lo son. Aprovechar todas las capacidades que nos entrega la Nube requiere precisamente eso: diseñar pensando en ella, y olvidar paradigmas de otras arquitecturas como On Premises.
Una extensa lista de literatura cubre aspectos tanto generales como específicos del diseño, pero en esta entrada me voy a enfocar en los 5 que yo personalmente creo son imprescindibles.
1. Aplicación como una colección de microservicios desacoplados
Microservices para la Nube
La máxima que aplica a toda la arquitectura en la Nube es desacoplar, y el software no es una excepción. El patrón de diseño más eficiente hasta la fecha de esta entrada es crear tu aplicación como una colección de APIs.
¿Es mejor microservicios o serverless? Dejaré esta pregunta para más adelante, por ahora cuando hable de microservicio lo haré como referencia al concepto general de API.
Por definición los servicios propios de la nube están distribuidos en multitud de datacenters físicos de los cuáles ni siquiera sabemos su ubicación. Esto nos permite arquitecturas centralizadas donde atender al mayor volumen de usuarios posible, a la vez que copiamos lo esencial para de otros países puedan acceder a nuestra aplicación con la menor latencia posible.
Y el mayor rendimiento que se logra de consumir esta distribución es con microservicios desacoplados (loosely coupled). Esto es, el software y el hardware como un conjunto de pequeños servicios no dependientes entre ellos, que pueden ser modificados sin impactar a toda la aplicación.
Algunos de los beneficios:
- Mejoras en la productividad y el time to market. Piezas más pequeñas y desacopladas simplifican el desarrollo y la operación dado que pueden ser trabajadas de manera independiente. La simplicidad también trae beneficios reduciendo el tiempo requerido para salir a producción.
- Resiliencia. Al estar desacoplados, la caída de un servicio no necesariamente traerá como consecuencia la caída de toda la aplicación.
- Escalabilidad. Cada servicio puede estar creado en el lenguaje que más beneficios aporte sin necesidad de preocuparse de la compatibilidad. Se les asigna recursos propios y cada uno de ellos puede escalar independientemente cuando sea requerido.
- Eficiencia operacional. Un ecosistema de microservicios es más fácil de mantener que una aplicación monolítica donde todo está en una gran caja negra. Cada servicio puede ser monitoreado y actualizado de manera independiente.
- Reducción de costes. Por un lado, se requiere menos tiempo de desarrollo para liberar microservicios a nivel productivo. Por otro lado, sólo escalan (es decir, consumen más recursos) aquellos servicios que lo requieren, y no toda la aplicación.
2. Desacoplar y distribuir los datos
Data
Desacoplar los datos de la aplicación tiene los mismos beneficios descritos en el punto anterior más uno que hoy en día es crucial: velar por la seguridad y protección de la información de los usuarios.
Dependiendo de las políticas sobre datos de la organización, o del país donde opera, podría ser necesario una arquitectura de datos distribuida. Parte de la información será replicada globalmente sin mayor problema, mientras que el resto deberá almacenarse en el país de origen, o incluso dentro de un datacenter específico.
Al estar desacoplado los datos y su consumo, el lanzamiento global se torna más simple. Se distribuye el código y los datos posibles. El resto se aloja en un espacio que cumpla con las políticas de seguridad y se configura para que la latencia sea la menor posible para los usuarios.
3. Escalabilidad y Resiliencia
Load Balancer
Se debe tener claridad de cómo la infraestructura, los servicios y los datos se comunicarán entre sí para luego de analizado el comportamiento durante pruebas integrales y de estrés, se diseñe y aplique mejoras al comportamiento y estabilidad de la aplicación.
Debemos hacernos y respondernos preguntas tales como: ¿Qué sucede dentro de mi aplicación cuando es consumida por miles de usuarios concurrentes? ¿Cómo mejoro el acceso a datos que no puedo regionalizar? ¿Aquellos servicios críticos están escalando adecuadamente? ¿Cómo se está comportando la aplicación ante puntos de falla?
La respuesta a estas y otras pregunta permitirán diseñar el mejor plan de mejora a la aplicación. Algunas configuraciones comunes son: escalamiento de aquellos servicios que se ven impactados en horario punta y su posterior desescalada; fail over para todos los servicios críticos para la operación; puntos de recuperación para datos; que servicios y datos tengan la mínima latencia entre sí.
4. Monitoreo y Alertas
Métricas y Reportes
Una aplicación en producción no es el fin, sino el comienzo de una nueva etapa que requerirá constante mantención. Estar enterado de todo lo que ocurre dentro y fuera de ella, y tomar acciones correspondientes cuando es requerido es fundamental.
Una herramienta para lograr este cometido son los reportes con métricas claves, y las alertas para cuando algo fuera de lo común ocurre.
Una buena práctica es listar todo lo que medirá, diseñar las métricas que servirán para tal propósito y crear un reporte con ellas. El paso final es crear alertas automatizadas para que cuando alguna métrica esté por sobre o debajo del límite se apliquen de inmediato acciones correctivas.
Una enorme ventaja de la Nube es que, dado que todos los servicios nativos son eso: servicios; el monitoreo puede aplicarse literalmente a todo: infraestructura, servicios nativos, red, servicios de la aplicación, datos.
5. Seguridad
Seguridad
Para cualquier aplicación en la Nube la seguridad también debe ser una prioridad. Definir el conjunto de procedimientos de seguridad y la tecnología subyacente no debe entenderse como una capa o tarea más en el diseño de la aplicación. La seguridad debe ser parte del ADN de cada servicio de la aplicación.
Este punto en sí merece una entrada independiente por todo lo que involucra y conlleva.
Por ahora me permito compartir medidas básicas pero obligatorias tales como: jamás compartir la cuenta de administración; crear usuarios y grupos independientes para la aplicación y los equipos internos de la organización; remover privilegios generales y dar sólo los específicos para que funcione con normalidad; encriptar los datos almacenados y en tránsito; aplicar todos los mecanismos de seguridad que cada servicio nativo de la nube pone a disposición.
Y jamás, jamás compartir las claves.
6. Costos en la Nube
Costos en la Nube
Lo he dejado para el final, pero no por eso es el menos relevante. No es la primera vez que toco el punto, cree un par de entradas relacionadas tiempo atrás: Gestión de presupuesto infraestructura Cloud y Estrategias de costos para soluciones Cloud.
Crear reportes para costes incurridos tanto de infraestructura como servicios, y generar alertas que informen para cuando se supere el presupuesto es imprescindible.
Sobre todo, para las atribuladas áreas de Finanzas y Control de Gestión que querrán tener información en tiempo real al respecto.
Luego, utilizar la información de los reportes para proceder a optimizar costes también es fundamental.
Puede parecer poco pagar centavos por un servicio nativo. Pero si multiplicas tales centavos por cantidad de servicios, tiempo de uso y usuarios concurrentes, podrías llevarte una desagradable sorpresa al final del mes.
Conclusión
El tema me ha llevado más palabras de las que tenía pensadas; y aun así me quedo corto en todo lo que este tema da. Mientras sigo tomando cursos y preparo mis certificaciones, seguirá creando temas relacionados en entradas futuras.
Y para terminar, les dejo una lectura obligatoria para todo amante de la Nube: AWS Well-Architected. ¡Buena lectura!
Imágenes creadas por rawpixel.com fueron obtenidas en Freepik. Imágenes creadas por Pete Linforth, TheUjulala y Clker-Free-Vector-Images fueron obtenidas en Pixabay.