AWS Cloud Adoption Framework: perspectivas técnicas.

¡Bienvenidos de nuevo! Continuamos completando el análisis de la propuesta de Cloud Adoption Framework de AWS.

Recapitulando un poco, el framework está propuesto por seis perspectivas que serán objetivo de nuestra evaluación para determinar nuestro estado en cada una de ellas y proponer, en caso de ser necesario, acciones que nos lleven a la visión recomendada. En el primer post diseccionamos las tres primeras perspectivas: Business, People y Governance. Estas áreas de trabajo están relacionadas con la visión y estrategia de negocio.

En este post nos centraremos en las tres siguientes perspectivas: Platform, Security y Operations. Estas tres áreas tienen un contenido eminentemente técnico, y medirán nuestra capacidad para ejecutar convenientemente nuestras aplicaciones y servicios en la nube de AWS. Si hacemos un paralelismo con el CAF de Azure que analizamos en post anteriores, el conjunto de estas perspectivas dará lugar a la Landing Zone y establecerá su modelo operativo.

Perspectiva Platform

En la primera de las perspectivas técnicas, analizamos la preparación de nuestra organización para describir y diseñar arquitecturas orientadas a la nube. La visión que perseguimos es que tendríamos que ser capaces de entender los distintos componentes y servicios que nos ofrece AWS para definir la arquitectura de nuestras aplicaciones sobre ellos. Deberemos conocer los principios y patrones que rigen los despliegues bajo AWS para ponerlos al servicio de nuestras necesidades.

Como ya hablamos en la perspectiva People, disponer de equipos formados en estos servicios (o requerir de servicios profesionales que dispongan de ellos) es muy importante. Para enfrentar con conocimiento los planteamientos necesarios de esta etapa del análisis, podemos tomar como referencia las certificaciones de AWS Solutions Architect Associate y Solutions Architect Professional.

Las capacidades en las que se desglosa la perspectiva hacen referencia a los bloques básicos con los que se puede construir una aplicación y sostener un servicio. Es importante que entendamos la diferencia de funcionamiento entre infraestructuras on-premise y su contrapartida en la nube. De esta manera, detectaremos brechas de conocimiento o procedimientos internos que debemos revisar.

Vamos a enumerar cada uno de estos bloques:

1. Computación. En este punto pondremos el foco en entender las diferencias entre el modelo de provisionamiento de un data center local y los recursos creados en la nube. Mientras antes debíamos dimensionar exhaustivamente las capacidades requeridas y lanzar las compras de servidores físicos, ahora contamos con la posibilidad de crear y utilizar procesamiento de manera prácticamente instantánea. Para comenzar, será más fácil hacer paralelismo entre nuestras máquinas físicas y las máquinas virtuales creadas en la nube, pero no debemos dejar de lado que disponemos de otros modelos de procesamiento y computación que han despegado con los servicios en la nube. Estamos hablando de los enfoques Serverless. Si te interesa profundizar en este tipo de servicios, aquí te contamos por qué ha llegado el momento de reemplazar servidores por código y aquí cómo llevar Cloud y Microservicios a la máxima potencia.
2. Red. Al igual que ocurre con la computación, la topología de nuestra red pasará de componentes mayormente físicos (hubs, switches y routers) a dibujarse de manera lógica mediante redes virtuales. Es importante comprender las distintas topologías con las que podemos diseñar nuestra Landing Zone, ya que es un planteamiento importante que suele decidirse en las etapas iniciales. Aunque el CAF no menciona ninguna topología en particular, podéis ampliar la información en distintos whitepaper de AWS. Os recomendamos leer las opciones de conectividad entre redes virtuales (VPC) y cómo construir topologías de red escalables y seguras. Podéis encontrarlos aquí y aquí respectivamente.
3. Almacenamiento. Bajo este epígrafe, volveremos a centrarnos en entender las diferencias entre el modelo de gestión de las necesidades de almacenamiento en nuestros entornos locales frente al provisionamiento en la nube. En ella nos alejamos de los conceptos SAN o NAS para estar orientados a servicios de almacenamiento de bloques o ficheros (blobs). Es importante conocer la diferencia entre estos tipos de almacenamiento en la nube, cuándo podemos utilizar cada uno de ellos y cómo sacar partido del coste reducido del almacenamiento en blobs. Lo mejor en este caso es recurrir a la propia documentación de los principales servicios de almacenamiento de AWS. EBS para el almacenamiento de bloques (documentación aquí) y S3 para el almacenamiento de blobs (documentación aquí).
4. Bases de datos. Las habilidades necesarias para el manejo de bases de datos gestionadas en la nube son diferentes a las que necesitamos cuando nos encargamos de ellas en entornos on-premise. Sin ir más lejos, la alta disponibilidad de base de datos on-premise suele precisar de conocimiento específico y no está exento de dificultades a la hora de ponerlas en marcha. Todas estas funcionalidades están de partida cuando desplegamos una base de datos en la nube de AWS, por lo que podemos centrar el conocimiento de nuestros equipos en el rendimiento y patrones de uso. Es importante que conozcamos cuándo podemos aplicar los principales tipos de bases de datos que nos ofrece AWS. Cuándo debemos, y qué ventajas tiene sobre el resto, una base de datos relacional, una NoSQL o un Data Warehouse. Los servicios destacados que representan respectivamente cada una de estas categorías dentro de AWS son: RDS, DynamoDB y Redshift.
5. Aquitectura. Al igual que en el resto de bloques, debemos actualizar nuestros conocimientos para el manejo de servicios en la nube. Desde el punto de vista de la arquitectura, también tenemos que conocer qué servicios son los más adecuados para construir las soluciones de nuestra empresa. En AWS contamos con distintos servicios que, compuestos de la forma adecuada, responden a los mismos requisitos técnicos. Sin embargo, no todos escalan igual, ni tienen el mismo coste, ni se les tiene que dedicar el mismo esfuerzo operativo. Los arquitectos también deben profundizar en cuáles son las arquitecturas de referencia ante requisitos comunes para tomarlas como punto de partida. Lo mejor en este caso, como mencionamos anteriormente, es abordar alguna de las certificaciones específicas para arquitectos de AWS (Solutions Architect Associate y Solutions Architect Professional).
6. Desarrollo de aplicaciones. Por último, el framework nos conmina a evaluar nuestra metodología y arquitectura de software. Se pone énfasis en resaltar que la agilidad en el despliegue de infraestructura debe ir acompañada de patrones de desarrollo que los faciliten. Como anotación personal (no recogida en el CAF) me permito añadir que las aplicaciones que se despliegan en la nube deberían responder a ciertas características como las que se recogen, por ejemplo, en The Twelve Factor App.

