AWS Summit Barcelona 2015

No suelo viajar mucho por trabajo pero, desde que trabajo en Crononauta, siempre subo a Barcelona varias veces al año. Y además de trabajar, esta vez hemos aprovechado para asistir al AWS Summit 2015 Barcelona.

El evento de Amazon Web Services, tuvo lugar durante todo la jornada del Jueves 5 de Noviembre en Fira de Barcelona, Montjuïc. Nunca había estado en Fira Barcelona, con lo cual me impresionó el edificio, el salon de actos principal y toda la organización del evento. Especialmente el catering, que me pareció muy bueno. La calidad de la comida era bastante buena, y en ningún momento faltó de nada. En todo momento había snacks, zumos, agua, café y bollería.

En cuanto al evento, el AWS Summit Barcelona fue inaugurado por Guillem Veiga, Head of AWS en Iberia, con una breve introducción de todo lo que íbamos a poder ver durante la jornada.

AWS re:Invent 2015

Luego vino Jeff Barr, el Chief Evangelist de AWS; que muchos lo conocemos ser quien administra y publica en el blog de AWS. Quién mejor que él, que lleva 13 años trabajando en AWS, para contarnos cómo ha ido evolucionando AWS a lo largo de estos años. Entre otras cosas nos contaba cómo en 2007 AWS sólo contaba con tres servicios (EC2, RDS y S3), y actualmente en 2015 cuentan con más de 50 servicios, operando en 11 regiones diferentes. Jeff fue dando paso a ponencias como la de Luis Bosque de CartoDB, que nos explicó cómo funciona CartoDB, el volumen de datos que manejan y por qué decidieron migrar a AWS; o los chicos de BEEVA que nos enseñaron su proyecto de Big Data con algoritmos de Machine Learning para ofrecer información útil a sus clientes sobre ventas de artículos por zonas, o incluso ventas de productos relacionados con su sector.

AWS Security

A continuación vino Bill Murray, pero no el actor de cine, sino el director de AWS Security. Lo que más me llamó la atención de su ponencia fue la presentación de un nuevo producto llamado Amazon Inspector que, de momento, está en "preview" y sólo está disponible en la región US West (Oregon).

Amazon Inspector te permite analizar el comportamiento de las aplicaciones que ejecutas en AWS y te ayuda a identificar fallos potenciales de seguridad.

Básicamente te permite instalar un agente en las instancias EC2, para poder
ejecutar una serie de checks que te ayudarán a comprobar la seguridad de tu
plataforma. Bill nos enseñó algunos checks básicos como el login SSH con root.

Una vez se ejecutan estos checks, te permite realizar un análisis general de la seguridad de la plataforma.

De momento este servicio está algo limitado, porque
los agentes sólo pueden ser instalados en Amazon Linux AMI 2015.03 (o
posteriores) o Ubuntu Server 14.04 LTS, de momento.

Todo lo que necesitas saber sobre Autoscaling

Seguro que si has trabajado ya sobre AWS, esto ya te suene de algo, o al menos ese era mi caso. Realmente el tema de Autoscaling es un servicio, sin coste adicional, que ofrece AWS dentro de EC2; y que permite que tu infraestructura escale horizontalmente, siempre y cuando esté preparada para ello, claro está.

Realmente, que una plataforma pueda escalar horizontalmente, no sólo depende de que configuremos o no el Autoscaling en EC2. Para que una plataforma pueda escalar horizontalmente debe estar bien diseñada, tanto a nivel de sistemas, separando los servicios / stack de software de forma inteligente; como a nivel de código, porque la aplicación también debe estar preparada para escalar.

Si tenemos bien resuelta esta parte, AWS nos proporciona los componentes
necesarios para escalar nuestra aplicación de forma más o menos sencilla,
configurando los siguientes componentes:

• Launch Configuration: permite definir la "template" de instancia EC2 que vamos a arrancar, en caso de que necesitemos auto escalar. Podremos definir qué AMI queremos usar, almacenamiento,
  security group, etc.

• Auto Scaling Group: permite crear un grupo de Autoscaling basado en un Launch Configuration.
  Básicamente podemos definir el número mínimo de instancias en el grupo de auto escalado, número máximo de instancias, zonas de disponibilidad sobre la que vamos a operar, si queremos añadir las instancias bajo un balanceador o ELB (Elastic Load Balancer), etc.

• CloudWatch Alarms: CloudWatch es el servicio de monitorización de AWS. Es un servicio que no supone coste adicional, siempre que no activemos el Detailed Monitoring. Nos permitirá monitorizar nuestro Autoscaling Group, y en base a las alertas que configuremos, nuestra plataforma será capaz de lanzar nuevas instancias cuando sea necesario. Por ejemplo, podremos arrancar un par de instancias más en el caso de que el uso de CPU del grupo de Autoscaling supere el 80% durante 10 minutos, y volver a eliminarlas cuando la CPU del Autoscaling group baje del
  40% durante 15 minutos.

Últimamente he trabajado mucho con esto, así que seguramente le dedique un post donde pueda entrar más en detalle.

Gestionando Containers a Escala

En esta Live Demo se presentaba el servicio EC2 Container Service, que
permite desplegar, gestionar y escalar contenedores Docker donde ejecutar aplicaciones, servicios o simplemente scripts para realizar cálculos.

