Ya puedes tener la estrategia de marketing mejor del mundo, la mejor campaña publicitaria, los mejores anuncios. Unas publicaciones excelentes en blogs, una gran inversión en SEM, o un SEO de contenidos inmejorable. Que si la infraestructura informática subyacente no acompaña de poco servirá. Aquí es donde entra el estar o no en la nube. Y nunca mejor dicho, poner tu aplicación web por las nubes.
Lo mismo digo en el otro sentido, una gran infraestructura informática sin buenos contenidos, diseños, blog, SEM, etc.. de nada serviría tampoco. Sería como un desierto muy muy grande, en el que sólo se mueven las bolas corredoras del desierto.
Conjunto de servicios abrumador
En Amazon Web Services (AWS), tenemos un conjunto abrumador de servicios que engloban todo lo que una empresa mediana o grande pueda necesitar. Incluso también una pequeña empresa, porque caro no es si se gestiona bien. Y así se puede dotar a la pequeña empresa de un sistema informático que a la larga podrá crecer con su negocio. Si ponemos entonces el sistema informático en la nube, éste sistema informático no será el cuello de botella. Es decir, el sistema informático no será lo que impida nunca el crecimiento de una empresa. Cosa que puede pasar desapercibida fácilmente si no se le da la importancia que tiene.
Empresas de la talla de Netflix, Nokia, Adobe, NASA, Securitas Direct.. están en AWS. El gran Facebook comenzó también en AWS, hasta que necesitó de tal cantidad de servidores que le salía más barato montar sus propios edificios repletos de ellos. Creando sus propios data-centers y se desligándose de AWS. AWS son los pioneros y líderes del mercado de la nube. Tiene un gran ecosistema, calidad, simplicidad y unos precios indudablemente competitivos. No pretendo hacer una comparativa porque no conozco otras nubes tanto como para hacerlo. Pero si buscas tener una visión global de lo que hay en AWS éste es tu post.
Una buena infraestructura no es suficiente, pero sí necesaria
Como decía antes, puede pasar desapercibida la necesidad de mejorar la infraestructura. Es difícil detectar los límites que tiene una web, cuántos usuarios concurrentes aguanta, peticiones por segundo, cantidad de productos a la venta ¿permite tener miles, decenas de miles, o centenas de miles de productos tu infraestructura informática?
Los especialistas en SEO a esto le llaman la técnica de: ¡Corre, Forrest, corre! Cuanto más rápido y más aguante tu web, mejor indexará, y mayores adquisiciones orgánicas tendrá.
Veamos un caso de estudio. A la derecha tenemos la repercusión en el ranking de Alexa de aplicar estas mejoras en un proyecto.
Puede ser que tengas una web responsive y unos contenidos excelentes, ahora toca indexar todo eso y aguantar el rastreo a lo bruto que te van a hacer los crawlers (Google, Bing, Yahoo, etc..). Si tienes miles de productos, puedes enfrentarte a rastreos de centenares de miles, o millones de peticiones en una hora. Esto no es tonteria, dale la importancia que tiene porque repercutirá en tu puntuación para salir en los resultados de búsquedas.
En el siguiente gráfico tenemos las visitas orgánicas, es decir, las visitas que vienen de búsquedas en buscadores (pure SEO). Podemos ver la subida de visitas de Navidades como es normal. Después se publicó en la nube de AWS en abril una nueva versión del proyecto. Y tras 3 meses de ajustes, la aplicación web empieza a poder absorber el 100% de los rastreos de los famosos crawlers. Y cómo no, las visitas orgánicas comenzaron a subir y a subir.
Claro, no bastaría con haber puesto una infraestructura buena, también hace falta un buen contenido que crawlear.. de igual manera que no basta un contenido bueno si luego los crawlers te tumban la web. No puede haber una cosa sin la otra. Insisto en esto, ya que muchos se obcecan simplemente en el SEO de contenidos. Pero a día de hoy, en el SEO influyen todos los elementos que pueda tener un website. Todo influye desde el contenido y las imágenes, pasando por los comentarios de los visitantes, hasta llegar a la infraestructura informática.
Volviendo al grano, hermano ¿de qué disponemos en esta nube?
Nada más entrar nos encontramos con el abrumador abanico de servicios disponible en AWS. De un vistazo podemos darnos cuenta de que si algo se puede hacer en una nube, en AWS se puede hacer, por supuesto. Tenemos desde el servicio básico de gestión de dominios de Route 53, creación de redes virtuales en VPC, pasando por la creación manual de servidores EC2. Macroservidores de envío de emails SES con los que enviar por ejemplo 12 emails por segundo.
Así como también servicio de recepción de emails con WorkMail. También podemos lanzar servidores de bases de datos clásicas relacionales con RDS. Bases de datos en memoria como Redis o Memcached mediante ElastiCache. Sistemas de almacenamiento de archivos muy económicos como S3. O sistemas de archivos extremadamente rápidos pensados para compartir ficheros entre cientos de servidores como EFS. Podemos tener en marcha una red de distribución de contenidos o también llamado CDN con muy pocos clics en CloudFront. CloudFront es un CDN de calidad y muy económica. Es muy potente de configurar poniendo como orígenes de datos sistemas de ficheros S3, balanceadores, o directamente orígenes de datos externos a AWS.
Siguiendo con herramientas de gestión de códigos fuentes Git con CodeCommit. Podemos desplegar tanto máquinas como códigos fuentes con nuevas actualizaciones con el clásico OpsWorks. Y claro cómo no, también podemos trabajar con el famoso Docker. Tenemos Chef, una tecnología muy asentada con la que podemos automatizar incluso la creación de servidores (esto es material para otro post). Cortafuegos avanzados que pueden desencadenar eventos en otras partes del sistema con WAF. Los nuevos certificados de seguridad gratuitos del Certificate Manager para ponerlos en balanceadores o CloudFront..
Y un largo, muy largo etcétera..
Resumiendo, si alguien está haciendo algo en Internet, también se podrá hacer en AWS. Una vez se comprenden los sistemas informáticos, es bien sencillo gestionarlos en AWS. No hay más que buscar entre el mar de documentación que nos dan, aprender lo que necesitas y ponerlo en marcha. A ver, no es trivial, pero sí que es sencillo de poner en marcha muchos de los servicios. Una vez se tiene la base de conocimientos de para qué sirve cada cosa, y qué tecnologías intervienen, la gestión en AWS se ha simplificado de forma que en pocos clics y pocas configuraciones tenemos montado el sistema informático.
Mucho material académico
Cómo se monta alguno de los servicios es contenido como para ir presentando y resumiendo en otras entradas del blog. Jeje, ya tengo contenido para ir escribiendo, a ver si tengo tiempo y me pongo con ello. Voy a saltármelo y me remito a la documentación oficial que es excelente, otro pilar básico del gran éxito que tiene AWS:
Así que mejor sigamos con un caso de estudio viendo resultados..
Una visión global de estado
Una vez puesto en marcha un sistema, tendremos que supervisarlo. A modo de ejemplo, aquí presento si no lo conoces a CloudWatch. Con un simple vistazo podemos estar tranquilos, o no. Podemos configurar alarmas que lancen notificaciones por email, por ejemplo. En caso de que la base de datos no esté disponible, si los servidores llevan mucho tiempo consumiendo casi el 100% de la CPU, etcétera. Aquí tenemos el dashboard de un proyecto de una aplicación web sobre un Magento:
Los picos pueden dar problemas, se ve una clara periodicidad diaria del uso de todos los sistemas. El sistema está estable en ésta última semana, aunque han habido unos picos de errores en el CloudFront. Esto puede deberse a despliegues de nuevas versiones de la aplicación, habría que investigarlo..
Como he dicho este sistema corre un Magento. Tenemos delante de todo el sistema un CloudFront, en el que se configura un CDN para ir cacheando ciertos archivos, distribuyéndolos por todo el mundo según de donde vengan las peticiones al sistema. Un balanceador de carga (ELB de Elastic Load Balancer), que distribuye las peticiones entre los servidores subyacentes que tienen el citado Magento. Dichos servidores atacan a una base de datos tolerante a fallos en RDS, se trata de un Mysql. Además este Magento tiene la cache de back puesta. Tiene el turbo mediante Redis. Esto agiliza las consultas de datos guardando en memoria RAM los datos. Así se libera Mysql y podemos tener un Mysql mucho más pequeño que el que recomiendan para Magento.
S3 y EFS, depende de para qué
Los ficheros compartidos entre los servidores se montaron inicialmente sobre S3, más económico pero peor rendimiento que EFS. Posteriormente se montaron los ficheros compartidos en EFS, 10 veces más caro aunque por la cantidad de ficheros no llegó a ser realmente caro. No necesita cargar en RAM para ser rápido, con una latencia de lectura/escritura de ficheros excelente. Con EFS se aumentó el rendimiento de Magento brutalmente. Porque Magento tiene la peculiaridad de que hace lecturas de ficheros cada vez que navegas por el catálogo. Es decir, con cada clic, si estamos viendo 30 miniaturas de productos en la categoría de productos, podemos necesitar hacer 30 lecturas/escrituras de ficheros antes de devolver la web al navegador. Esto es algo peculiar que con otros CMSs no había visto, y puede desembocar en 30 creaciones de fichero en un sólo clic.
Esto fue un cuello de botella resuelto con S3 guardando en RAM los ficheros. Cuello que al pasar a EFS nos lo evitamos por completo. Estamos hablando de 2 segundos de latencia en la primera carga de ficheros en S3, frente a 2 milésimas aproximadamente de latencia en con EFS.
Curiosamente, Magento va generando miniaturas de las imágenes al vuelo. Y si lo haces sobre S3 no se parece en nada a la velocidad que puedas tener con EFS. Si tienes este problema ya te he dado la solución. Es decir, que si tienes que andar constantemente leyendo y escribiendo ficheros en la aplicación que estés, dale EFS. Si no es el caso, S3 podría ser la mejor solución.
Terminando
Ya me he extendido demasiado de nuevo, escribiendo otro testamento de los míos. He citado muchos conceptos, demasiadas siglas, me disculpan. AWS es muy extenso, y espero que no haya quedado muy espeso todo esto. Espero haber podido dar buena visión global de AWS. Si por lo menos has llegado hasta aquí abajo ya es un logro que me estés leyendo. Así que ¡gracias!
¡Un saludo!