Perspectiva Security

Si avanzamos en las perspectivas del framework, la siguiente será la perspectiva Security. Es un error pensar que toda la seguridad de nuestra infraestructura corre de la mano de AWS. De este proveedor corre la seguridad perimetral de sus instalaciones, el acceso físico a los Datacenter o la redundancia de los suministros. Sin embargo, los servicios que ponemos en marcha y su configuración caen bajo nuestra responsabilidad. AWS ha ido avanzando y nos facilita ciertos aspectos. Por ejemplo, la visibilidad por defecto al crear un almacenamiento S3 no permite lecturas públicas. Sin embargo, este tipo de configuraciones por defecto de los servicios no son suficientes y debemos manejarlas explícitamente.

Las capacidades de esta perspectiva se dirigen a evaluar si conocemos todas las herramientas para construir una seguridad adecuada y acorde a los riesgos de cada uno de los activos de la compañía. Repasemos cada una de ellas:

1. Identidad y gestión de accesos. La piedra angular de la seguridad será conocer qué mecanismos de identidad pone a disposición AWS y cómo poder establecer las políticas de acceso. Veremos que somos capaces de articular buenas prácticas, como la del mínimo privilegio posible, o integrar la identidad de AWS con la existente en la organización (federación). El servicio fundamental que debemos conocer y sobre el construir toda la estrategia de identidad será AWS Identity and Access Management (IAM).
2. Observabilidad. Bajo esta capacidad se integran los servicios de logging y supervisión de AWS. El objetivo es que conozcamos cómo podemos conseguir una visión holística en casi tiempo real de lo que está ocurriendo en nuestra nube. No solo se habla de logs, sino de cómo somos capaces de correlacionar con otro tipo de eventos para potenciar la visibilidad de lo que ocurre y, por tanto, reaccionar de la forma más rápida posible. En este punto empezamos la toma de contacto con los servicios Amazon CloudWatch y Amazon CloudTrail.
3. Seguridad de la infraestructura. Si en el primer punto cubríamos la identidad y el acceso de los usuarios, en este punto se cubre la seguridad de los servicios desplegados en sí. Es fundamental conocer qué políticas de seguridad podemos articular en cada uno de los servicios que utilizamos, para así adaptarlas a nuestras necesidades u obligaciones de la legislación vigente. Existen configuraciones más generales, como la segmentación de redes y su conectividad con las redes públicas (Internet), pero también específicas del servicio concreto como las url prefirmadas de S3 o el cifrado de los datos en reposo de RDS.
4. Protección de la información. Esta capacidad hace referencia a las posibilidades de trabajar la observabilidad, no desde el punto de los servicios (capacidad número dos de las perspectiva), sino de la información que en ellos se almacena. Tenemos que conocer que podemos ser capaces de monitorizar accesos a determinada información o etiquetar datos personales que necesitan un tratamiento específico. Este punto, como el anterior, es especialmente relevante si estamos sujetos a legislación específica en este sentido (GDPR).
5. Respuesta ante incidentes. El último punto de esta perspectiva nos invita a evaluar los procesos para responder ante amenazas, mitigándolas y reduciendo el daño que estas provoquen si llegan a producirse. También será importante contar con conocimientos para realizar análisis forenses que nos permitan identificar áreas de mejora que se incorporen a un procedimiento de fortificación iterativa. Una lectura interesante para este punto es el Marco de seguridad cibernética NIST​​ (CSF por sus siglas en inglés) y cómo aplicarlo bajo AWS.