En mi caso aún no tengo muchos conocimientos sobre Docker, pero si has trabajado con él, te facilitará la gestión de clusters de contenedores en varias instancias EC2. Aunque si esto no te gusta siempre puedes montar Docker desde cero en una instancia EC2.

La demo que hizo el ponente era desplegar una página web sencilla dentro de un cluster Docker. Podéis desplegar esta aplicación de ejemplo desde el Dashboard de ECS.

ECS básicamente te abstrae de todo lo referente a la administración de Docker, y te permite definir un cluster en unos cuantos pasos sencillos. Durante estos pasos puedes elegir la memoria asignada a cada contenedor, mapeo de puertos que se suele hacer en Docker, usar un ELB (balanceador) para el cluster, e incluso definir la cantidad y tipo de instancias EC2 en las que queremos alojar el cluster.

En mi caso me apunto estudiar este servicio, porque la verdad es que los
conocimientos que tengo de él son bastante básicos.

Despliegue Continuo en AWS

En esta Live Demo se presentaban tres servicios: AWS CodeCommit, AWS
CodePipeline y AWS CodeDeploy. Estos tres servicios están dentro de la categoría de Developers Tools y permiten alojar código fuente, Integración Continua y deploy de código, respectivamente. A decir verdad me perdí la demo de los dos primeros, pero pude asistir a la de AWS CodeDeploy.

CodeDeploy permite desplegar código fuente de forma relativamente sencilla. En muy resumidas cuentas, este servicio se basa en tener
un agente ejecutándose en cada una de las instancias y, una vez configurado un Deployment Group, es posible especificar una URL hacía un fichero zip alojado en un Bucket de S3 o repositorio Github. Mediante un fichero de configuración, que debe ir dentro del repositorio de código, podremos indicar al agente dónde desplegar el código, o incluso ejecutar comandos tras realizar el deploy, en un post-hook.

CodeDeploy permite configurar cuándo un deployment se considera "ok" o "fallido".

• One at a Time: se considera un deployment fallido si falla en al menos una de las instancias del Deployment Group.
• Half at a Time: se considera fallido si falla en la mitad de las instancias del Deployment Group.
• All at Once: se considera deployment fallido si falla en todas las instancias del Deployment Group.

Quizás una de las cosas que no me convencen de CodeDeploy es que se necesita tener un agente con un puerto abierto en cada instancia, lo cual puede añadir un punto de fallo en cuanto a seguridad; y que, si no estoy equivocado, no tiene opción de rollback. Si algo va mal, la única opción es volver a desplegar una versión del código que sepamos que funciona bien.

Utilizando Spot Instances de Amazon EC2

Las spot instances han avanzado mucho desde que fueron introducidas por primera vez. Normalmente el precio las instancias EC2, al margen del tipo de instancia que se elija con más o menos recursos; varia en función del modelo de compra de la instancia. Puede ser On Demand, Reserved, o Spot Instances

Las instancias On Demand son las de uso más común. Simplemente cada tipo de instancia en la modalidad de On Demand tienen un precio fijo. Si arrancas una instancia On Demand sabes que el precio que AWS te cobra es el especificado en la documentación, y el coste total dependerá del tiempo que esté esa instancia en modo Running.

Pero también existe la modalidad de Spot Instances. Para no hacer muy pesada la explicación, básicamente consiste en fijar el precio que te gustaría pagar por un tipo de instancia, y en el momento en que el precio de mercado esté por debajo del precio que hayas establecido, podrás arrancar instancias de ese tipo a ese precio. Es como jugar a bolsa, cuando las acciones caigan por debajo de un umbral de dinero, compro acciones.

La modalidad Spot Instances es muy llamativa a la hora de aplicarla con un Autoscaling Group, pues podríamos conseguir ahorros bastante significativos, arrancando Spot Instances cuando el precio caiga, y mientras tanto seguir usando On Demand.

Amazon Elastic Filesystem

Amazon Elastic Filesystem es uno de los servicios que llevo esperando mucho tiempo. De momento, no está disponible en Ireland pero espero que lo estrenen en Europa de aquí a unos meses.

Uno de los principales problemas a resolver cuando trabajas en una
infraestructura con escalabilidad horizontal, es la compartición de ficheros entre instancias. Hasta ahora mucha gente se ha configurado su propio cluster NFS, GlusterFS, e incluso he llegado a ver soluciones que usan un Bucket S3 junto con s3fs, lo cual me parece muy arriesgado, porque se ha demostrado que no funciona muy bien. Precisamente esto es lo que viene a resolver EFS.

Al igual que con el resto de servicios, podremos abstraernos de la creación del cluster de ficheros y del storage de éste. En pocos minutos podemos contar con un punto de montaje con varios Terabytes y con una SLA muy alta. Este servicio realmente se basa en NSFv4. Estoy deseando poder probar este servicio en algún proyecto, hacer pruebas de carga y ver si realmente funciona tan bien como se espera, o si tendré que seguir usando mi propio cluster de GlusterFS para compartir ficheros entre instancias.

Y creo que esto es todo, la verdad es que mola mucho asistir a este tipo de
eventos, porque no todo es resolver tickets, leer documentación, gestionar
alertas y atender clientes. En este tipo de charlas siempre se abre un poco la mente, sobre todo escuchando las experiencias de los demás, en este caso con AWS.

En breve escribiré posts relacionados con Amazon Web Services, y espero poder entrar mucho más en detalle.

Un saludo!