Aprende sobre las ventajas y desventajas de un enfoque sin servidor para tomar la decisión correcta para tu pila tecnológica
Serverless es un tema apasionante para muchas personas, y es algo que ha evolucionado mucho desde su concepción. Comenzó siendo un enfoque para deshacerse de los servidores, no en el lado técnico (obviamente) sino en el lado de la gestión.
La idea detrás de esto es hacer que los desarrolladores, y las personas de TI en general, se concentren en crear código y desplegarlo en algún tipo de infraestructura gestionada. La contraposición habitual era contra plataformas basadas en contenedores. Con servicios de Kubernetes gestionados, como EKS o AKS, todavía eres responsable de los trabajadores que están ejecutando tu carga. No necesitas preocuparte por el componente de administración. Pero, de nuevo, necesitas manejar y gestionar algunas partes de la infraestructura.
Este enfoque también se incorporó en otros sistemas, como iPaaS y ofertas puras de SaaS en cuanto a low code o no code. E incluimos el concepto de función como servicio para marcar la diferencia en este enfoque. Entonces, la primera pregunta es: ¿Cuál es la principal diferencia entre una función que despliegas en tu proveedor sin servidor y una aplicación que puedes usar en tu iPaaS?
Depende de la perspectiva que quieras analizar.
Voy a omitir los detalles técnicos sobre capacidades de escalar a cero, técnicas de calentamiento, etc., y me centraré en la perspectiva del usuario. La principal diferencia es cómo estos servicios te van a cobrar en función de tu uso.
iPaaS u ofertas similares de SaaS te van a cobrar en función de la instancia de la aplicación o algo similar. Pero la plataforma sin servidor/función como servicio te va a costar en función del uso que hagas de esa función. Eso significa que te van a cobrar en función del número de solicitudes que reciba tu función.
Eso es un cambio de juego. Proporciona la implementación más precisa de las operaciones optimizadas y el enfoque de elasticidad. En este caso, es directo y claro que solo vas a pagar por el uso de tu plataforma. La economía es excelente. Echa un vistazo a la oferta de AWS Lambda hoy:
El nivel de uso gratuito de AWS Lambda incluye 1 millón de solicitudes gratuitas por mes y 400,000 GB-segundos de tiempo de cómputo por mes.
Y después de ese primer millón de solicitudes, te van a cobrar 0.20 $ por cada millón de solicitudes adicionales.
Al leer las oraciones anteriores, probablemente estés pensando: «Eso es perfecto. ¡Voy a migrar todo a ese enfoque!»
No tan rápido. Este estilo de arquitectura no es válido para todos los servicios que puedas tener. Aunque la economía es excelente, estos servicios vienen con limitaciones y anti-patrones que significan que deberías evitar esta opción.
Primero, comencemos con las restricciones que la mayoría de los proveedores de la nube definen para este tipo de servicios:
- Tiempo de ejecución: Esto suele estar limitado por tu proveedor de la nube a un número máximo de segundos de ejecución. Eso es justo. Si te van a cobrar por solicitud, y puedes hacer todo el trabajo en una sola solicitud que tarda 10 horas en completarse utilizando los recursos del proveedor, ¡probablemente eso no sea justo para el proveedor!
- Recursos de memoria: También limitados, por las mismas razones.
- Carga útil de la interfaz: Algunos proveedores también limitan la carga útil que puedes recibir o enviar como parte de una función, algo a tener en cuenta cuando estás definiendo el estilo de arquitectura para tu carga de trabajo.
En un momento, veremos los anti-patrones o cuándo deberías evitar usar esta arquitectura y enfoque
Pero primero, una breve introducción a cómo funciona esto a nivel técnico. Esta solución puede ser muy económica porque el tiempo que tu función no está procesando ninguna solicitud no está cargado en sus sistemas. Por lo tanto, no está utilizando ningún recurso en absoluto (solo una pequeña parte de almacenamiento, pero esto es algo ridículo) y generando cualquier costo para el proveedor de la nube. Pero eso también significa que cuando alguien necesita ejecutar tu función, el sistema necesita recuperarla, lanzarla y procesar la solicitud. Eso generalmente se llama el «tiempo de calentamiento», y su duración depende de la tecnología que uses.
- Servicios de baja latencia y Servicios con tiempo de respuesta crítico: Si tu servicio necesita baja latencia o el tiempo de respuesta debe ser agresivo, este enfoque probablemente no va a funcionar para ti debido al tiempo de calentamiento. Sí, hay soluciones alternativas para resolver esto, pero requieren solicitudes ficticias al servicio para mantenerlo cargado y generan costos adicionales.
- Proceso por lotes o programado: Esto es para API sin estado para el mundo nativo de la nube. Si tienes un proceso por lotes que podría llevar tiempo, tal vez porque está programado por las noches o los fines de semana, podría no ser la mejor idea ejecutar este tipo de carga de trabajo.
- Servicios masivos: Si pagas por solicitud, es importante evaluar el número de solicitudes que tu servicio va a recibir para asegurarte de que los números todavía estén a tu favor. Si tienes un servicio con millones de solicitudes por segundo, probablemente este no sea el mejor enfoque para tu presupuesto de TI.
Al final, serverless/función como servicio es tan genial por su simplicidad y lo económico que es. Al mismo tiempo, no es una bala de plata para cubrir todas tus cargas de trabajo.
Necesitas equilibrarlo con otros enfoques arquitectónicos y plataformas basadas en contenedores, o ofertas de iPaaS y SaaS, para mantener tu caja de herramientas llena de opciones para encontrar la mejor solución para cada patrón de carga de trabajo que tenga tu empresa.
