Por qué todo lo que subo a azure está mal

Hoy he venido contaros mis experiencias ayudando a diferentes empresas en la subida de sus aplicaciones a azure, y concretamente a azure PaaS. Así que en realidad no son mis experiencias, son las de esas empresas. Y si soy totalmente sincero, no son sus experiencias, en realidad de lo que os voy a hablar es de sus quejas.

Este documento corresponde con el guión realizado para dar la charla de "Por qué todo lo que subo a azure está mal" para la Global Azure Bootcamp de 2018. Si lo prefieres, puedes ver el vídeo de la charla en este enlace.

Un poco de historia

Dejad que os cuente una pequeña historia:

una pequeña historia

Todo empezó en 1981, cuando nací. Aquí en Madrid. Desde entonces he estado muy cerca de los ordenadores. La década de los 90 mi padre me estuvo enseñando C++. Ahí estaba yo con Visual Studio y las Microsoft Foundation Classes. Sin entender muy bien exactamente por qué se dibujaba un botón en la pantalla.

El caso es que aunque mi vida es muy divertida, en realidad lo que hoy nos interesa es la experiencia que puedo aportar en azure. Esto empezó en 2010, cuando aún lo llamábamos Windows Azure. El portal de gestión estaba hecho en una tecnología llamada a “petarlo” en programación web como es… era Silverlight. Ahí conocimos los storages y cloud services. Nos peleamos con el auto escalado usando Wasabi y en relidad todo era mucho más difícil que ahora.

Por ahí por el 2015 Microsoft nos propuso a Tokiota colaborar con ellos en unas jornadas que servían para ayudar a otras empresas a subir a sus aplicaciones a azure. Y ahí es cuando realmente empezamos a pelearnos y a aprender con retos de todo tipo, que hoy veremos.

El camino a la nube

Supongo que todos los aquí presentes habrán hecho alguno de los tutoriales de la extensa y a la vez excelsa documentación que Microsoft tiene a nuestra disposición en internet. Todo funciona genial. Creo que la primera vez que escuche eso de “azure nos obliga a programar bien” fue a Gisela Torres. En una charla no muy diferente de esta. Y es verdad. Esto está genial. Pero no cuando ya tienes una aplicación desarrollada que no ha sido pensada para ser subida a la nube, la cosa cambia.

el camino a la nube

Así que decidimos hacer un “ABC”. Una especie de metodología, guía o industrialización de las migraciones que estábamos realizando. Y lo llamamos “el camino a la nube”. Lo simplificamos de tal manera que lo resumimos en 4 sencillos pasos.

Básicamente se trataba de conseguir que las aplicaciones de estas empresas fueran escalables horizontalmente. Así que nos fijamos solo en los recursos:

Si teníamos resueltos estos casos ya estábamos listos para poder subir a la nube… ¿o no?

Empiezan los problemas

Nuestro camino a la nube se había visto muy eficaz en la migración de muchas clases de WebApps, pero fue justo entonces cuando comenzaron los problemas. Las compañías a las que ayudábamos estaban poniendo sus aplicaciones en producción en la nube, estaban empezando a investigar por su cuenta y a tomarse licencias fuera de lo que nosotros considerábamos como una mera prueba de concepto. Un pequeño empujón que les ayudaría a usar los servicios PaaS de azure.

empieza los problemas

Nuestros desarrollos internos funcionaban genial. Es más, en Tokiota no tenemos servidores, usamos azure. Y estábamos muy contentos con la calidad del servicio.

Pero para las empresas que ayudábamos, la cosa no estaba yendo bien. ¿Quizá nos habíamos confundido? ¿quizá azure no era tan bueno? ¿es posible que tuviéramos que revisar todo nuestro proceso y prestar más atención a los detalles?

Posiblemente sí. Y es aquí donde surge el enfado. El enfado lleva al odio. Y al final desemboca en una fase de apatía. (no en el lado oscuro ;P)

