Adentrándose en la nube con Amazon Web Services (AWS) y Cloud Computing

Es curioso el revuelo generado por el Cloud Computing desde hace un par de años, y los servicios SAAS. Si eres un programador web como nosotros, inicialmente te sorprendería cómo la gente comenzó a ver el valor a algo que tú, como programador web, hacías desde hace tiempo: ¿acaso no llevabas programando en “la nube” desde hace tiempo? “Cliente -> Servidor”, si eso lo enseñaban en la carrera…

Sin embargo, uno de los avances más impactantes, a mi parecer, no ha sido en la programación en la nube, sino en la aplicación del cloud a las arquitecturas físicas. El verdadero genio fue el que juntó los servicios Cloud con la posibilidad de virtualizar máquinas. La posibilidad de crear y usar máquinas en la nube ha sido el que ha permitido desarrollar servicios escalables “con solo pulsar un botón”. A ese yo le daría el Premio Nobel de Tecnología (que por cierto, no existe). Quizás me equivoco si digo que el primero fue Amazon, pero no me equivoco si digo que es el más avanzado en cuanto a funcionalidad y usabilidad.

Qué es Amazon Web Services

Amazon Web Services (AWS) es un conjunto de servicios orientados al cloud computing (y por tanto, escalabes), siendo los más conocidos S3 y EC2. S3, Simple Storage Service, es un servicio de almacenamiento remoto que permite a desarrolladores almacenar información ilimitada, y tener un control sobre ésta. EC2, Elastic Cloud Computing, te permite crear máquinas virtualizadas de forma sencilla para montar la estructura de tu servicio en la nube sin necesidad de utilizar ningún servicio físico. Lo bueno de ambas soluciones es que Amazon te cobra por uso. Puedes despreocuparte de quedarte escaso de Gigas, ya que si te pasas, lo único que se verá afectado será tu bolsillo, no tus clientes.

Personalmente, lo que más me gusta de la solución es que fue ideada por programadores para programadores (bueno, más o menos). Es decir, Amazon inicialmente no pensó en revender ese servicio, lo usaban internamente para su estructura de servidores; pero viendo lo bien que le funcionaba a ellos, ¿por qué no abrirlo al resto de programadores, que seguro que tienen la misma necesidad?. Y acertaron.

Servicios que ofrece AWS

Los servicios que ofrece AWS son servicios aplicados al cloud computing; siempre orientados a la escalabilidad. La interacción con ellos se hace generalmente vía API (inicialmente) y cuando el servicio progresa, se hace una interfaz en un panel de control (útil para los más nuevos). Los servicios que ofrece AWS son cada días más numerosos. Hace pocos meses (desde la escritura de este post) se lanzó, por ejemplo,  el servicio Route 53.

A continuación se listan los servicios más destacables:

• Amazon S3: Tu disco duro en la nube, es uno de los servicios estrella de Amazon. Está orientado al desarrollador, de modo que en nuestra aplicación podamos guardar algunos ficheros en un disco, externo a nuestras máquinas e ilimitado. Es posible controlar los permisos de los ficheros que se suben mediante políticas de acceso. Además, se puede acceder a los ficheros mediante acceso http, por ejemplo: http://myfiles.s3-website-us-east-1.amazonaws.com/fichero.txt. Esto permite que guardes todas las imágenes de tu website en un servidor de alta disponibilidad externa a tu máquina ec2.
• EC2: el otro servicio estrella de Amazon, permite gestionar virtualizadas, creando una estructura de servidores “elástica”. La creación de dichos servidores se puede hacer manualmente (mediante el panel de control) o mediante la API. Con este último, por tanto, es posible automatizar la creación de servidores, añadiendo así servidores temporales que realicen tareas puntuales y destruirlos después (y por tanto, abaratando costes).
• RDS: el EC2 llevado a la base de datos. Aunque todavía beta, es un servicio muy potente. Con este servicio, es posible crear una MySQL o una Oracle con un par de clicks. Lo mejor de todo, es que están automatizadas todas las tareas de backup y mantenimiento. Además, con un par de clicks es posible generar un esclavo, o elevar la potencia de la máquina y/o generar y recuperar instantáneas. Tareas de mantenimiento que generalmente son costosas para recursos de administradores de sistemas, se simplifican gracias a este servicio.
• Elastic Load Balancing: dentro de EC2 existe la funcionalidad de ELB, un balanceador que podrás configurar en pocos minutos.
• Elastic IP: servicio para el mapeo de IP fijas a máquinas EC2.
• CloudWatch: servicio de monitorización y alarmas en función de métricas. El Cloudwatch básico no tiene coste adicional, y está basado en que se recuperan el valor de las métricas cada 5 minutos. El Cloudwatch avanzado tiene un coste adicional a cambio de tomar métricas cada minuto. No es nada espectacular, pero la posibilidad de configurarlo en minutos y no tener que instalar tu propio servidor de monitorización, no tiene precio.
• Route 53: servicio de DNS con la escalabilidad y disponibilidad que solo Amazon puede ofrecerte. Quizás algo caro (un euro por gestión de un dominio al mes), pero están en ello.

