Serverless: Realidad y perspectivas (2)

Bueno continuando con esta revisión respecto a la plataforma Serverless, veamos algunas consideraciones para entornos de trabajo y como enfocarlo de la mejor manera.

Para empezar debemos recordar que nuestras aplicaciones, por lo general, viven en un contexto, teniendo interacciones con otros sistemas, fuentes y consumidores de datos, sistemas externos, etc, los cuales al momento actual en su mayoría se encuentran en entornos on premise, lo cual nos lleva al reto de como hacer que nuestras aplicaciones en la nube se integren con los componentes on premise. Si nuestro ecosistema nació íntegramente en la nube (sin que eso implique ser cloud native) no es que no haya retos, pero son diferentes y a ellos nos enfocaremos en otro momento.

Lejanos son los tiempos en que las organizaciones podían tener todo un conjunto de direcciones IPV4 publicas a todos los equipos de sus organización (si, yo viví esa época en tres de mis primeros trabajos), ahora la escasez de direcciones IPv4 como las necesidades de asegurar los recursos frente a ataques e intrusiones, nos ha llevado de manera natural a un escenario en que los recursos criticos de computo de nuestras organizaciones hagan uso de direcciones IPv4 privadas, y claro, con segmentos de red dedicados y protegidos detrás de un firewall, dándose “confianza” de acceso solo a equipos dentro de la red propia de la organización (la excepción, claro, se da cuando es necesario exponer servicios al publico o a agentes externos).

Entonces cuando se aborda el crecimiento hacia la nube, un paso natural y conveniente es tratar (con las limitaciones de ancho de banda) de considerar a la nube como una continuación de nuestras redes privadas, para lo cual se habilitan VPNs, enlaces dedicados, nuevas reglas de firewall, se asignan segmentos de red (en el caso de Azure se denominan VNETs y en AWS VPCs), pero…

Nos topamos con una fricción respecto a la variedad de los servicios que podemos usar en la nube, y es que muchos de los servicios PaaS de los que he hablado  en este blog (como nuestro viejo complice Azure Web App) son servicios de IP publica, vale decir que no podemos asignarles directamente una IP privada de nuestra red extendida en la nube (1), por lo que si queremos que interactuen con recursos privados on premise, o inclusive con segmentos de red privados en la nube (VNETs)… no podremos, a menos que habilitemos capas (APIs) de exposición de IP publica. con las complejidades que esto puede implicar (programación ad hoc, autenticación, autorización).

Esta claro, que si queremos un mayor uso de tecnologías PaaS como Serverless, se debe procurar superar esta fricción de mundos, asi que Microsoft desde el año pasado a habilitado una característica llamada Regional VNET Integration que viene a establecer un puente entre el mundo PaaS de IPs publicas y el mundo de IPs privadas, ya sea de VNET u on premise.Regional VNET Integration

Como funciona esto? Bueno, simplificando mucho la documentación se trata de lo siguiente:

  • Contamos con una VNET y una subnet “Destino” que aloja los recursos a los que queremos acceder.
  • Se tiene un AppService, ya sea una Web App en modo de pago Standard o superior, o un Function en modo Premium o de tipo dedicado App Service.
  • Se enrola a nuestra AppService en una VNET nueva y vacia “Origen”, de esta manera nuestra Web App o Function sera “consciente” de un entorno VNET, y así conectarse a otras IP privadas.
  • Se define a que subnet “Destino” nos conectaremos desde el AppService, se entiende que era por eso que definimos una VNET de “Origen” pues asi se tiene el puente necesario para comunicar ambos mundos.

Si, suena muy teórico, por lo que la mejor forma de probarlo y entender es seguir el ejemplo que explica como establecer dicha conexión, es muy sencillo.

Cabe mencionar que al momento de escribir este post, la funcionalidad aun esta en modo Preview, y que hay que tener en cuenta algunas limitaciones de las opciones del servicio.

  • Solo funciona, de momento, en AppService basadas en Windows.
  • Cuando reservamos la VNET “Origen” solo la podemos asignar a una AppService.
  • De igual manera, de momento desde una AppService solo podremos conectarnos a los recursos pertenecientes a una subnet “Destino”.

Aun así es un gran avance para facilitar las interacciones entre servicios PaaS y recursos de IP privada, ya sea en nuestras VNETs en la nube o en la infraestructura On Premise, esto se complementara con el nuevo servicio Private Link, pero eso es otra historia 😉

Espero que esto haya ayudado a clarificar un poco las opciones disponibles, quedo de tus comentarios.

(1) Bueno, en realidad si se puede, pero hasta hace poco eso implicaba el provisionar un servicio llama App Service Environment, que es muy costoso, por lo que nos hemos enfocado en la solución que esta por liberar Microsoft.

Información adicional:
Integrate your app with an Azure Virtual Network 
Web app network security made easy
Delivering services privately in your VNet with Azure Private Link

2 thoughts on “Serverless: Realidad y perspectivas (2)

Agregue un comentario

Su dirección de correo no se hará público. Los campos requeridos están marcados *

Time limit is exhausted. Please reload the CAPTCHA.