¿App engine (PaaS) y serverless computing cumplen ambos una misma función?
La línea entre ambos conceptos a menudo puede ser borrosa.
En pocas palabras: App Engine y Serverless Computing no cumplen la misma función, pero ambos son parte de la misma tendencia de abstraer la infraestructura. App Engine es una plataforma que ha adoptado características de la computación serverless, pero su propósito fundamental es diferente.
¿Qué es Serverless Computing?
La computación serverless es un modelo de ejecución de código. El punto clave es que tú, como desarrollador, no te preocupas por los servidores, las máquinas virtuales, los contenedores, ni nada de la infraestructura subyacente. Tú solo subes tu código (una función) y esta se ejecuta en respuesta a un evento (una petición HTTP, una subida de archivo, un mensaje en una cola, etc.).
Modelo de Pago: Pagas solo por el tiempo de ejecución de tu código. Si no se ejecuta, no pagas nada.
Escalabilidad: Se escala automáticamente, de cero a millones de peticiones.
Ejemplo: Google Cloud Functions, AWS Lambda, Azure Functions.
¿Qué es Google App Engine?
Google App Engine es una Plataforma como Servicio (PaaS). Fue una de las primeras en ofrecer la abstracción de servidores, pero su modelo original era diferente al de serverless. En App Engine, tú despliegas una aplicación completa (un microservicio, una API REST, una aplicación web), no solo una función.
Modelo de Pago: Pagas por las instancias que están "vivas" (incluso si no están recibiendo peticiones). Aunque ahora puedes configurar el escalado automático hasta cero, su propósito principal sigue siendo tener un servicio en funcionamiento.
Escalabilidad: Escala automáticamente las instancias de tu aplicación.
Ejemplo: Un backend completo para una aplicación móvil o un sitio web.
Diferencias y Similitudes
Característica | Serverless Computing (Cloud Functions) | App Engine (PaaS) |
Modelo de Ejecución | Basado en eventos. Tu código se activa por un evento. | Basado en aplicaciones. Tu código es un servicio continuo. |
Escalabilidad | Escala de 0 a N instancias al instante. | Escala de instancias activas a más instancias. |
Modelo de Cobro | Pago por uso (tiempo de ejecución + invocaciones). | Pago por instancias (pago por minuto de instancia activa). |
Caso de Uso Común | APIs simples, procesamiento de datos, tareas programadas. | Aplicaciones web completas, APIs robustas, backends. |
Un buen símil es pensar en Serverless Computing como un servicio de taxi (solo pagas por el viaje, de punto A a B), mientras que App Engine es como alquilar un coche (pagas por el tiempo que lo tienes, sin importar si lo estás usando o no).
En conclusión, aunque App Engine ha adoptado el escalado a cero y la flexibilidad, su propósito principal sigue siendo el alojamiento de aplicaciones completas, a diferencia del modelo serverless puro que se enfoca en la ejecución de código en respuesta a eventos. App Engine es una plataforma, mientras que "serverless" es un paradigma.
Sí, es posible, pero es un reto técnico que requiere adaptar la arquitectura de Laravel para que sea completamente stateless y utilice servicios externos para persistir la información.
Laravel fue diseñado originalmente para ejecutarse en un entorno de servidor web tradicional, donde la aplicación se ejecuta en un proceso de larga duración. La computación sin servidor, en cambio, ejecuta tu código en funciones efímeras de corta duración que se inician y se detienen con cada solicitud.
Para que Laravel y la computación sin servidor se entiendan, necesitas un "adaptador serverless" que se encargue de traducir la solicitud HTTP entrante al entorno serverless en un objeto Request
que Laravel pueda procesar.
Herramientas para lograrlo
Las soluciones más populares para ejecutar Laravel en un entorno sin servidor son:
Laravel Vapor: Es la solución oficial y administrada por el equipo de Laravel para AWS Lambda. Automatiza casi todos los problemas de la transición, desde el manejo de colas hasta el almacenamiento de archivos y la base de datos. Está diseñado para que la experiencia sea lo más cercana posible a un despliegue tradicional de Laravel.
Bref: Una herramienta de código abierto para desplegar aplicaciones PHP y Laravel en AWS Lambda. Requiere más configuración manual que Vapor, pero es gratuita y muy flexible.
Adaptaciones necesarias
Independientemente de la herramienta que elijas, tu aplicación debe ser reestructurada para manejar la naturaleza stateless del entorno. Esto significa que no puedes confiar en el sistema de archivos del servidor para almacenar sesiones, cachés o archivos cargados.
Recurso | Solución para Entornos Serverless |
Sesiones | Almacenarlas en una base de datos o en una caché externa como Redis. |
Archivos | Usar servicios de almacenamiento de objetos como AWS S3 o Google Cloud Storage. |
Colas de Jobs | Utilizar servicios de colas gestionadas como Amazon SQS o Google Cloud Pub/Sub. |
Cache | Usar Redis o Memcached como backend. |
Ventajas y Desventajas
Ventajas
Escalabilidad ilimitada: La aplicación escala automáticamente para manejar cualquier volumen de tráfico.
Paga por uso: Solo pagas por las solicitudes y el tiempo de computación que tu aplicación consume, lo que puede ser muy rentable para sitios con tráfico variable.
Reducción de costos de infraestructura: No tienes que pagar por servidores inactivos esperando peticiones.
Desventajas
Arquitectura más compleja: Tienes que gestionar más servicios externos, lo que puede aumentar la complejidad.
Latencia de "arranque en frío": La primera vez que una función es invocada después de un periodo de inactividad, puede haber un ligero retraso mientras el entorno se inicializa.
Restricciones de tiempo de ejecución: Las funciones sin servidor tienen un límite de tiempo de ejecución (generalmente unos pocos minutos), lo que las hace inadecuadas para procesos de larga duración.
En resumen, sí, puedes ejecutar Laravel en un entorno serverless, pero no es tan simple como un despliegue tradicional. Es una excelente opción si buscas una escalabilidad masiva y una estructura de costos basada en el consumo, y si estás dispuesto a adaptar la arquitectura de tu aplicación para ello.
No hay comentarios:
Publicar un comentario