Existen más servicios, pero para adentrarnos en el mundo del Cloud Computing, los aquí comentados no están nada mal para empezar…

Breve ayuda e introducción para los iniciados

A continuación, me gustaría indicar un listado de comentarios / reflexiones / pequeños apuntes que pueden ser interesantes para el recién iniciado. Esas cosas que te gustarían que alguien te explicara antes de haber empezado de cero (y antes de pagar por tus errores, claro).

• Regiones: toda estructura de Amazon está dividida en regiones. Las regiones son arquitecturas físicamente INDEPENDIENTES entre sí. Puedes montar máquinas en una u otra región, pero no puedes crear máquinas en una región y migrarlas a otras. Son independientes, y eso hay que tenerlo en cuenta. Hay cinco regiones disponibles: dos en USA (una por costa), una en Irlanda, otra en Tokyo y otra en Singapur. Es buena idea tener una máquina en una región y algún clon en otra; pero para ello, tendrás que copiar la AMI de una a otra. Aquí te explican cómo hacerlo (no es fácil).
• Diseña tu aplicación de forma escalable: es decir, en una aplicación apache, php y mysql, lo normal es que el apache y el php vayan en una máquina y MySQL en otra. De esta forma, si el problema es el procesamiento del servidor, podrás escalar el frontend. Si el problema es la BD, podrás escalar (mediante maestros y esclavos, o sharding) el backend. Nunca montes Apache+PHP y Mysql todas en una misma máquina.
• AMI: La AMI es una imagen virtual de Amazon. Cuando se crea una máquina virtual en EC2, se hace partiendo de una AMI (por ejemplo, una AMI con centos y con apache, mysql y php instalado). Una vez que arrancas la máquina en base a una AMI, puedes personalizarla como lo harías con otra máquina (descargando más software, instalando tu aplicación, etc), y luego crear otra AMI (es necesario detener la máquina para hacer una AMI). Esa AMI que crees puede ser privada. Con dicha AMI, podrías entonces crear réplicas exactas de tu servidor para añadir por ejemplo frontends de tu aplicación. De ese modo, tu frontal es escalable de forma fácil.
• Cobro en EC2: te cobran por máquina existente (bien en estado parada o bien arrancada). Es decir, te cuesta lo mismo tener una máquina parada, que una máquina arrancada. Por ello, si utilizas una como entorno de preproducción, es mejor que utilices una máquina, hagas lo que quieras, y si no la vas a usar, la destruyas. Cuando quieras volver a probar algo antes de pasar a producción, vuelve a crear el entorno de preproducción con la AMI.
• Elastic Load Balancing: pon todas tus frontales de producción detrás de un ELB. Y mapea en tu DNS este ELB, no la IP de las máquinas EC2. 
• IPs fijas y dinámicas: ¡muy importante! cada máquina EC2 tiene una IP dinámica, con lo que NUNCA debes mapear la IP de una EC2 en tu DNS. Para ello, puedes utilizar el ELB o usar Elastic IP. Con Elastic IP te asignas una IP fija y la asocias a una máquina EC2. Así solucionas el problema.

