Limitaciones de Serverless
CLOUD NATIVE, INFRAESTRUCTURA.En esta nueva entrada de nuestro blog continuamos con la segunda parte de “Serverless computing o informática sin servidores” y explicamos las limitaciones de esta arquitectura y en qué casos puede no ser recomendable su uso.
Las arquitecturas sin servidor son aquellas aplicaciones que se ejecutan en gran medida usando servicios de terceros (también conocidos como “Back-end” o “BaaS”), o que se ejecutan en contenedores efímeros con códigos personalizados (“FaaS”). En este momento el proveedor host de este tipo de servicios más conocido es AWS Lambda.
Como explicamos en nuestra anterior entrada, el término “sin servidor” no implica que el código se ejecute sin un servidor, sino que la empresa o persona que posee este tipo de sistemas no necesita comprar o alquilar servidores o máquinas virtuales para que dicho código de back-end sea ejecutado.
Desventajas del computing sin servidor:
Problemas en el sistema de APIs de terceros
Usar APIs de terceros siempre trae consigo varios problemas. Algunos de estos incluyen el control de dichos proveedores, los problemas de mantenimiento, el bloqueo de proveedores y consideraciones relacionadas con la seguridad, entre otros. Otras desventajas incluyen que al implementar una API se debe renunciar al sistema, lo cual puede conducir a mucho tiempo de inactividad del mismo y en este proceso se pierde funcionalidad, se presentan limitaciones inesperadas y hay cambios en los costos.
Falta de herramientas operativas
Los desarrolladores siempre dependerán de los proveedores para las herramientas de depuración y monitoreo. Dicha depuración es difícil y generalmente requiere de un acceso especial para obtener una cantidad de métricas relevantes para identificar la causa de algún problema en específico.
Complejidad de la arquitectura
Para decidir el tamaño de una función en particular es necesario evaluarla, implementarla y probarla. Por esta razón debe haber un equilibrio entre la cantidad de funciones que una aplicación debe tener. Dado que resulta engorroso administrar gran cantidad de funciones en una sola aplicación, el ignorar esto puede causar la creación de monolitos.
Inconvenientes de implementación
Realizar las pruebas de integración en este tipo de apps es difícil. Las unidades de cada función de las integraciones con FaaS son mucho más pequeñas que con otras arquitecturas, por lo tanto, se debe confiar totalmente en dichas pruebas de integración. Además, también existen problemas relacionados con el control de versiones y empaquetado, ya que es posible que se deba implementar cada artefacto FaaS por separado.
Las limitaciones
Este tipo de implementación es una forma diferente de construir y operar sistemas, pero, al igual que las otras alternativas, tiene sus limitaciones y desventajas. Aunque aún es muy nueva, la plataforma FaaS más madura es la AWS Lambda, cuya primera versión (muy limitada) fue lanzada a finales del año 2014.
Toda innovación y novedad trae consigo algunas grandes advertencias: no todo funciona bien y existen partes para las que aún no se conoce bien la mejor forma de utilizarlas.
Limitaciones inherentes
Algunas de las limitaciones del computing sin servidor son inherentes a este enfoque, lo que significa que no pueden ser completamente evitadas. Se debe aprender a solucionar este tipo de problemas o, incluso, a vivir con ellos.
Las principales limitaciones inherentes que tiene este enfoque son las siguientes:
Estado
A pesar de parecer obvio, en las aplicaciones de este tipo la gestión del estado puede resultar algo complicada. Además de que los componentes son explícitamente diseñados para ser almacenes de datos, la mayoría de sus componentes son efectivamente “sin estado” y deben, por definición, interactuar con otros componentes con estado para mantener cualquier información más allá de su vida útil.
Latencia
En una aplicación de este tipo, la latencia entre sus componentes siempre será una preocupación, ya que estos pueden ubicarse de manera confiable dentro del mismo rack o en la misma instancia del host, e incluso pueden ser unidos en el mismo proceso. Sin embargo, la naturaleza muy distribuida y poco compacta de las aplicaciones sin servidor dan por hecho que la latencia siempre será algo de qué preocuparse.
Pruebas locales
La dificultad de las pruebas locales es una de las limitaciones más importantes de la arquitectura de aplicaciones sin servidor, ya que la implementación de pruebas de extremo a extremo son increíblemente complejas.
Pérdida de control
Muchas de las limitaciones del enfoque sin servidor se relacionan con el hecho de que las plataformas FaaS o BaaS son desarrolladas y operadas por un tercero. Esto implica inherentemente ceder el control total de la administración del software sobre el cual el código se ejecuta.
Como existen diferentes tipos de control en las apps, la pérdida de control ocurre de diferentes formas: en la configuración, el rendimiento, la solución de problemas y la seguridad. Todas estas son limitaciones inherentes dentro de este enfoque.
Conclusión
Serverless es un tipo de arquitectura con ventajas y desventajas que deben ser considerada en el largo plazo y en contexto. La arquitectura sin servidor tiene limitaciones inherentes y retos de implementación.
Las inherentes se refieren al desarrollo y operación de aplicaciones sin servidor en general y se relacionan directamente con el control de las mismas y con el uso de una plataforma de servidor o de la nube, de modo que se debe ceder una cantidad importante de control al o a los proveedores.
Las consideraciones de implementación, que no son menos importantes, en su mayoría podrían ser resueltas o abordadas por los mismo proveedores o por la comunidad en general.
Los dos tipos de limitaciones con el tiempo tendrán soluciones, a medida que vayamos ganando experiencia colectiva en la creación y ejecución de aplicaciones sin servidor.