Historia de Azure

No, no os voy a contar un cuento. Esta «historia» es más «history» que «story», aunque como toda historia está influenciada por quien la cuenta. La cuestión es que pensaba comenzar a dar la murga con Azure (aprovechando que estoy trabajando con ello otra vez), y unos días en Edimburgo me han hecho reflexionar que a veces las cosas se entienden mejor si conoces su historia. Por tanto voy a intentar contaros la historia de Azure tal y como yo la recuerdo.

Azure, aunque ya deberías saberlo porque por estos lares se ha mencionado muchas veces (en especial por el gran JC), es la plataforma de cloud computing de Microsoft. En ella ofrece PaaS e IaaS, pero al principio todo era PaaS. Esto puede parece una nimiedad sin importancia, al fin y al cabo Amazon al principio ofrecía sólo IaaS y ahora ya no. Sin embargo, en este caso el orden si altera el producto, y en el caso de Azure hoy en día podemos ver cosas que si no recordamos esto nos van a parecer rarísimas y nos va a costar entender. Al principio -si no recuerdo mal, que la memoria no es lo mío-, básicamente sólo había unas pocas cosas:

  • «Procesos» (web y worker roles): estos servían para programar código. Podía ser código que respondiese a peticiones web o procesos infinitos que hicieran un trabajo constante -simplificando mucho-. No tenías que preocuparte de las máquinas, los sistemas operativos ni nada. Hacías tu código .Net -al poco tiempo también Java y PHP-, le decías si necesitabas mucha potencia, baja potencia o potencia normal, y cuantos «procesos» corriendo. Él se encargaba de levantar máquinas para esos «procesos», instalarles el sistema operativo, arrancarlo y echar a andar tu proceso. Además si había algún problema y se rompía algo lo volvía a levantar, y si tenías al menos dos procesos iguales, te garantizaba que estaría el 99.96% del tiempo en ejecución incluso aunque hubiese que instalar actualizaciones del sistema (que por supuesto también hacía él).
  • Almacenamiento (tablas, colas, blobs, CDN y SQL): los que conozcáis un poco la historia sabréis que estoy haciendo trampas porque la red de contenidos y las bases de datos al principio principio de todo no estaban. De cualquier modo, tenías las tablas que eran un almacenamiento noSQL que te permitía almacenar a un precio de risa y a una velocidad de vértigo un montón de datos, pero sólo podías preguntar de un modo eficiente usando el nombre de la tabla, la clave de la partición y la clave de la fila; podías hacer querys con operadores o sin alguno de esos datos, pero el tiempo entonces no iba a ser constante y pequeño. Las colas eran sitios donde metías datos y cuando se leían desaparecían durante un tiempo, para que tuvieses tiempo de procesarlos y si acababas lo borrabas y si no la cola hacía que reapareciese; algo común para comunicar procesos. Los blobs eran en cierto modo archivos, podías almacenar archivos gordos, que no te cupiesen en las tablas que tenían un tamaño de entidad pequeño, y los podías dejar públicos o privados. El CDN era para repartir contenidos estáticos rápidamente a cualquier parte del mundo, y las bases de datos de SQL Azure te permitían tener un almacenamiento relacional y con transacciones como «toda la vida». Lo genial de este almacenamiento es que ellos se encargaban de todo: daban seguridad, replicaban los datos 3 veces y si algo se corrompía lo reestablecían automáticamente, etc.
  • Fabric: Luego estaba Fabric que para mi siempre fue lo más abstracto y de hecho no lo miré en exceso para la certificación porque era lo que menos me preocupaba y menos útil me parecía. Ojo no confundirlo con el Fabric que acaban de presentar para dar soporte a microservicios, no. En aquel Fabric se englobaban otros servicios que no tenían cabida en los anteriores como el Azure Active Directory o las VPN; cosas que estaban más enfocadas a los entornos de grandes corporaciones.

