Microservicios y tecnologías serverless... | Learnings | The Cocktail menú cerrar
Volver Cerrar

7 julio 2017

Microservicios y tecnologías serverless en la nube

El objetivo de este artículo es presentar las arquitecturas serverless (o sin servidor), cada vez más de moda, y encuadrarlas dentro del esquema general de arquitecturas cloud, PaaS e IaaS, así como ver su caso de aplicación más directo en arquitecturas de microservicios.

Screen shot 2017 07 04 at 18.46.31

Introducción

Cualquier organización con un grado relativo de madurez se enfrenta con el problema de la inercia tecnológica: ¿cómo responder a los retos que plantean las diferentes novedades tecnológicas y a la vez dar el servicio de toda la infraestructura que soporta la operación del negocio? Las respuestas habituales suelen pasar por un modelo de entrega basado en devops y migraciones de la arquitectura a un cuadro bimodal.

En una arquitectura tecnológica bimodal se consideran dos niveles separados: una capa tradicional, fuente de verdad del sistema y en la que se gestiona la transaccionalidad, y una capa innovadora en la que se aplican ciclos de entrega más ágiles, habituales en todo lo que tiene contacto con el usuario final.

En la capa orientada a innovación, los objetivos son claros: la agilidad en la adopción de cambios tecnológicos y un time to market más agresivo.  En este aspecto, desde la arquitectura nos podemos apoyar en dos facilitadores: las arquitecturas cloud y los microservicios.

Arquitecturas cloud

Los proveedores de cloud (públicos o híbridos) permiten aprovisionar entornos completos en un modelo de pago por uso (incluyendo no sólo capacidad de cómputo sino elementos tradicionalmente apoyados en hardware como balanceadores, firewalls y dispositivos de almacenamiento).  Este aprovisionamiento no sólo sucede de forma inmediata e incluso automatizada, sino que estos activos pueden ser decomisionados con la misma agilidad.

Más allá de la propia elasticidad de la arquitectura, otro elemento importante en la valoración de las tecnologías ofrecidas por los proveedores de servicios cloud es el propio ritmo de adopción de nuevos servicios por parte de estos proveedores, que se anticipan a los proveedores tradicionales de servicios de infraestructura, por ejemplo incorporando servicios relacionados con el Big Data, la computación cognitiva y el machine learning, además de la propia presencia en diferentes localizaciones geográficas.  Por ejemplo, Amazon Web Services ofrece sus servicios hasta en 11 ubicaciones geográficas, mientras que Google Cloud Platform lo hace en 10 y Microsoft exhibe músculo aquí con 40 localizaciones diferentes.

Todos los proveedores disponen de las dos formas de entrega de los servicios de cloud existentes: la modalidad IaaS y PaaS.

IaaS: Infraestructura como Servicio.

En el modelo IaaS, el proveedor ofrece agilidad y flexibilidad en la gestión de la propia infraestructura, ya que permite el aprovisionamiento ágil bajo demanda e incluye el autoescalado bajo criterios automáticos (por ejemplo, por consumo de recursos en un intervalo de tiempo temporal, o de forma planificada en ciertas franjas horarias) y la abstracción de los recursos (podemos contratar y gestionar un servicio de almacenamiento en disco en red sin tener que lidiar con los diferentes vendors de cabinas, discos y software de gestión de volúmenes).

PaaS: Plataforma como Servicio.

Si en el modelo IaaS podemos construir nuestra plataforma cloud a partir de los elementos básicos ofrecidos por el proveedor cloud, en el modelo PaaS esta elección ya viene dada de antemano por el proveedor, que se encarga de ofrecer un servicio gestionado de la misma.    Por ejemplo, con el servicio Elastic Beanstalk, AWS ofrece la posibilidad de disponer de un stack tecnológico completo basado en plantillas que se pueden desplegar de forma inmediata (por ejemplo: Apache + PHP + MySQL) .  De esta forma la aplicación está lista en producción simplemente haciendo push a un repositorio de código.

Otros proveedores que ofrecen capacidades similares son Heroku (de Salesforce) o Google App Engine, que soportan lenguajes tan diversos como Java, PHP, Python, Go, Ruby o incluso Elixir de forma nativa.

