Devops, microservicios, autoescalado y desarrollo de apps: las claves del éxito de Amazon.

Después del resumen del AWS Summit Madrid 2016 y de avanzar lo que se contó en las charlas Innovación en el mundo Enterprise y Agilidad en Cloud, en el post de hoy hablaremos de Go! Build!, otra de las sesiones paralelas donde se profundizó en cómo se ve en Amazon el perfil de desarrollo y DevOps, cómo se crea una aplicación a gran escala y cómo se puede desarrollar una aplicación móvil con AWS.

“DevOps en Amazon: Un vistazo a las herramientas y procesos”

Aunque existe una gran controversia sobre el concepto Devops, en la conferencia quedó bastante claro lo que significa este término para Amazon: “un conjunto de metodologías que permite a los equipos trabajar de forma más cercana entre ellos, aportando mayor agilidad al proyecto y notables incrementos de productividad, que pretenden dar agilidad y responder a las necesidades del flujo de desarrollo, optimizando los procesos de desarrollo, tests, despliegue, resolución de bugs, paso a producción, monitorización…”.

Generalmente estas metodologías se implantan gracias a una cultura Devops, donde una persona (en ocasiones varias) dentro del grupo de trabajo se encarga de implementar dichas mejoras en forma de automatizaciones, nuevas herramientas de despliegue, de control de versiones, monitorización, etc.

Para entender la importancia que tuvieron para Amazon estas prácticas, hay que entender otro punto fundamental de su éxito: la refactorización de la arquitectura de su sitio web.

• Del monolito a los microservicios

En 2001 el market de Amazon se basaba en una arquitectura monolítica. A medida que la empresa creció, esta arquitectura sobre la que todos sus desarrolladores tenían que realizar modificaciones se volvió inmanejable. El equipo de trabajo rondaba las cien personas y la organización a la hora de mergear los cambios de todas ellas era una locura.

De esta forma, lo que en principio definieron como el merge friday pasó a convertirse en el merge week o en las merge wars. Esto contrajo la imposibilidad de avanzar en los desarrollos, la paralización de los despliegues, los cuellos de botella, los conflictos de código…
La solución a esta problemática era clara: plantear una arquitectura basada en microservicios. De esta forma, se dividió el código de la web en muchas primitivas independientes comunicadas vía API. El equipo de cien personas se dividió en muchos equipos de aproximadamente ocho personas, cada uno de ellos responsable de un microservicio.

• Devops: imprescindible para escalar

Uno de los problemas que tenía Amazon es que había gran cantidad de equipos de desarrollo, pero sólo un equipo de despliegue. Aquí es donde entra en acción la cultura Devops. Para poder gestionar tal cantidad de microservicios era necesaria una herramienta “self service” para automatizar el proceso de despliegue cada vez que uno de los equipos incluyera cambios. Tenía que ser agnóstica de plataforma, con gestión de versiones, que incluyera un testeo previo (tests unitarios) y posterior (tests funcionales) al despliegue y, a ser posible, que pudiera gestionar automáticamente el rollback de la aplicación en caso de error. Así fue como surgió hace 13 años la herramienta Apollo, cuyo hijo (AWS CodeDeploy) dota de una gran salud y está disponible para los usuarios de AWS.

Tras automatizar el proceso de despliegue, cada uno de los microservicios dispuso de su propio pipeline de despliegue. De esta forma, el principio divide y vencerás tuvo más sentido que nunca.

• Resultados de la evolución

Las cifras eran claras: de gestionar un equipo enorme, con versiones del producto lentas y poco fiables, pasaron a disponer y desplegar múltiples entornos productivos con releases mucho más frecuentes, testeadas y, por lo tanto, más fiables, llegando a alcanzar los 50 millones de despliegues en producción al año (aproximadamente un despliegue cada segundo y medio), aunque hay que tener en cuenta que son despliegues de funcionalidades muy pequeñas.

Creo que, tras esta conferencia, quedó claro que la agilidad y los microservicios han sido unos aliados fundamentales para Amazon. En mi opinión, tanto el principio de divide y vencerás como la agilidad, aplicados a los proyectos actuales, son fundamentales para que una empresa sobreviva. Sin ellos el time to market se eterniza y en una economía global eso es inadmisible.

“Aplicaciones a gran escala: Cómo servir a millones de usuarios”

La segunda de las conferencias trató sobre el crecimiento natural de una aplicación, desde sus comienzos, pasando por el nivel de prueba de concepto o piloto, hasta que consigue servir a millones de usuarios. Estas charlas resumieron la propuesta de AWS para gestionar este crecimiento, no sólo con la herramienta de auto escalado de AWS, sino también planteando una arquitectura que en efecto sea compatible con dicho escalado.

• ¿Auto escalado? Primero revisa tu arquitectura

