Aprendiendo Serverless

La infraestructura tecnológica ha sido transformada para desplegar aplicaciones más rápido. Primero fue la virtualización de servidores, luego vinieron los contenedores y ahora llega la tecnología serverless para hacer más simple la tarea de administración y operación de infraestructura. Vamos a estudiar conceptos básicos sobre serverless ó en palabras más simples, sin-servidor, y como están en AWS.

¿Cómo funciona Serverless?

El objetivo principal de serverless es la capacidad de activar aplicaciones por medio de eventos. Un evento es una acción generada por una aplicación ó servicio llamados productores, que disparan una función, administrada por un enrutador de eventos, para realizar un procesamiento que luego será enviada a otros servicios ó a otras funciones, también llamados consumidores. Las funciones están hechas de código, permisos, variables de entorno y cantidad de CPU/memoria.

Los componentes de una arquitectura serverless son simples, productores que generan eventos enviados a consumidores. En el siguiente ejemplo, los eventos son generados por una acción en una aplicación para procesar datos y luego almacenarlos en una base de datos, también a su vez, guarda datos en un bucket que dispara de forma automática una función para procesar datos y almacenarlos en otro bucket.

Los eventos invocan a las funciones de formas distintas, puede ser por SDK (Software Development Kit), CLI (Comand Line Interface), toolkit ó directamente a través de HTTP. Según las necesidades de la aplicación y del origen del evento, los tipos de invocaciones son:

• Invocación síncrona: La función es ejecutada retornando una respuesta al invocador con datos adicionales. Los eventos esperan una respuesta inmediata de la función.

• Invocación asíncrona: La función es ejecutada sin dar un a respuesta al invocador. En este caso, las funciones envían los datos a los destinos ó consumidores.

• Invovación stream (pooling) : La función estará “viendo” los invocadores para obtener eventos y ejecutarse. Es un caso adecuado para transmisión de datos en tiempo real.

Las funciones son ejecutadas en entornos de ejecución según el lenguaje de programación. Por ejemplo, AWS Lambda soporta entornos para Java, Go, Powershell, Node.js, C#, Python, Ruby ó incluso crear un entorno personalizado. Una vez invocada la función, el código es compilado y ejecutado para hacer llamados por API a los consumidores. En palabras simples, una función puede realizar acciones en otros servicios de base de datos como Amazon DynamoDB, ó enviar mensajes por medio Amazon SQS ó Amazon SNS.

Memoria, tiempo y concurrencia

Cuando se está construyendo una nueva función, es importante definir el desempeño de la función en entornos reales con volumen de ejecución altos. El ajuste de configuraciones garantiza la optimización de costos y mejora de la experiencia con la aplicación final. Estas configuraciones son memoria, tiempo muerto (timeout) y la concurrencia.

Memoria
Es un recurso linealmente proporcional a otros recursos como la CPU, significa que al aumentar memoria aumenta su equivalente en CPU disponible para la función. Es una relación de GB y segundos. AWS Lambda tiene disponible una herramienta para afinar la configuración de memoria.

Tiempo de espera
Mejor conocido como timeout es el tiempo máximo que una función esté ejecutando hasta que sea terminada. En el caso AWS Lambda, el tiempo máximo es de 900 segundos (15 minutos). Este límite significa que una función no puede estar ejecutando por más de 15 minutos. La razón es porque el costo de una función está determinado por solicitudes y duración. Las pruebas de carga son la mejor manera de determinar el tiempo de espera óptimo de una función.

Concurrencia
Es el numero de invocaciones que una función ejecuta en un momento determinado. Cuando invocación lanza una instancia de la función para procesar los eventos, cuando el código de la función termina de procesar queda disponible para otra invocación. Cuando ocurre más de una invocación al mismo tiempo, se llama la concurrencia de la función. Existe tres controles de concurrencia:

• Concurrencia no reservada: Como mínimo existen 100 concurrencias disponibles para las funciones que no tienen concurrencia reservada. Lo que permite que todas las funciones puedan ejecutarse.

• Concurrencia reservada: Garantiza el máximo de instancias de una función, así una función puede tener concurrencia reservada para que no pueda ser usada por otras funciones.

• Concurrencia aprovisionada: La concurrencia aprovisionada inicializa una cantidad solicitada de entornos de ejecución para que estén preparados para responder de inmediato a las invocaciones de la función.

La concurrencia permite que la función escale bajo demanda, por cada evento concurrente genera una instancia separada del entorno de ejecución. La escalabilidad es administrada de forma automática según las solicitudes de la función, así que no hay necesidad de administrar infraestructura para responder a las demandas de la aplicación.

¿Y la seguridad?

En el modelo serverless, el proveedor de nube tiene la responsabilidad de mantener y operar toda la infraestructura adyancente y el cliente sólo es responsable por la seguridad de los datos y aplicaciones desarrolladas. Significa que la administración de seguridad en serverless, es basada sólo en políticas de accesos sobre las funciones, más conocido como el modelo de gestión de identidades y accesos (IAM). Los permisos son categorizados según la invocación y la ejecución de la función.

• Políticas de recursos IAM: Son permisos definidos en formato JSON para invocar la función. Se define quién puede invocar la función.

• Rol de ejecución IAM: Es un grupo de permisos que se asocian a la función. Se define qué puede realizar la función sobre otros servicios.

SAM La ardilla ayudante

Para facilitar el despliegue de aplicaciones en una forma más eficiente, el modelo AWS Serverless Application Model (SAM) mejora la experiencia de los desarrolladores a la hora de ejecutar código sin servidor. SAM es un marco de trabajo libre que define las funciones y recursos en plantillas YAML para ser desplegadas por medio de la infraestructura como código.

Las plantillas YAML contienen el código de la aplicación y recursos necesarios, como por ejemplo funciones AWS Lambda. SAM transformará esas plantillas en pilas de AWS CloudFormation que se encargará de aprovisionar las funciones junto con los demás recursos de infraestructura. Para desplegar con SAM, sólo se necesita una interfaz de línea de comandos, llamada SAM CLI. Se pueden desarrollar y probar las funciones de forma local antes de ser desplegadas en los ambientes productivos, y SAM crea la aplicación sin servidor con solo tres comandos:

• sam build: Construir la aplicación de forma local y transformar a plantillas YAML.

• sam package: Empaquetar las plantillas YAML y la aplicación en un archivo zip.

• sam deploy: Desplegar la función con la aplicación y recursos por medio de AWS CloudFormation.

El modelo sin-servidor representan un nuevo tipo de arquitectura orientada a eventos, en donde las aplicaciones son escritas en funciones, disparadas por eventos y la administración de infraestructura está totalmente oculta. Representan una evolución de los modelos de despliegue de aplicaciones en la nube.

Publicado en: The Bucket of Notes