Este modo de entrega permite iterar y pivotar de forma extremadamente rápida sobre prototipos, lo que permite validar ideas de negocio rápidamente en cuestión de días.    A cambio debemos adaptar nuestra solución a las plantillas predefinidas de stacks tecnológicos con los que cuenta el proveedor cloud: en definitiva, como arquitectos cedemos flexibilidad a cambio de agilidad.

Microservicios

La otra tendencia arquitectónica tiene que ver con cómo se organizan los diferentes servicios de negocio que soportan las aplicaciones tanto internas como externas.  Si a mediados de la pasada década la tendencia eran las arquitecturas orientadas a servicios (SOA), con la emergencia de las plataformas cloud y la facilidad de aprovisionar entornos que estas ofrecen en la actualidad, la idea que se impone  es la de llevar el concepto al extremo con los microservicios.

Un microservicio es un servicio autónomo y encapsulado que ofrece una capacidad concreta de negocio bien delimitada.  Estos microservicios disponen de una única responsabilidad (Single Responsibility Principle), lo que reduce el acoplamiento entre los diferentes microservicios y mantiene la cohesión dentro del dominio lógico.  Herramientas como DDD nos pueden ser de ayuda a la hora de trocear los diferentes procesos de negocio en una arquitectura de microservicios.

Ese menor acoplamiento implica la facilidad de desplegar modificaciones y cambios dentro de un microservicio sin impactar al resto. Por su parte, la mayor cohesión supone que el dominio de aplicación de un microservicio está perfectamente acotado, lo que facilita la evolución y el entendimiento del mismo por parte de los equipos.  

La comunicación entre los diferentes microservicios se hace mediante llamadas HTTP REST para forzar la separación de responsabilidades y por lo general el concepto de la persistencia se resuelve dentro del propio microservicio, para evitar que la propia definición del esquema de la base de datos sea fuente de acoplamiento.

Arquitecturas Serverless: funciones como servicio (FaaS)

La última evolución en las arquitecturas cloud consiste en el uso de funciones serverless. ¿En qué consisten?

Tanto IaaS como PaaS ofrecen el concepto de tarificación y dimensionamiento con base en instancias de computación (tipo de CPU cores, tamaño de RAM, etc.).  El modelo serverless abstrae los recursos de computación hasta el punto donde simplemente se ejecuta código que lleva a cabo una lógica concreta de negocio, que se tarifica únicamente por minutos de ejecución. En este contexto ya no se habla de servidores virtuales, máquinas, o instancias que gestionar: el plano de control que ve el desarrollador es, simplemente, la posibilidad de ejecutar una función de código, no un servidor de aplicación.  

Esta función de código se ejecuta bajo demanda, siendo tarificada la ejecución por tiempo (AWS Lambda y Google Cloud Functions lo hacen en fragmentos de 100ms) y con capacidad de escala de forma automática.  Esto es así porque el ciclo de vida de la función es efímero: una vez finalizada su ejecución, el entorno de la misma desaparece.  

Si el código  serverless no se encuentra disponibilizado en un servidor de aplicación, ¿cómo se activa su ejecución?  La respuesta es que la función se dispara mediante eventos que sucedan en el resto de la infraestructura cloud: por ejemplo la subida de un fichero concreto, la recepción de un evento en una cola de mensajería,  una activación periódica por lotes o mediante un API manager nativo de la plataforma cloud.  En el caso de Amazon Web Services, este API manager es AWS API Gateway.

En este caso, la idea del API Gateway es crear puntos de acceso a APIs internas de nuestra infraestructura, siempre alrededor del estándar HTTP REST.  La combinación con el esquema   serverless anteriormente descrito, implica que podemos activar nuestras funciones de código directamente como respuesta a invocaciones de una API REST.

Una vez activada la ejecución de nuestra función  serverless, el código puede consultar diferentes  sistemas vía API (bien sean otros microservicios o incluso sistemas de la capa tradicional) para recuperar la información relevante a la hora de ejecutar su lógica de negocio.

A modo de ejemplo, a continuación se muestra un diagrama técnico de una arquitectura en la que se expondría de forma pública una API que podría consultar datos, bien de un servicio legado alojado en la infraestructura on-premise (que se encontraría en la capa tradicional en el esquema bimodal), o bien de un microservicio implementado sobre una función serverless.

 

 

Otro caso de uso sería utilizar una función serverless para el envío de correos en un formulario de una landing page muy sencilla y totalmente estática, lo que evitaría la contratación y  gestión de un servidor de aplicación sólo para procesar el formulario y enviar el contacto a una pasarela de correo.

