Durante los últimos años se está intentando separar cada vez más la infraestructura del código. En este aspecto las soluciones serverless cada año van ganando más popularidad.
Introducción a AWS Serverless
Las principales ventajas que se obtienen al hacer uso de esta arquitectura son:
No hay que gestionar la infraestructura sobre la que se ejecuta el código. No hace falta configurar servidores, contenedores, etc.
El escalado es automático y solo se paga por lo que se usa.
Automáticamente existe una alta disponibilidad.
Como principal desventaja cabe destacar que actualmente la tecnología serverless está altamente relacionada con el proveedor que se desea utilizar, debido a este motivo una vez desarrollada una aplicación en un proveedor determinado si queremos migrarla a otro deberemos de realizar cambios.
Serverless en AWS
AWS nos permite desarrollar aplicaciones serverless gracias a su servicio Lambda.
Este está altamente integrado con la mayoría de los eventos que gestiona la plataforma.
Los principales componentes a tener en cuenta al trabajar con Lambda son:
– Api Gateway: Permite publicar APIs REST y enlazar los endpoints con las funciones Lambda. Entre las funcionalidades que ofrece cabe destacar que soporta multi-tenancy.
– Step Functions: Permite definir flujos de trabajo complejos a partir de definir cómo deben de interactuar diferentes funciones lambda. Además ofrecen otras funcionalidades avanzadas como los callback (esperar una respuesta externa a una llamada) o anidar flujos.
Arquitectura
La arquitectura de las funciones Lambda es bastante simple. Por un lado estas están suscritas a un conjunto de eventos concretos que son generados por alguno de los servicios de AWS. Estás pueden realizar acciones muy diversas dependiendo de los datos de cada evento.
Por ejemplo podemos procesar los archivos que se vayan guardando en un S3 y dependiendo de sus metadatos almacenar cierta información en DynamoDB.
Demo
Crear una función Lambda es muy sencillo. Simplemente tenemos que acceder al servicio Lambda desde nuestra consola de AWS. Cuando vayamos a crear una función se nos preguntará qué procedimiento queremos utilizar para crearla, por motivos de simplicidad elegiremos la opción de “Crear desde cero”.
A continuación debemos de indicar el nombre que identificará nuestra función y en qué lenguaje queremos implementarla. En este caso hemos elegido Node ya que es de los más sencillos para hacer pruebas.
Podemos probar las funciones directamente desde la interfaz de usuario. Para ello debemos clicar en el botón de probar función. Dado que las funciones consumen eventos tenemos que elegir qué evento de prueba queremos utilizar. Como hemos creado la función aún no tenemos ningún evento de prueba definido por lo que definimos uno. Un evento de prueba simplemente es un JSON con la estructura que recibirá nuestra función.
Una vez definido el evento y lanzada la prueba podemos ver en el apartado en verde el resultado de esta. Donde podemos validar que la función ha realizado lo que esperábamos. Las funciones Lambda soportan versiones y etiquetas. Cuando se realiza una versión, el código de esa versión ya no es modificable. Un alias se puede entender como si fuera un puntero a una o varias versiones.
La función editable no pertenece a ninguna versión y nos podemos referir a él mediante el alias $LATEST. Cuando publiquemos una versión lo haremos del código que se encuentra referenciado desde este alias. Adicionalmente podemos añadir una descripción.
En este caso estamos accediendo a un parámetro del evento que nos generará API Gateway.
Una vez ya publicada esta segunda versión vamos a crear un alias. Como ya se ha comentado en el apartado anterior un alias puede referenciar a una o varias versiones. En este caso vamos a ver como se define para varias versiones (un alias ponderado). Cuando vayamos a crear un alias ponderado debemos de indicar el porcentaje de peso que tiene cada versión. Este porcentaje definirá cuántos evento procesa cada una de las versiones. En este ejemplo hemos indicado un 50% por lo que uno de cada dos eventos será procesado en cada versión.
Los alias también se pueden probar con lo que podemos validar que realizando múltiples pruebas cada vez nos responde una función distinta.
Crear una API simple desde el API Gateway es igual de simple que crear una Lambda. Simplemente tenemos que acceder al servicio API Gateway desde nuestra consola de AWS. Cuando vayamos a crearla se nos preguntará qué tipo de API queremos crear. En este caso elegiremos HTTP API. A continuación tendremos la opción de crearla directamente o de importar su definición a través de un archivo Swagger (OpenAPI v2) o OpenAPI (OpenAPI v3). Por simplicidad la crearemos vacía.
A continuación se nos permitirá elegir las integraciones (servicios que procesaran los eventos que genere el API). En este caso elegimos integrar Lambda y elegimos la función que hemos creado en el apartado anterior. Si no se indica la versión se utiliza $LATEST.
Finalmente creamos las rutas de nuestra api y elegimos a qué función dentro de nuestra Lambda se realizará la llamada.
Por último, se nos permitirá agregar etapas (stages). Cada etapa se puede entender como un entorno diferente. Por ejemplo podríamos definir sandbox y production. En este caso dejaremos la etapa que se crea por defecto $default.
Podemos editar la integración para indicar la versión determinada que queremos utilizar. Para ello simplemente debemos de añadir al final del identificador ARN el alias o versión a utilizar
Podemos ayudarnos de las etapas definidas para que dependiendo de en cual nos encontremos se utilice una versión u otra de forma dinámica. Para ello nos serviremos de las variables de la etapa.
Por un lado definiremos en variables de la etapa la variable lambdaAlias cuyo valor será el alias que deseemos utilizar. En este caso ponderado.
Finalmente volvemos a definición de la integración y sustituimos el alias indicado anteriormente por un valor evaluado dinámicamente (${stageVariables.lambdaAlias})
Conclusiones
Hemos podido ver que tanto Lambda como API Gateway son dos servicios muy fáciles de utilizar. Las soluciones serverless pueden ofrecernos grandes ventajas a la hora de implementar, escalar y reducir los costes de nuestras aplicaciones, pero a cambio cedemos la parte de independencia de nuestro código.
Cabe destacar que los mostrado anteriormente no es production ready. En un proyecto real tendríamos las funciones en uno o varios repositorios además de todos los elementos necesarios para poder realizar testing en local. Finalmente tanto la publicación de las funciones y actualización de las APIs se realizarán de forma automática mediante herramientas de integración continua.
¡Habla con nuestros expertos!