OJO: Aquí Amazon tiene un grave inconveniente que aún no ha sabido o podido solucionar de forma elegante. NO es posible asociar una IP fija con el ELB (probablemente por su estructura interna, o porque no quieren hacerlo, aunque no lo sé). Esto hace que tu mapeo en el DNS de tu dominio sea a través de un CNAME con el nombre del ELB, en vez de con una A a la IP fija. En principio no parece haber ningún problema, excepto por una limitación muy importante derivado de los DNS: las zonas APEX de un dominio (es decir, las que no son subdominio, “tudominio.com” en vez de “www.tudominio.com”), no pueden mapearse con un registro CNAME, con lo que estás vendido. La solución de amazon es que utilices su servicio DNS, Route 53, con el que sí puedes hacerlo. Y recordad: a un euro el dominio. Algo sospechoso este asunto…

• EBS vs Instance Store: Al crear una máquina en EC2 es importante saber si la AMI en la que te basas es EBS o Instance Store. EBS es un volumen lógico por el que pagas, pero es permanente. Puedes parar la máquina, destruirla, y luego volver a crear otra, y montar el EBS. Con esto, los datos almacenados en la partición EBS perdurarán. Sin embargo, en una AMI basada en Instance Store, no puedes pararla, ya que si la paras, los datos se perderán para siempre (pero puedes reiniciarla). Todo tiene sus pegas y sus inconvenientes. Además, la Instance Store por defecto es de 160 Gb (más o menos) y la EBS de 10 Gb. Aunque a priori no se puede parar la máquina, es posible hacer una AMI de una instance store con un truco especial, aun con la desventaja de que la AMI puede ser inservible si el sistema está modificándose.

Mi sugerencia: si los datos de cada frontend son volátiles (no pasa nada si se borran), usa una Instance Store, que tiene 160 Gb. Adáptala y crea una AMI para tu servidor. Monta tu servidor en base a dicha AMI, y haz que los usuarios la utilicen, mientras utilizas la primera para desarrollo. Cuando quieras actualizar la estructura de la aplicación (versión de PHP, etc), hazlo sobre la máquina de desarrollo y genera la AMI  a partir de esta; probablemente no tendrás problemas, ya que no está casi en uso. Luego, genera un nuevo servidor en base a esa AMI, y destruye la actual de producción. Ah, utiliza siempre Elastic Load Balancing para que el cambio sea transparente.

	Ventajas	Inconvenientes
EBS	Permanente. Se puede crear una AMI on-the-fly, o lanzar una réplica. Se puede parar	Solo 10 Gb, más caro.
Instance Store	160 Gb, más barato.	Volátil. NO se puede crear una AMI on-the-fly (de forma fácil), o lanzar una réplica. No se puede parar.

• Documentación: la documentación es muy completa. Pero lo que es una virtud, a veces es un defecto, ya que tienes que leer mucho antes de hacer. Te sugiero que leas, leas, leas, y cuando sepas, hagas. A no ser que te sobre el dinero, o no te preocupes por cometer errores. El tema de EBS o Instance Store, por ejemplo, es clave para la evolución de tu plataforma. Si has decidido mal, volver a empezar (reconfigurar tus servidores) puede causarte mucha molestia. Toda la documentación de todos los servicios AWS lo tienes aquí, en principio, no necesitas más, créeme.
• Soporte: Aaay, el soporte. Mi pensamiento inicial era “soy un cliente que paga por un servicio, debería tener un soporte algo personalizado”. Pues no, olvídate. Todo el servicio personalizado que vas a tener (sin pagar cuota adicional) lo vas a tener en los foros de amazon. Eso sí, son completos y un extenso knowledge base por si te encuentras en situaciones que otros usuarios ya se han encontrado. Ese será tu primer punto de acceso. Incluso puedes tener suerte y que alguien oficial de Amazon AWS te conteste. Pero no cuentes con ello. Si para tu negocio es indispensable que alguien oficial de AWS te conteste, piensa en pagar algo a partir de los 50 euros mensuales que cuesta el servicio básico. Si tienes un servicio web que funciona, tampoco parece una cifra descabellada.
• Migración de tu servicio actual: si tu servicio actual es un servicio básico con apache con php y mysql  y buscas un entorno escalable y fácil de manejar, amazon puede ser tu solución. Puedes comenzar creando una EC2 y usando una RDS, y en un día, tener tu entorno preparado. Posteriormente, puedes comenzar a revisar las posibilidades de escalado mediante ELB y nuevas máquinas. Y por último, revisar las posibilidades de maestro / esclavo que vienen en la RDS. También puedes hacerlo todo a la vez, pero tardarás un mes en controlar todas las posibilidades. Eso sí, antes de lanzarte a producción, asegúrate que entiendes bien el funcionamiento de tu EC2, y si puedes pararla o no, y qué ocurre en caso de terminarla.
• RDS: Aunque el servicio esté en beta, yo considero que la opción MySQL funciona muy bien; no tanto la Oracle, como leo en los foros (no he probado esta última). La opción MySQL nunca me ha dado ningún problema (o si lo era, era causa mía). Un entorno RDS con maestro-esclavo se puede configurar en unos minutos y es una auténtica gozada olvidarse de los backups. Sabes que se están haciendo, y no tienes miedo de lo contrario.
• Multi AZ Deployment: si tu RDS se estropea en una región, estás vendido, ya que pierdes la disponibilidad de tu aplicación. Para solucionarlo, existe la opción de pagar algo más por la opción Multi AZ, que lo que hace es tener una instancia en standby en otra región. Si tu RDS se estropea, automáticamente se switchea a la otra región. La pregunta que te puedes hacer es ¿tengo que pasar eso para quedarme tranquilo? Todo es cuestión de probabilidades.