Perspectiva Operations

Llegamos a la última de las perspectivas técnicas, Operations, que aborda el conocimiento de la organización para poder ejecutar, usar, mantener y recuperar los servicios acorde a los niveles exigidos por la organización y, en última instancia, por sus usuarios finales. Resalta la necesidad de ese flujo de retroalimentación que permita ir adaptando los servicios conforme a los cambios de nuestros requisitos de negocio. El fin último es que nuestra plataforma siempre esté alineada a la consecución de los objetivos definidos, y no sea una fotografía estática de lo que servía en el pasado.

Las capacidades que estructuran esta perspectiva son las siguientes:

1. Monitorización de los servicios. Será fundamental conocer los mecanismos de monitorización existentes para responder de forma proactiva a problemas de salud (disponibilidad) o rendimiento de nuestros despliegues. Así como, una vez detectados, lancen las automatizaciones para solucionarlos, minimizando (incluso eliminando) el impacto en la experiencia de nuestros usuarios. Volveremos a apoyarnos en el servicio central de monitorización de AWS Amazon CloudWatch.
2. Monitorización del rendimiento de las aplicaciones. Si en el punto anterior hablamos de servicios, en este punto se trabajan las aplicaciones que se ejecutan sobre ellos. Es importante conocer cómo medir el rendimiento de las aplicaciones, puesto que puede no estar relacionado con la infraestructura de servicios subyacente y precisar de correcciones diferentes (cambios en el código). Para ello, podemos evaluar las soluciones de AWS como AWS X-Ray.
3. Gestión del inventario de recursos. Aunque no queda muy claro en el nombre de la capacidad, lo que intenta ponerse de manifiesto es la importancia de gestionar correctamente los costes dentro de la infraestructura en la nube. Habrá que desarrollar las competencias necesarias para conocer los modelos de ahorro en el uso de los servicios (ej. reserva de instancias), o conocer cómo escoger adecuadamente el tallaje de los servicios. El objetivo de esta capacidad es dar el mejor servicio al coste más eficiente posible.
4. Gestión del cambio. Bajo esta capacidad analizaremos nuestra competencia para gestionar, planificar y ejecutar cambios dentro de este nuevo entorno de la nube y cómo acercarlos, si no lo hacemos ya, a enfoques de entrega continua o despliegue continuo. Para profundizar en el ecosistema ofrecido por AWS para estas tareas, podemos consultar AWS CloudFormation y AWS CodePipeline.
5. Informes y analítica. En este punto se podrá abordar la integración y explotación de las métricas que obtenemos de nuestro entorno en la nube para medir nuestros KPIs o acuerdos de nivel de servicio (SLAs). Además, tenemos la posibilidad de explotar un nivel más fino de granularidad a la hora de imputar costes debido al modelo de pago por uso asociado a la nube.
6. Continuidad del negocio/Recuperación ante desastres. Abordamos un punto que, según mi experiencia, no está correctamente desarrollado en algunas organizaciones. Se trata de responder a la pregunta de si seríamos capaces de recuperarnos en caso de un fallo de gran envergadura en nuestro servicios IT y cómo lo haríamos, cuánto podríamos estar sin servicio (RTO) y qué pérdida de información podríamos asumir (RPO).
7. Catálogo de servicios IT. La última de las capacidades evalúa nuestras habilidades para seleccionar los servicios acorde a los SLA y requisitos que queremos cumplir. Está íntimamente ligada al portfolio de cargas de trabajo que analizamos en la perspectiva Governance, puesto que el despliegue de las mismas debe hacer uso del conjunto de servicios definido en nuestro catálogo.

Con esto hemos terminado el recorrido por las perspectivas del CAF. Es un buen momento para reincidir en que el objetivo de este tránsito es determinar qué le falta a nuestra organización para reducir riesgos e incorporar estas nuevas tecnologías y, una vez detectadas esas carencias, elaborar un plan de acción o roadmap de actividades concretas que nos permitan solventarlas.

Esperamos que esta serie de posts os hayan ayudado a tener una visión integral del Cloud Adoption Framework de AWS, así como entender la utilidad de aplicarlo en vuestros primeros pasos a la hora de trabajar en la nube. Seguiremos compartiendo nuestras experiencias y análisis sobre estas metodologías en próximos post. ¡Nos leemos pronto!