Una de las funcionalidades más importantes de AWS es la de auto escalado, tanto si se requieren más recursos, como si lo que se quiere es reducir el uso de los mismos. Este servicio permite al administrador de sistemas elegir un threshold por encima (o por debajo) del cual escalar un grupo de instancias. Esta funcionalidad es muy útil, pero también puede resultar peligrosa si, por ejemplo, no se controla el número de instancias máximas del grupo de escalado.

Antes de escalar una aplicación hay que tener en cuenta el número de usuarios y si la arquitectura de la misma está preparada (o necesita) dicho escalado. Es decir, en ocasiones, una simple modificación de la arquitectura del servicio puede librarnos de configurar la funcionalidad de auto escalado.

Normalmente, para un uso no intensivo de una aplicación (prueba de concepto, piloto…), se suele partir de una arquitectura básica como la de la imagen, basada en Amazon Route 53 para la resolución de DNS, una IP elástica y una única instancia de EC2 con el código y servicios que necesite la aplicación instalados en la misma instancia.

Antes de migrar esta arquitectura, se puede valorar el cambio de tamaño de la instancia. Amazon Web Services tiene en este punto una gran variedad de opciones para nuestras instancias, optimizadas para un uso más intensivo de CPU, almacenamiento, memoria…

Esta evolución de un tipo de instancia a otra sería el primer paso, pues todavía es de suponer que no hay necesidad de un mayor uso de recursos. Una máxima en Amazon es “consume lo que necesites”, ni más ni menos (pues pagarás por lo que consumas).

El siguiente paso suele ser extraer la base de datos de la instancia de la aplicación a una instancia separada. Para este paso podemos elegir si queremos montar nosotros mismos la base de datos dentro de la instancia (self managed) o bien elegir una de las múltiples opciones que ofrece Amazon a tal efecto:

1. Amazon RDS
2. Amazon DynamoDB
3. Amazon ElastiCache
4. Amazon RedShift

También puede ser útil en este momento el servicio de Amazon Database Migration, que ayuda al usuario a migrar la base de datos sin pérdida de servicio de la misma a Amazon Web Services. También permite migrar de un tipo de base de datos a otra, (Oracle a MySQL p.e.) o incluso migrarla a Amazon Redshift desde Aurora, PostgreSQL, MySQL, MariaDB, Oracle o SQL Server.

Antes de seguir creciendo, hay que replantear la arquitectura de forma que sea tolerante a fallos. Generalmente todos los servicios suelen tener momentos de indisponibilidad, pero una arquitectura en alta disponibilidad con varias instancias en varias zonas de disponibilidad diferentes suele reducir estos periodos hasta prácticamente desaparecer. Además, al plantear una arquitectura redundante, la carga se suele balancear desde un balanceador externo al servidor de la aplicación, paso que facilita la posterior configuración del auto escalado.

En caso de que aún así la base de datos siga siendo el cuello de botella, habría que plantearse escalar horizontalmente la base de datos, creando un cluster de base de datos con un master, varios esclavos e incluso varias réplicas de sólo lectura en caso de que nuestro servicio necesite muchas lecturas a base de datos.

Si los tiempos obtenidos siguieran siendo bajos, se puede plantear ofrecer el contenido del portal a través de la CDN de AWS (Cloudfront), usar los servicios de Elasticache para reducir los accesos a la base de datos o bien guardar los datos de sesión en una base de datos externa NoSQL.

Llegados a este punto, la arquitectura de nuestro servicio estará lo bastante madura y la demanda habrá ido creciendo con la arquitectura de forma que tenga sentido recurrir a la funcionalidad de auto escalado de AWS. Es importante recordar que esta funcionalidad puede añadir o borrar máquinas del tipo que le hayamos indicado y por lo tanto toda la información de sesiones, datos de usuario, etc… debería guardarse fuera del grupo de servidores que se quiere que escale automáticamente. De ahí la importancia de los pasos previamente comentados.

• Ahora sí: auto escalado

La funcionalidad de auto escalado permite modificar los recursos de un cluster de máquinas definiendo el tamaño del pool de máquinas (tanto el mínimo como el máximo) y las zonas de disponibilidad en las que se quieren distribuir las máquinas.

Amazon dispone de gran variedad de servicios que pueden ayudarnos a la gestión de este tipo de despliegues:

1. AWS Beanstalk: Permite, a partir del mismo repositorio de código, desplegar el servicio y administrar el equilibrio de carga, escalado automático, monitorización… Está pensado para aplicaciones y servicios web desarrollados en Java, .NET, PHP, Node.js, Python, Ruby, Go y Docker.
2. AWS CloudFormation: Posibilita el despliegue de infraestructuras mediante el uso de plantillas.
3. AWS Opsworks: Para configurar aplicaciones mediante Chef. Se puede definir la arquitectura, y para cada componente, los recursos necesarios, paquetes a instalar, configuración, almacenamiento, automatización del escalado, etc.

Los que asistimos a esta conferencia salimos de ella con sabios consejos sobre cuándo usar y cuándo no la funcionalidad de auto escalado, dependiendo de la demanda de nuestra aplicación y la madurez de nuestra arquitectura. Sin duda, lecciones muy útiles para nuestro día a día.