En este caso, yo considero que los usuarios pagan por un servicio que debería estar incluido en Amazon. Es decir, si mi instancia RDS se estropea, entiendo que es por culpa de Amazon, y por tanto, es Amazon quien tiene que ofrecerme esa solución sin coste adicional. No entiendo cómo deja en manos del usuario decidir si quiere esa solución, y a mayor coste (que por cierto, el coste no es pequeño).

• Mails: ojo con el envío de mails. Si tienes un servicio que envía notificaciones vía mail, verás cómo los sistemas empiezan a marcar tus mails como SPAM, o incluso nunca salgan. Esto es debido a que las IP de Amazon están blacklisteadas, ya que pueden haber sido usadas por spammers en la anterioridad. Para evitar esto, Amazon creó el servicio Simple Email Service. Implica utilizar su propia API para el envío de mails. La forma más fácil es cambiar el sendmail o postfix para que utilice la API por debajo, y olvidarte así de cambiar la lógica de programación (que es lo que odiamos los programadores)

Otras soluciones

Como veis, Amazon AWS es un servicio espectacular, completo e incluso asequible, para crear tu aplicación escalable de forma sencilla. Sinceramente, y puedo estar equivocado, creo que está a años luz de otros competidores. Por una razón muy simple: fue el primero, y ellos lo usan intensivamente. Es una solución para ellos que abren al mundo. Y por eso funciona muy bien.

Sin embargo, hay arquitecturas en las que,  por diversas razones, Amazon no es una opción. Por ejemplo, si necesitas un proveedor más cercano, alguien con el que poder hablar de tú a tú. O un servicio más personalizado. O donde necesites saber, por ley, dónde están los servidores y quién accede a ellos. Para ello, hay otros proveedores españoles que tienen soluciones iguales de potentes, quizás no tan completas, pero muy sólidas. En INIT, por razones como éstas, hemos tenido que optar por proveedores más cercanos en algún proyecto, y nos gustaría destacar especialmente el servicio CloudBuilder, de Arsys.

Cloudbuilder tiene la ventaja de ser un servicio mucho más sencillo y directo que Amazon. Amazon es más complejo y tiene el inconveniente de que no puedes preguntar a alguien directamente “oye, que pasa si hago esto…”. En Arsys tienes la opción de preguntarlo, y además el panel es mucho más intuitivo. Y otro punto a favor: te informan de todo lo que implica un gasto, algo que Amazon no hace. Sin embargo, no existen opciones como el RDS, pero tiempo al tiempo…

Conclusiones

Está claro que hoy en día, el futuro de las arquitecturas está en la nube. No tiene sentido, si no eres un ISP, comprar un hardware que puede que quede obsoleto en poco tiempo. O incluso para un servicio que quieres probar que puede que no dure más de dos meses porque no tienes éxito.

Hoy en día la nube está de moda, pero está de moda, porque es útil. Y barata. Mi consejo es que te subas a la nube, ya lo decía Alaska en Fangoria.

Y si necesitas ayuda, indícanoslo y aquí te echamos un cable. Para eso estamos.