Serverless Microservices con Azure Functions y Api Management

Hace ya un tiempo que Amazon liberó el servicio Lambda, en ese entonces no lo entendí muy bien, me pareció entender que respondía a eventos, lo comparé con los Azure WebSites + Azure Web Jobs y dejé el tema hasta ahí. En las ultimas semanas Microsoft anunció el servicio Azure Functions, y en la web ya se veían comparaciones con AWS Lambda, vi la documentación y la presentación en su momento, pero no entendí que plus había frente a los ya conocidos Azure WebSites + Azure Web Jobs. La semana pasada se llevó a cabo el Dev Days Latam en la ciudad de Lima, un evento sin presentes en la región al que tuve la oportunidad de asistir, y donde por primera vez escuché este concepto en una de las sesiones.

Decir que son los microservicios me resulta tan difícil como decir que es la programación funcional, si bien puedo decir algunas características no tengo una definición precisa y desconozco si la hay. En una ocasión un colega dijo “son Bounded Contexts as a Service” y es una definición que me gusta, pues de ahí se desprende lo de las pequeñas unidades de despliegue y la posibilidad de usar un lenguaje para cada necesidad y etc. etc. Imaginar que son los Serverless Microservices me hizo pensar en unidades de despliegue que no van a un “server” (?) ¿imágenes de Docker auto gestionadas en un host que yo no controlo? al googlear el termino para ver alguna definición o implementación veo que, para sorpresa mía, los primeros resultados son implementaciones hechas en AWS Lambda. ¿Pero no es lo mismo que un Azure WebSite + Web Job?

Desconozco mucho de la oferta de computo en la nube de Amazon así que traduzco la documentación de AWS Lambda a los Azure Web Sites y Web Jobs, pues me ofrece muchas de las características que allí se muestran. Pero si Azure ya tenía estos dos servicios ¿Para qué crear uno nuevo, si de hecho, lo Functions están basados en el Azure WebJob SDK?

Rescato algunos de los conceptos: Compute on-demand, que incluye un nuevo modelo de cobro y la posibilidad de responder a eventos de servicios de terceros (Http – WebHooks (?)). Y por último, pero no menos importante, el modelo de programación: Un Function App es una carpeta que contiene un archivo host.json y carpetas con las funciones. Estas funciones (carpetas) son archivos de código (en los lenguajes soportados) y un archivo function.json que define la función. La documentación completa está aquí.

Podemos entonces definir un Function App como el siguiente:

MyService
|host.json
|Membershib
|| node_modules
|| function.json
|| index.js
|SayHello
|| function.json
|| project.json
|| run.csx

En la estructura de este ejemplo he dejado dos funciones en lenguajes distintos dentro del mismo Function App (ahora mismo no sé si escala por función o por App), pero se puede mejorar esta implementación teniendo un servicio independiente de membership y uno “por cada necesidad”

Cómo cada Función tiene su propio endpoint… ¿Cómo hacemos para “unificarlo”? Azure tiene el servicio de Api Management que nos viene perfecto para exponerla como un Api, además de otros plus del servicio.

Así como los microservicios voy a dejar este post corto, solo con el concepto y sin más detalles de la implementación. Ya luego si me animo sigo con algo más parecido a un tutorial.

He dejado algo de código, con la estructura del proyecto que mostré aquí, en mi GitHub.

Anuncios
Serverless Microservices con Azure Functions y Api Management

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s