El otro día me hicieron esta pregunta, y más allá de los muchos tópicos, no supe argumentar suficientemente una decisión de semejante importancia.

Para decidir la necesidad o no de iniciar el traslado, en primer lugar hay que analizar las características del proyecto o, incluso, de la organización.

En el supuesto de un proyecto existente con la infraestructura “on premise”, parece lógico implementar una solución híbrida donde quizás, los backups se persistan en la propia infraestructura y además, en una servicio de terceros como Amazon S3 a través de Amazon Storage Gateway.

De esta manera, si tuviese lugar una catástrofe, se dispondría de la información necesaria para volver a empezar solucionado el “incendio”. Esto requeriría de un tiempo que podría ser minúsculo si además, disponemos de un entorno reducido en una nube pública, que podamos dimensionar en caso de caída de la infraestructura principal, redirigiendo el tráfico de forma automática.

Otra posibilidad es el traslado de las operativas menos importantes, dejando toda la capacidad de computación de nuestros CPDs para los procesos “CORE”

Para un proyecto nuevo, parece todavía más indicada la opción “cloud”, ya que disponemos de multitud de posibilidades para arrancar con unos costes muy reducidos, basados en arquitectura serverless, que nos permiten la modalidad de pago por uso.

Para esta opción, aparecen servicios como Lambda (funciones ejecutadas al ser lanzado un evento), S3 (almacenamiento a un precio reducido, con gran disponibilidad y durabilidad que además nos da la opción de funcionar como servidor de estáticos), Cognito (servicio de autenticación multidispositivo), DynamoDB (base de datos fácilmente escalable) o API Gateway.

Imaginemos además, que necesitamos implementar una solución altamente escalable y con gran disponibilidad a nivel de catástrofes, lo que requeriría de la existencia (y mantenimiento) de al menos dos centros de datos con capacidad “infinita”, independientes y lo suficientemente alejados. Además se hace indispensable el desarrollo de herramientas para su sincronización, la detección de errores en uno y el “arrancado” de los servicios en el otro, sin pérdida alguna de datos y/o funcionalidad. Diseñar algo así en la nube es sencillo y tiene unos costes ínfimos en comparación.

Todas estas funcionalidades están ya disponibles y testadas en plataformas como AWS, son fácilmente programables y nos permiten diseñar nuestra arquitectura de una forma reactiva para poder solucionar los problemas antes incluso de que se propaguen y afecten a nuestros usuarios.

Pero lo importante del traslado a una nube como Amazon no son sus servicios, si no el hecho de que, al estar dentro de una plataforma tan robusta, podemos empezar a pensar de una forma diferente toda nuestra organización. Desde la seguridad hasta la facturación (a través de tagging de recursos), pasando por la arquitectura de nuestras aplicaciones.

AWS nos da todas las herramientas para diseñar de forma eficiente la seguridad de nuestra nube, a nivel de redes (VPC, Security Groups, ACLs, …), a nivel de granularidad de permisos (usuarios/roles/grupos, policies logrando el fin de las credenciales), encriptación de datos sensibles (KMS, gestión de claves, servicios de almacenamiento con encriptación, …) y lo hace dándonos todas las garantías posibles a nivel de compliance y cumpliendo con los máximos estándares exigidos en el sector (https://d0.awsstatic.com/whitepapers/aws-security-whitepaper.pdf)

Sería fácil decir que empresas como Spotify, Netflix, HSBC o Apple confían en AWS para almacenar su información, pero el hecho de que el gobierno de los Estados Unidos disponga de su propia región para instituciones como la NSA o la CIA, muestran el grado de confianza que podemos depositar en la compañía de Seattle.

A nivel de seguridad, es importante nombrar dos servicios, CloudTrail que nos permite auditar cada movimiento dentro de la plataforma y CloudWatch, que nos ayuda en la creación de alertas, facilitando la automatización de tareas para poder ser reactivos ante errores, ataques, picos de tráfico o accesos no deseados.

Una vez superado la posible desconfianza a nivel de seguridad, aparecen herramientas de DevOps que facilitan el desarrollo y la integración contínua de grandes proyectos compuestos por multitud de equipos. Por ejemplo, CloudFormation nos permite diseñar nuestras infraestructuras y plasmarlas en un JSON, lo que facilita el versionado y el apagado/encendido de entornos “clon” aumentando la previsibilidad de los despliegues. Existe además la posibilidad de añadirlas a un catálogo (AWS Service Catalog) de soluciones “disponibles” para la organización, forzando a los equipos a utilizar arquitecturas validadas por una entidad superior.

Obviamente, AWS dispone de multitud de servicios para trabajar con contenedores (EC2 Container Service), automatizar despliegues (CodeStar, CodePipeline, …) y gestionar las configuraciones o tareas (OpsWorks, Config, …)

Todos estos servicios, como indicaba anteriormente, nos ayudan a la hora de diseñar una solución de software desacoplada, robusta y elástica que diste mucho de los tradicionales monolitos acercándose más al idílico mundo de los microservicios, mucho más manejables, funcionales y mantenibles. Si necesitas ayuda de como manejar tu computadora puedes visitar https://store.hp.com/mx-es/default/tech-takes/como-puedo-capturar-la-pantalla-en-mi-pc.

Evidentemente, todo dependerá de la tipología del cliente, sus proyectos (existentes y futuros) y el presupuesto disponible, pero apostar por AWS es hacerlo por una plataforma líder, que cada año evoluciona sus productos y servicios a una velocidad y con un nivel de calidad que nos sería imposible imitar en nuestra propia organización.