Este tipo de arquitecturas admiten además comportamientos asíncronos replicando modelos de publicación y suscripción, lo que permite coreografiar procesos de negocio sin necesidad de una orquestación explícita por parte de un servicio concreto.  En definitiva, este nuevo tipo de infraestructura no basada en servidores da una capa de lógica que permite conectar y extender diferentes servicios (nuestros o de terceras partes).

Estas funciones sin servidor funcionan a modo de hilo con el que tejer una arquitectura apoyada en el resto de los servicios tanto PaaS como IaaS. Por ejemplo, AWS permite activar funciones serverless ante eventos como subidas de archivos a S3, o como respuesta a eventos de mensajería, tal y como muestra el siguiente diagrama:

Esta técnica desacopla el procesamiento de los mensajes de su emisión, de forma que si el tratamiento de los mensajes es relativamente costoso, se puedan lanzar tantas funciones serverless como sea necesario, sin limitaciones de máquinas.

Seguridad en entornos serverless

En el análisis de amenazas de seguridad de este tipo de arquitecturas podemos considerar aquellos riesgos que se ven mitigados, los que se incrementan y los que no cambian.

En el grupo de los riesgos que se reducen:

  • Se evitan dependencias de sistemas operativos vulnerables.  La mayoría de exploits se producen porque no se han aplicado los parches de seguridad suministrados por el fabricante del sistema operativo.  En un entorno serverless el proveedor cloud puede hacerlo a escala sin interrupción del servicio.

  • Denegación de servicio.  Dado la propia esencia efímera del entorno de ejecución serverless, no existe un servidor concreto que derribar.  Lógicamente, esto no impide un ataque de  denegación de facturación, donde un agente malicioso realice llamadas excesivas a los endpoints.

  • Servidores en ejecución permanente. Un vector habitual en los ataques a la infraestructura consiste en lograr instalar un agente malicioso en un servidor y dejarlo funcionando (probablemente para tratar de comprometer otras partes de la infraestructura).  Dado que cada ejecución de la función  serverless se ejecuta en un entorno aprovisionado limpio, no existe dicha posibilidad.

Otras tipologías de amenazas deben seguir siendo vigiladas:

  • Políticas de permisos.  O, lo que es lo mismo, determinar quién está autorizado a ejecutar las funciones y APIs implementadas con esta tecnología.  Las plataformas serverless actuales permiten asignar roles y privilegios de acceso a las diferentes capacidades, pero es fácil omitir el detalle y convertir en públicos los puntos de acceso.

  • Aseguramiento del dato en reposo.  Dado que el entorno serverless no dispone de persistencia, esta debe ser resuelta en otro punto de la infraestructura.  Nuevamente surge aquí el problema de la granularidad de los permisos.

  • Vulnerabilidad en el código y/o dependencias.  La capa de aplicación no queda especialmente protegida en el entorno serverless.  Si el programador escribe un código vulnerable o incorpora dependencias que lo son, la función serverless manifestará la misma vulnerabilidad.

Y hay riesgos a vigilar con mayor intensidad:

  • Terceras partes - En un entorno serverless es más probable acabar integrando llamadas a servicios de terceros.  La pregunta que hay que responder aquí es: ¿qué datos estamos compartiendo con estos vendedores y cómo protegen esta información?  ¿Se asegura el dato en tránsito?

  • Superficie de ataque - Mayor granularidad y flexibilidad pueden conllevar usos no previstos por parte de atacantes.   No sólo es necesario testar las funciones serverless individualmente, sino comprobar que no existen flujos de llamadas que provoquen comportamientos incorrectos.

Conclusiones

Las capacidades serverless que ofrecen proveedores como Amazon, Google o Azure son una opción más a barajar dentro del juego de herramientas con las que cuenta el arquitecto de soluciones en la nube.  Combinando funciones serverless con el resto de servicios en la nube del proveedor, ya sea en modo PaaS como IaaS, podemos construir plataformas escalables que son efectivas en coste.   

El aspecto más importante a considerar cuando una organización adopta el uso de elementos  serverless es que se trata de capacidades nativas del proveedor de cloud, lo que a futuro puede complicar la migración de la plataforma a otro proveedor de infraestructura (aunque si es otro proveedor cloud probablemente disponga de capacidades similares).

 

Cambiemos juntos

las cosas