Para evitar este devenir de los sentimientos teníamos un plan. Apuntamos lo que nos decían esas empresas y debajo añadíamos nuestras notas sobre la solución. Al documento resultando lo llamamos “Mis Notas”. Así todos los consultores lo considerarían suyo. Podrían modificarlo. Añadir o borrar nueva información.

Y lo que hoy os traigo son lagunas de las notas más destacadas de “Mis Notas”:

EN MI MÁQUINA VA GENIAL, PERO CUANDO SUBO LO MISMO A AZURE VA SUPER LENTO

Esta frase es la sustitución del mítico “Works in my machine” o “En mi máquina funciona”. Y jamás he puesto en duda semejante afirmación. Pero claro, si mi portátil es un i7 con 16 Gb de RAM y 512 Gb de SSD y en azure me decanto por una máquina con 1 core y 1,75Gb de RAM y HDD virtual… Y eso sin contar con el tema de que en mi máquina estoy lanzando un servidor de desarrollo al que solo accedo yo (como podría ser IIS Express), mientras que en azure están entrando tropecientos usuarios a la vez.

recomendaciones generales

Aunque en realidad nosotros en nuestras aplicaciones con 100 usuario concurrentes y una instancia de las más pequeñas no hemos encontrado problemas…

De cualquier forma, uno de los puntos que siempre hay que revisar en azure es que todos los servicios de usemos en una aplicación estén hospedados en la misma región. En el mismo data center. Primero por los temas de performance, pero segundo porque además el tráfico de azure a azure en el mismo datacenter no nos lo cobran.

Otro detalle que es importante es usar al menos instancias estándar o “S” en nuestros servicios de producción. Y a partir de estos tamaños buscar el más adecuado para hospedar nuestro servicio. A parte de los típicos valores de CPU, RAM y disco, también vienen asociadas con el tamaño de una instancia otros factores como el número de conexiones, las I/Os… que son muy importantes también.

Y el último consejo en general para usar cualquier servicio de azure es realizar siempre procesos cortos. Si por A o por B tenemos un proceso que nos va a llevar mucho tiempo (y cuando digo mucho es más de 1 segundo) lo mejor que podemos hacer es distribuirlo y ejecutarlo en los servicios adecuados para estas tareas como por ejemplo WebJobs, azure functions o si tenemos algo grande de verdad un azure batch.

Si AAD ya tiene gestor de usuarios, ¿para qué hacer el mío dentro de mi aplicación?

No cometáis este grabe error. Os perseguirá el resto de vuestra vida laboral.

Recomendaciones para Azure Active Directory

Lo primero que tenemos que hacer es conocer que es lo que hace AAD cuando delegamos la autenticación y autorización de usuarios. Autenticación es ese proceso en el que validamos que un usuario es en realidad quien dice ser. Autorización es cuando decidimos si un usuario tiene permisos para ver un recurso en concreto (nuestra webapp).

Si dejamos que nuestro gestor de usuarios sea el AAD: qué pasa si borramos un usuario? Perderíamos todos sus datos? como no podemos hacer login con ese usuario queda en un estado de limbo dentro de nuestra aplicación o como va eso?

Siempre recomendaré que la autenticación la realice AAD por nosotros. E incluso el tema de autorización para entrar en nuestra página web. Pero el tema de la autorización sobre datos concretos de nuestra aplicación tenemos que gestionarla nosotros.

Así que os recomiendo:

EL SERVICIO DE AZURE REDIS CACHE ES MUY LENTO…

Redis es de las bases de datos relacionales más rápidas que existen. Trabaja en memoria lo que la hace ideal para comportarse como un servicio de caché. Así que, si redis funciona lento, lo más razonable es que el problema no sea de redis.

Recomendaciones para redis

ESTOY MUY CONTENTO CON EL SERVICIO DE COSMOS DB PERO ES CARÍSIMO

¿Qué entendemos como caro?

Recomendaciones Azure Cosmos Db

Esta frase es muy frecuente y es porque dentro de Cosmos DB, una colección es tratada, por así decirlo, como una base de datos. Las colecciones se facturan por separado y la colección mínima que podemos contratar es de 400 RU. Teniendo en cuenta que el precio por RU es más o menos 5 € por cada 100, el precio mínimo de una colección es de unos 20 €.