“Desarrolla y prueba tu aplicación móvil más rápido en AWS”

La última de las conferencias trató sobre las distintas problemáticas que el desarrollo de aplicaciones móviles conlleva, y los servicios que ofrece Amazon como respuesta a las mismas.

Algunos de estos problemas son:

1. Configuración y gestión de las librerías necesarias según las funcionalidades requeridas.
2. Problemas con el soporte multiplataforma y multidispositivo.
3. Gestión de las notificaciones.
4. Aumento progresivo de la complejidad de la aplicación.
5. Gestión de los picos de crecimiento de demanda una vez en producción la aplicación.
6. Gestión de los datos de usuario para la obtención de métricas de negocio.

En esta conferencia nos mostraron los distintos servicios con los que AWS ha respondido a todas estas necesidades. El pilar fundamental, la consola única que integra el acceso a todos estos servicios concebidos para facilitar el desarrollo de aplicaciones móviles, es AWS Mobile Hub.

• Mobile Hub

Uno de los primeros retos al que se enfrenta un desarrollador de aplicaciones móviles es la integración y configuración de los distintos servicios que permiten añadir funcionalidad a la aplicación. Mobile Hub permite gestionar de forma eficiente y cómoda (en una única consola) la problemática surgida en cada etapa del desarrollo (configuración, construcción de la aplicación, test y monitorización).

Como se puede observar en la imagen anterior, desde la consola de AWS Mobile Hub hay que elegir las distintas funcionalidades con las que queremos dotar a nuestra aplicación, y a continuación elegir “build”. De esta forma, Mobile Hub descarga un paquete de código (para iOs o Android) con las librerías necesarias, de forma que el desarrollador ya tiene todo preparado para empezar a desarrollar la aplicación sobre ese esqueleto.

Muchas de las funcionalidades que permite añadir Mobile Hub son llamadas a otros servicios de Amazon (no todos concebidos específicamente para el desarrollo de aplicaciones móviles). Por ejemplo:

1. La gestión de la identidad, mediante el registro de usuarios y la sincronización de los datos de usuario entre distintos dispositivos, se realiza gracias a Amazon Cognito.
2. Las notificaciones utilizan el Amazon Simple Notification Service (SNS).
3. Para habilitar la lógica de backend, se puede usar AWS Lambda.
4. Cuando la aplicación necesita que los contenidos del portal lleguen a los usuarios de forma rápida y eficiente se necesita AWS Cloudfront.
5. Para el análisis de los datos de los usuarios se pueden exportar los mismos a Amazon Redshift o simplemente Amazon S3 y se puede utilizar AWS Mobile Analytics para la realización de un análisis más pormenorizado de las métricas que se consideren más importantes.

Estas son sólo algunas de las funcionalidades que ofrece Amazon, pero los creadores de aplicaciones móviles también se pueden beneficiar de otros servicios de Amazon como son el Auto Scaling para la gestión de picos de demanda y alta disponibilidad de la aplicación, todas sus opciones de almacenamiento o gestión de base de datos, etc.

Una vez desarrollada la aplicación, existe el tremendo problema del aseguramiento de la calidad de la aplicación. En el mercado hay actualmente miles de dispositivos móviles para cada uno de los sistemas operativos disponibles. Para colmo, los terminales no suelen ser en absoluto baratos.

A la hora de probar la aplicación, el creador de la misma debe plantearse qué dispositivos va a comprar para las pruebas. Para evitar esta elección y el consiguiente desembolso de dinero, AWS ha sacado al mercado AWS Device Farm que permite probar, de forma automatizada (mediante el uso de conocidos frameworks de testeo de aplicaciones como Appium, Calabash, etc), la aplicación en los distintos dispositivos. Permite interactuar con los dispositivos, realizar capturas de pantalla en momentos determinados del test, la realización de pruebas manuales... Para mayor comodidad del desarrollador, se pueden realizar estas pruebas desde la propia consola de Mobile Hub. Por otro lado, AWS Device Farm dispone de plugins para Jenkins, lo que facilita la integración continua en el proceso de mejora y resolución de bugs.

En definitiva, gracias a AWS Mobile Hub los desarrolladores de aplicaciones móviles pueden centrarse en el diseño y desarrollo de las funcionalidades de la aplicación, olvidándose de algunos de sus problemas principales, como son la gestión de librerías, el heavy lifting y las pruebas multidispositivo.

Personalmente no me gusta tanto la tendencia de AWS de acaparar cada vez más nichos dentro del proceso de creación de un producto. Por otro lado, los servicios que diseñan no suelen fracasar. Como compañía tienen una gran facilidad para empatizar con sus usuarios y ofrecerles productos muy útiles y adaptados a sus necesidades. Supongo que gracias a esto han llegado a ser el gigante digital que son en la actualidad. Sin duda, su historia y recorrido nos sirve para aprender y mejorar.