Esto es lo que había, ni más ni menos y esto explica muchas cosas. Explica que ahora mismo haya dos portales de gestión (creo que hemos pasado por tres o cuatro), ya que las cosas han cambiado tanto y tan rápido que lo que valía para gestionar cuatro cosas no vale para gestionar cuarenta, o porque hay que gestionar cosas que inicialmente no se habían planteado como el manejar una misma persona múltiples suscripciones. Pero esa pequeñez de los portales no justifica este tostón de post, así que dejarme que os ponga un ejemplo gráfico para que entendáis y pensad que así es en general para todo:

Es obvio, aunque intentasen que no pensáramos en ello, que bajo los «procesos» había una suerte de máquinas virtuales que probablemente correrían sobre un hipervisor que manejase todo el hardware. Si hubiesen ofrecido desde un principio esas máquinas virtuales para vender infraestructura sin enfocarse tanto en la plataforma todo había sido distinto, pero ellos prefirieron montar todo el tema de los «procesos». Ahora bien, cuando la gente les pidió que ofrecieran máquinas virtuales para poder montar cosas más específicas, software no adaptado o -a lo loco- ¡linux! tenían un problema. Probablemente, y esto es suposición mía que estará más o menos fundada, temas como el de reiniciar todo cuando se rompía estaba a nivel de «proceso» o el hipervisor sólo soportaba un SO y para aprovechar esas funcionalidades que ya estaban depuradas, cuando introdujeron las máquinas virtuales lo hicieron por encima de ese PaaS que tenían ya montado. Por tanto, cuando creas una máquina virtual automáticamente se crea un «proceso» con un rol específico de máquina virtual y también una cuenta de almacenamiento para guardar sus datos en un disco duro montado sobre un blob. Vamos, que tenemos una máquina virtual, sobre un proceso que corre en una máquina virtual que funciona sobre un hipervisor que maneja una infraestructura de servidores en un contenedor de camión que está en Irlanda, Holanda, Brasil o Japón; un IaaS sobre un PaaS sobre una gran infraestructura; una locura.

Esto es un ejemplo, pero en general se aprecia que todo o casi todo está montado sobre estas bases primigenias, lo cual al primerizo le hace sentirse raro porque descubre cosas que no esperaba encontrar. Además ser consciente de ello nos ayuda a pensar en que si incluyen un nuevo tipo de base de datos que se basa sobre las estructuras existentes, esta estará por tanto replicada tres veces y no nos tendremos que preocupar de que pasa si se corrompe, ya que es algo que está solucionado de base.

Espero haberme explicado bien, esto es más fácil con un papel y un lápiz. Os dejo un vídeo de hace unos años que ilustra como son los datacentersde Azure, y hoy os libráis del tostón de que me digáis en los comentarios o por Linkedin o Twitter sobre que queréis hablar, que esta visto que no queréis hablar de nada ;P

Windows Azure Data Centers

 

Post By Javi López (27 Posts)

Arquitecto/desarrollador, creativo, buscador de nuevas soluciones y modelos de negocio, crítico constructivo y ex muchas cosas

Website: → JaviLopezG

Connect

Trackbacks/Pingbacks

  1. Webjobs de Azure - Cantabria TIC - 26 enero, 2016

    […] recordáis aquello que hablamos sobre la historia de Azure, recordaréis que al principio, solo había un sistema de “procesos” que se conocía (y […]

  2. Azure Stack - Cantabria TIC - 4 febrero, 2016

    […] tienen disponible las primeras cosas que estuvieron disponibles en Azure -y vosotros ya os sabéis su historia ¿a que sí?- como son las cosas de conectividad de redes virtuales y VPNs, el storage y los roles […]

  3. Historia de Azure – JaviLopezG - 20 febrero, 2016

    […] Seguir leyendo en CantabriaTIC. […]

Deja un comentario

Leave your opinion here. Please be nice. Your Email address will be kept private.

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies

ACEPTAR
Aviso de cookies
Translate »