¿Vienes de un mundo On-Premise donde la gestión de los recursos hardware y la planificación de capacidad de computo te dan dolores de cabeza continuamente?
¿Has migrado a la nube, pero sigues trabajando con instancias en las que gestionas la capacidad de computo manualmente?
¿Te gustaría centrarte en la funcionalidad y no en la gestión del stack tecnológico subyacente?
En este blog te explicamos cómo hacerlo mediante la adopción de tecnologías Serverless.
¿Qué es Serverless?
Podríamos definir Serverless o computación sin servidor como un modelo de computación en la nube cuya principal característica es que el desarrollador de la aplicación ha de centrarse solamente en la lógica de negocio, y no debe preocuparse por factores como:
- Planificar la capacidad de computo
- La configuración
- La gestión
- El mantenimiento
- La tolerancia a fallos
- El escalado de la infraestructura sobre la que se ejecuta dicha aplicación
Al delegar estas tareas al proveedor de tecnología Serverless, en este caso el proveedor cloud, será el quoen garantice que el stack sobre el que se ejecuta nuestro código es:
- Óptimo
- Altamente disponible
- Tolerante a fallos
- Ofrece el mejor rendimiento posible
- Se factura por el tiempo que se ha estado usando, lográndose un verdadero pago por uso. Esto es de vital importancia.
No olvidemos que, en el caso de máquinas virtuales en la nube, se factura cuando la máquina está levantada, independientemente de que el software que ejecuta esté recibiendo carga de trabajo o no.
Servicios cloud gestionados de AWS
Es importante tener en cuenta que serverless no hace referencia únicamente a computación, sino que también es aplicado a otra serie de servicios cloud en los que se aplica la misma filosofía, los denominados servicios cloud gestionados. En el caso de Serverless AWS, tenemos principalmente los siguientes:
- Computación o Informática (AWS Lambda o AWS Fargate)
- Almacenamiento (Amazon S3 o Amazon EFS)
- Gestión de Datos (Amazon Aurora Serverless o Amazon DynamoDB)
- Integración de Aplicaciones (Amazon API Gateway o Amazon SQS)
Beneficios de Serverless
Una vez entendido el concepto serveless, es importante entender que ventajas aporta a negocio, es decir, que mejoras tendrá una empresa en caso de aplicar esta tecnología en la ejecución de sus cargas de trabajo del día a día.
Las principales ventajas son las siguientes:
> Pago por uso
Es la ventaja más inmediata, ya que si una carga de trabajo se ejecuta solamente durante un lapso de tiempo concreto (como puede ser una carga de trabajo de actualización de datos, de carga en el datawarehouse o cualquier carga de trabajo periódica), solamente se nos facturará por el tiempo que hayamos utilizado el servicio.
Aparte del ahorro inmediato, hay un segundo ahorro derivado de la inexistencia de posibles costes errores de programación de encendido y apagado de los entornos, que muchas veces suponen un gran coste detectado solamente al recibir la factura mensual del proveedor.
> Eliminación de costes de “ownership”
Dentro de este apartado englobamos los costes asociados a los recursos (personas) que dedicamos a mantener el ecosistema de máquinas virtuales. Tareas como despliegues de infraestructura, parcheado de sistemas operativos, planificación de capacidad para responder a picos con costes óptimos, planificación encendidos y apagados para cargas puntuales, etc.
De esta forma, al no haber infraestructura que gestionar, no habrá costes de gestión.
> Alta disponibilidad y tolerancia a fallos incluída
Si bien cuando desplegamos un aplicativo sobre un stack que nosotros gestionamos tenemos que encargarnos también de velar por la alta disponibilidad y la tolerancia a fallos de la arquitectura desplegada (grupos de autoescalado, clústeres, configuraciones activo-pasivo, etc.), en caso de optar por tecnologías Serverless, esta parte suele estar resuelta por el proveedor cloud.
De nuevo, los costes asociados a desplegar servicios o metodologías que garanticen unos determinados SLA a nivel de disponibilidad y tolerancia a fallos se ven reducidos, y en muchos casos eliminados, al ser el proveedor cloud quien ha resuelto esa problemática.
> Agilidad, rendimiento, escalabilidad y paralelización
La mayoría de los Servicios Serverless que veremos en este blog tienen en común un objetivo primordial, hacer que la carga de trabajo se pueda ejecutar con:
- El máximo rendimiento
- El mínimo coste
- La mayor paralelización
- La mayor escalabilidad que permita absorber los picos de trabajo más demandantes que podamos encontrarnos
Por ejemplo, el servicio estrella dentro de la familia serveless de AWS, concretamente AWS Lambda, ofrece una concurrencia máxima de 1000 funciones lambda ejecutándose en paralelo, limite que podría aumentarse si fuese necesario.
Como vemos, no se trata de una máquina virtual que rinde bien hasta llegar al limite de 500 peticiones concurrentes y comienza a sufrir a partir de la petición numero 501. Con AWS Lambda estamos hablando de que el rendimiento de la función 1 será igual a de la función 501, sin verse el uno influenciado o perjudicado por el otro.
Evolución de arquitectura: Serverless y Microservicios
Si comparamos las arquitecturas de software tradicionales con las más recientes, hay una gran diferencia que salta a la vista: actualmente se tiende a desplegar arquitecturas desacopladas en detrimento de arquitecturas monolíticas.
Arquitecturas monolíticas
Si bien es cierto que una arquitectura monolítica puede llegar a ofrecer un muy buen rendimiento ya que todo está acoplado y forma parte de un mismo código, a la larga hay un gran problema: modificar un módulo o funcionalidad requiere realizar modificaciones en todos y cada uno de los módulos o funcionalidades con los que interactúa, ya que en la fase de diseño no se tuvieron seguramente en cuenta la definición de una API, o de unos interfaces que cumplir con el objetivo de independizar los ciclos de vida de cada una de las funcionalidades o módulos.
Debido a esto, cuando se trabaja con una arquitectura monolítica durante mucho tiempo, la arquitectura comienza a parecerse a una tela de araña donde todo se relaciona con todo, lo cual dificulta enormemente el mantenimiento y gestión del ciclo de vida del entorno.
Arquitecturas desacopladas
Por ello, las arquitecturas recientes apuntan cada vez más a eliminar ese acople mediante el uso de arquitecturas desacopladas. Estas arquitecturas descomponen el monolito en varias piezas de software más pequeñas que se centran en una funcionalidad concreta (autenticación, comunicaciones, algoritmos concretos, etc) denominadas microservicios.
Siempre y cuando hagamos una buena definición de los interfaces que esos microservicios han de tener para comunicarse con el resto, podemos independizar los ciclos de vida de cada uno de ellos, consiguiendo una arquitectura desacoplada.
Es aquí donde la tecnología Serverless ofrece una gran ventaja: existen una gran cantidad de microservicios sin estado, orientados a recibir una petición, realizar un procesado más o menos sencillo y devolver información, para lo cual no resulta óptimo tener una máquina virtual ejecutándose 24x7.
¿Cómo adoptar la tecnología Serverless?: Casos de uso
Como siempre decimos, la tecnología no es más que un facilitador para que negocio sea más óptimo, económico y/o tenga alguna ventaja sobre la competencia. De este modo, la mejor manera de entender cómo adoptar la tecnología Serverless es entender cuáles son los KPI de negocio.
A continuación, veremos varios casos de uso en los que, al introducir servicios Serverless, producen una mejora inmediata en uno o varios de los aspectos que hemos ido comentando (costes, mantenimiento, recursos dedicados a la gestión, rendimiento, etc.)
Primer Caso de Uso: De monolito a Serverless
Casi todas las compañías tienen al menos un desarrollo monolítico que han heredado o que diseñaron en su día y han ido manteniendo hasta ahora. Normalmente, cuanto más tiempo lleva en producción, más acoplados están sus módulos o funcionalidades.
En estas situaciones resulta extremadamente complicado deshacer esa maraña y, de la noche a la mañana, pasar de un monolito a una arquitectura desacoplada basada en microservicios, ya que requiere una dedicación profunda de muchos departamentos, principalmente el de desarrollo, conjuntamente con operaciones y, lógicamente, con negocio.
Precisamente por este motivo no se llega a dar el paso de modernización de los desarrollos, por el coste y el riesgo. No obstante, nadie ha dicho que solamente tengamos 2 alternativas (no hacer nada o hacerlo todo desde 0), sino que desde Neteris tenemos experiencia planteando y desplegando arquitecturas híbridas que nos permitan modernizar un desarrollo paulatinamente.
La forma es muy sencilla: cada vez que hay que desarrollar una nueva funcionalidad o realizar cambios sustanciales en alguna de las ya presentes, recomendamos que ese desarrollo sí se realice sobre tecnología Serverless, manteniendo 2 flujos de ejecución en función de donde se ejecute esa funcionalidad: Monolito VS Serverless.
En el diagrama anterior podemos ver 2 partes bien diferenciadas:
- Izquierda, donde aparecen máquinas EC2
- Derecha, donde aparecen servicios Serverless, entre ellos lambda.
En este caso, se trata de una aplicación monolítica a la que se ha añadido una componente Serverless que irá alojando esas nuevas funcionalidades a medida que el aplicativo vaya evolucionando, siguiendo la estrategia de ir trasladando paulatinamente funcionalidades desde el monolito hacia el Serverless, con el objetivo final de tener una arquitectura completa basada en microservicios, ejecutándose en servicios Serverless de AWS.
El punto de entrada será el servicio API Gateway, y ahí será donde se dirija la petición hacia el monolito o hacia el servicio Serverless correcto. Por ejemplo, la autenticación se realizará en AWS Cognito, y si hemos conseguido desplegar la funcionalidad requerida en el nuevo entorno, será una función lambda la que realice el proceso de la petición y almacene la información en la base de datos.
Es importante remarcar que, en este caso, uno de los primeros pasos fue sustituir componentes del entorno monolítico, en este caso la Base de Datos, por servicios Serverless, en este caso a un servicio de base de datos relacional sin servidor denominado Aurora Serverless.
Segundo Caso de Uso: Solucion ETL + Datawarehouse Serverless
Este segundo caso de uso consiste en la construcción de una solución que incluye un componente ETL (Extract Transform & Load) y un componente de Datawarehouse, con el objetivo de obtener una solución lista para conectarse a una base de datos origen, por ejemplo, de un ERP, y ser accedida por cualquier solución de análisis y visualización como pueden ser Amazon Quicksight, Microsoft Power BI o Tableau.
Como podemos ver en la arquitectura anterior, la información extraída de la base de datos origen mediante el servicio DMS (Database Migration Service) Serverless, irá a parar a un datalake, un bucket de Amazon S3 desde el que el servicio AWS Glue obtendrá la información cada vez que el AWS Glue Crawler detecte que se han depositado nuevos datos en el datalake.
De esta forma, realizará la transformación de los datos, volcando la información transformada en el datawarehouse, de nuevo un bucket de Amazon S3, y los metadatos en el AWS Glue Data Catalog.
Con esto ya tenemos una solución Serverless de ETL y Datawarehouse. Solamente nos queda conectar las herramientas de análisis y visualización para que puedan acceder a esa información, y aquí el servicio clave es AWS Athena, el cual nos permite lanzar SQL directamente al dataset almacenado en el bucket de S3 que hace las veces de datawarehouse.
Gracias a servicios como AWS DMS, AWS Glue, Amazon S3 y AWS Athena, nos olvidamos de:
- La gestión de la infraestructura
- Sistemas operativos
- Planificación de capacidad
- De los siempre costosos y peliagudos aspectos de licenciamiento, términos de uso de software de terceros, etc.
A través de estos 2 casos de uso reales, podemos ver que el hecho de basarnos en la tecnología serverless nos ha traído una serie de ventajas que tienen un gran impacto en negocio, ya que la tecnología Serverless trae beneficios no solamente a IT sino a negocio en general al mejorar costes, agilidad y elasticidad. ¡Si quieres saber más sobre cómo puede afectar a tu negocio, ponte en contácto con nosotros!