Si a esto le sumamos que cada “entidad” (como si fueran tablas de entity framework) la guardamos en una colección diferente y tenemos, por decir algo, 18 entidades: serían unos 300 € al mes con el añadido de que estamos (infra) usando 7200 RUs.

Si lo vemos así no es tan caro. Así que os proponemos 3 ideas:

Como bola extra os comentaré que cuando usamos el cliente de .net lo mejor es usar las llamadas asíncronas y la conexión hacerla por TCP y activando el “direct mode”.

SE ME BLOQUEA LA BASE DE DATOS EN LOS MOMENTOS DE MAYOR USO Y YA NO PUEDO ESCALAR MÁS

Con el servicio de SQL database nos hemos encontrado un festival de problemas de “performance”. Aunque generalmente se debe a que la gente está acostumbrada al cluster de su empresa de SQL Server que tiene 3 servidores con 64Gb de RAM, las cabinas de la leche que se conectan con fibra y bueno, la factura que da miedo.

Recomendaciones Azure Sql Database

Estos servidores suelen ocultar las operaciones que tienen una performance fatal. Así que cuando vamos al servicio PaaS de azure de base de datos, como usamos instancias pequeñas, se hacen evidentes. Pero no os estoy diciendo que uséis tamaños más grandes de SQL Database. Creo que sale más rentable invertir en mejorar nuestra queries.

¡CLARO! COMO AZURE ES DE MICROSOFT LAS APLICACIONES DESARROLLADAS EN NODE VAN FATAL

Ahora empezamos con la ronda de mentiras. Nodejs funciona en los application services genial. Pero si que es verdad que tenemos que tener en cuenta que si usamos instancias con windows, nodejs se usa mediante el módulo de IIS llamado IISNODE. Y este módulo tiene ciertas peculiaridades:

Recomendaciones App Services con nodejs

MICROSOFT HACE QUE LAS APLICACIONES DE PHP SE ARRASTREN PARA QUE PROGRAMES EN .NET

Si me conocéis sabréis que soy programador fundamentalmente de .net, no de PHP ni Java. Así que en estos puntos no os podré dar tantos consejos. Pero si que tengo algunos sobre las aplicaciones en PHP como por ejemplo wordpress:

Recomendaciones para App Services con PHP

¿FUNCIONA TOMCAT EN AZURE? BUENO, YO TENGO MI PROPIO TOMCAT CUSTOMIZADO…

Aun recuerdo la primera vez que una empresa vino con su Tomcat customizado. Y las que les han seguido!. Tomcat funciona en App Services. Y puedes subir el tuyo customizado. Lo más recomendable es buscar en la galería una Web App con la última versión de Tomcat. Este template se descarga el tomcat desde los servidores oficiales a la WebApp. Una vez ahí, solo tienes que sustituirlo por el tuyo. Aunque es muy posible que le tengas que hacer retoques. No es lo mismo un tomcat en tu datacenter que en azure…

Recomendaciones para App Services con Java

A parte de las típicas recomendaciones de cuidado con el tamaño de la instancia y el usa cachés allí donde puedas, nos encontramos también una pequeña curiosidad:

ES QUE AZURE ES MUY CARO

Y hemos llegado a la penúltima frase que más hemos oído migrando aplicaciones a azure: es muy caro.

Sobre el precio de Azure

SI no me lo arregla Microsoft, ME VOY A IR A AMAZON

Y por último el ganador. La persona que como no está contenta con su aplicación te suelta una amenaza. A mi ni me va ni me viene. Yo no trabajo en Microsoft. Pero la gente te lo dice igualmente.

Me voy a amazon

Mi respuesta se divide en dos puntos:

En resumen

Así que intentando responder a la pregunta retórica que formulábamos al inicio de la sesión: ¿Por qué todo lo que subo a azure está mal?

Pues posiblemente porque está mal. Y encima la culpa es mía.