DEV Community: Hermann D. Schimpf

How I Managed to Take My Laravel Application to the Serverless World (And How I Almost Died Trying)

Hermann D. Schimpf — Tue, 01 Apr 2025 18:18:57 +0000

Versión en español aquí.

In the first chapter of this journey, we explored why migrating to AWS Serverless was the best decision for my Laravel application. We talked about automatic scalability, cost savings, and freedom from traditional maintenance. But like in every great adventure, the path has its obstacles.

One of the concerns shared by most readers is that since serverless does all the magic for you and scales automatically, your wallet would also need to do so.

And I must be honest with you: I fell into the trap of the magical serverless. While I celebrated the absence of servers, my code wandered through the cloud like a tourist with an unlimited credit card: enthusiastic, but wasting resources at every step.

But hey! That's why I'm here today—to reveal what no tutorial warned me about: the art of writing PHP conscious of Lambda.

Let's dive into how to turn our Laravel application into a true serverless warrior. Yes, we will tackle the necessary optimizations and the precautions we must take.

But let's start lightly with some new concepts.

1. The Serverless Magic

a) Lambda: The Execution Chef

AWS Lambda is, in short, the chef that cooks your code just when needed. Its event-driven model means it only activates upon requests (HTTP, SQS events, cron jobs, etc.), and like an a la carte kitchen, you only pay for the time the stove is used. Additionally, Lambda's free tier allows you to start without worries, as long as you keep an eye on usage limits.

But: Did you know that AWS Lambda, among all the languages it natively supports, PHP is not one of them? 😤

For our peace of mind, Lambda allows us to define our own custom runtimes.

b) Bref: The Bridge that Connects PHP and Lambda

Although I'd love to have created my own solution to run PHP on Lambda like some suggested (and thanks in advance for trusting my abilities so much), sometimes it's not necessary to reinvent the wheel.

That's where Bref comes in, an essential tool that allows us to run PHP applications on Lambda without rewriting all our code.

Great! But, how does it work?

Personally, I love knowing the inner workings of things, but to keep it simple, Bref operates as follows:

When a request enters your application, it is captured by API Gateway and sent to the Lambda function, where Bref's runtime starts PHP-FPM in the background and redirects the request via FastCGI. Once the result is obtained, it is returned to API Gateway, which in turn sends it as a response to the end user.

Simple, right?

c) Serverless Framework: The Glue That Binds All Components

Can you imagine the amount of configurations needed to set up a Lambda function with a custom runtime that runs Bref (and with it, PHP-FPM) so that your Laravel code can work?

Well, you can relax: the Serverless framework does all that for you. You just need to define the necessary components in a serverless.yml configuration file and, with a simple serverless deploy, you're in the cloud! 🚀

2. Preparing Laravel for the Serverless Jungle

First, you need to understand that migrating to a serverless environment means that Laravel must go into "nomadic mode". This means adapting it to be stateless.

Do you remember when I mentioned that Lambda is ephemeral? The simplest way to imagine Lambda is like talking to someone with a very short memory: every time you start the conversation, you have to reintroduce yourself (e.g., session data). Do you give him a notebook to write something down and then return it to you (file uploads)? Forget about it, you won't even find it in the limbo of Inception.

So, some essential adjustments are necessary:

Logs to stderr: You don't have SSH access to Lambda, so you need to store logs in CloudWatch.
Read-only storage: The file system in Lambda is read-only, except for the /tmp directory. So, file uploads need to be stored in S3 (or similar).
Sessions: You need to move session data to cookies or, better yet, use DynamoDB for a more robust solution.
Cache: For simplicity, we'll opt for DynamoDB.
Environment variables: Forget about the .env file in production; you'll need to use variables defined in the serverless.yml configuration file.

Bref's Survival Kit

To make these adjustments easier, the Bref community has created a package called bref/laravel-bridge that automates most of the changes mentioned above.

Getting Our Hands Dirty: Transforming Laravel into a Cloud Nomad

It's time to get our hands dirty.

If you want to follow along step by step, the requirements from this point on are:

PHP (obviously!)
Composer ¹
Node.js ²
serverless ³

Let's start by creating a new Laravel project ⁴:

# Installing Laravel
laravel new laravel-above-the-clouds
cd laravel-above-the-clouds

# Create and migrate the database (sqlite by default)
php artisan migrate

# Install Node.js packages (Vite.js, Tailwind CSS, etc.) and compile assets
npm install && npm run build

Install the bref/bref and bref/laravel-bridge packages ⁵:

composer require bref/bref bref/laravel-bridge --update-with-dependencies

The bref/laravel-bridge package, as I mentioned earlier, resolves the necessary adjustments for Laravel to work in a serverless environment.

Bref already includes a preconfigured serverless.yml file that we can use as a starting point for our first deploy:

php artisan vendor:publish --tag=serverless-config

Think of the serverless.yml file as a set of LEGO instructions for AWS: it's the guide that allows you to set up your application flawlessly.

Deploy the project:

serverless deploy

When finishes, in the console you will get the API Gateway URL to access your application on AWS!

3. But, what happened with my CSS?

The first thing you'll notice is that the assets (CSS and JS) don't load correctly. This happens because, in a serverless environment, we don't have Apache or Nginx to serve static assets; and here I want to make a brief pause.

Taking our application to a serverless environment implies changing our mind-set that a single server is responsible for performing all the tasks to make our application work. In a serverless environment, each component must be managed by a specialized service.

In our case, some of the main components in a Laravel application are as follows:

Component	Servidor Dedicated Server	AWS Serverless
Routes, Controllers, ...	PHP-FPM	Lambda
Static Assets (images, javascript, css)	Apache / Nginx	S3
Session Data	Database / Cookies	RDS / DynamoDB
Cache	Local Disk	DynamoDB / Redis
File Upload	Local Disk	S3
Scheduled Tasks (Schedule)	crontab	EventBridge
Event Queue	SSH $ `php artisan queue:work` / maybe supervisor	SQS
`artisan` Commands	SSH $ `php artisan ...`	Lambda
Application Log	SSH $ `tail -f storage/logs/*`	CloudWatch

But let's take it easy, solving one point at a time.

From Complexity to Simplicity: Serverless Orchestration

From the points mentioned, the bref/laravel-bridge package already solves application logs and session data. A log group is created in CloudWatch for application logs, and session data is stored in cookies (we will later see how to move session data to DynamoDB).

To serve static assets, we have two alternatives:

The hard way: Add the creation of a S3 Bucket to our serverless.yml configuration, obtain the bucket name, build the public URL, and assign it to the ASSET_URL environment variable.
The easy way: Use the serverless-lift plugin ⁶, and let the magic flow.

Although I learned a lot the hard way (I've been following Bref's growth since 2020 ⁷), you can take advantage of community-developed tools that simplify our lives.

We install the serverless-lift plugin and add a new section ⁸ within the serverless.yml file:

serverless plugin install -n serverless-lift

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm

- # ...

  artisan:
    handler: artisan
    runtime: php-82-console

- # ...

+ constructs:
+   website:
+     type: server-side-website
+     assets:
+       '/build/*': public/build
+       # Add here any file or directory that needs to be served from S3

plugins:
  - ./vendor/bref/bref
+   - serverless-lift

Within the constructs section, we have defined a website component of type server-side-website. This tells the serverless-lift plugin to create a CloudFront distribution, which will act as a CDN to serve static files from an S3 Bucket, and also as a reverse proxy, redirecting requests to your PHP application's routes through API Gateway => Lambda.

serverless deploy

This deployment will take an additional 5-7 minutes only once, as CloudFront distributions are created globally. Subsequent deployments will be faster, as long as you don't modify configurations that affect the CloudFront distribution.

In the console output, you will see that you now have two URLs, one from the API Gateway (which we will no longer use), and another from CloudFront, which will serve static assets from the S3 Bucket, and the rest of the routes will be processed by Lambda.

And now the CSS loads correctly! Congratulations, you have deployed your first Laravel application in a serverless environment.

4. Optimizing for the Real World: The Battle Against Cold-Start

You may have noticed that the first time you accessed your application, it took a few extra seconds to respond.

As I mentioned in the previous article, this is called a cold-start and occurs when Lambda initializes a new instance to run your application. This initialization can take 250ms or more, especially if your application is large.

Lambda keeps an instance alive for up to 10 minutes after processing a request, then it is automatically destroyed.

We can address this from several fronts.

a) Keep a Lambda instance always alive ⁹

In low-traffic applications, it is normal to have periods of inactivity greater than 10 minutes, so we may have a higher percentage of requests processed in a cold-start.

Bref provides a special event that we can use to keep a Lambda instance alive. We simply need to add a schedule event in our serverless.yml configuration file with the payload {warmer: true}. Bref will recognize this special event and respond instantly with status code 100 ¹⁰ without executing your code, thus keeping the instance alive.

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm
    events:
      - httpApi: '*'
+       - schedule:
+         rate: rate(5 minutes)
+         input:
+           warmer: true

b) Reducing the size of your application

During a cold-start, AWS Lambda downloads the application package, decompresses it in a temporary environment, and loads the runtime with all the necessary dependencies and configurations. This process, although optimized, adds latency to the first request. Therefore, reducing the package size (for example, by removing development dependencies or unnecessary modules) can significantly shorten this time.

The default serverless.yml file from Bref already ignores certain directories that are not necessary in PHP, such as node_modules.

Development packages

Before deploying, we can uninstall development packages. This will significantly reduce the size of the vendor directory, and consequently, the total size of the code sent to Lambda.

composer install --no-dev

AWS Services dependencies

In most of my applications, the composer package that takes up the most space is aws/aws-sdk-php (required by bref/laravel-bridge).

The good news is that the community has developed a composer script to clean up unused AWS service packages in our application ¹¹. We just need to specify the services we use in the composer.json file:

{
  "name": "laravel/laravel",
  "type": "project",
  ...
  "require": {
    "php": "^8.2",
    "bref/bref": "^2.3",
    "bref/laravel-bridge": "^2.5",
    "laravel/framework": "^11.31",
    "laravel/octane": "^2.8",
    ...
  },
  "scripts": {
+     "pre-autoload-dump": "Aws\\Script\\Composer\\Composer::removeUnusedServices",
    "post-autoload-dump": [
      "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
      "@php artisan package:discover --ansi"
    ],
    ...
  },
  "extra": {
    "laravel": {
      "dont-discover": []
    },
+     "aws/aws-sdk-php": [
+       "DynamoDb",
+       "S3",
+       "Sqs"
+     ]
  },
}

The cleanup script will run every time you run composer install or composer update.

c) Boosting Performance with Laravel Octane

Even when cold-starts occur, Laravel Octane kicks in to keep the application in memory and significantly reduce response times. By avoiding a full Laravel boot on each request, the user experience is greatly improved.

Laravel Octane acts as an accelerator that "keeps the application warm". Once Lambda initializes the application, Octane takes care of keeping it in memory, so that subsequent requests can be served almost instantly. It's like starting a car engine and leaving it ready to go at any moment, rather than starting it from scratch each time.

Steps to implement Laravel Octane:

composer require laravel/octane
php artisan octane:install

Once installed, update the serverless.yml file to use Laravel Octane as the handler ¹². This will ensure that your application runs with the improved performance that Laravel Octane offers:

service: laravel

- # ...

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-82
- # ...

Finally, deploy your application with the changes made:

serverless deploy

d) Metrics that Validate Progress

Applying all the improvements mentioned, we have reduced the initialization time (cold-start) of our application. And with Laravel Octane, we have not only improved the time of the cold-start, but also improved the overall response time of our application.

We can visualize the response times in the CloudWatch logs that were already configured automatically for us.

Cold-start without optimizations (499ms):

Cold-start with Laravel Octane and optimizations (190ms):

Note that when using Laravel Octane, Laravel execution is kept in memory, so be careful of memory leaks ¹³.

5. Falls and Lessons Learned: Errors Every Serverless Migrant Should Know

You may have noticed that there is a function called artisan in the serverless.yml file. This function uses the "console" version of the Bref runtime ¹⁴, which allows us to run Laravel Artisan commands in AWS Lambda.

Since we don't have SSH access to the Lambda instances, Bref provides a bridge to execute cli commands using the bref:cli command from serverless.

serverless bref:cli --args="<artisan command and its options>"
serverless bref:cli --args="route:list"

Optimizations

A very important point I want to reinforce is that we must change our mentality when developing applications for serverless environments. In this new paradigm, it is crucial to design our processes and workflows considering the unique characteristics of serverless computing, such as the ephemeral nature of functions and the billing model based on usage.

Serverless is not expensive... but poorly adapted code is.

In my first month migrating one of my applications to a serverless environment, I made the mistake of not thoroughly reviewing certain processes. One of them was responsible for synchronizing the products of the online store with an external billing system, including updating product images. And as I mentioned in the previous article, some processes are not ideal for execution in a serverless environment. In this case, I was paying for idle time, during the image download, my code in Lambda was not doing anything more than waiting 5-8 seconds per image. With 65,000 items in the store and two daily synchronizations, this resulted in a bill of ~$530 just for the idle time during image download.

This incident led me to redesign the synchronization process. In a first attempt at optimization, I implemented the download of multiple images in parallel using PHP ZTS, which led me to develop the hds-solutions/parallel-sdk library ¹⁵. This version reduced costs to ~160$, but it was still not enough; my goal was to have costs below what I was spending originally on EC2.

In a second attempt, I moved the image download process to a dedicated EC2 instance. Although this significantly reduced costs to ~50$, the application was divided into two separate components.

Finally, in the third version of the synchronization process, after talking to the client, I implemented a small script on the billing system server. Instead of my application downloading the images, this script sent the images directly from the billing system server to S3 using pre-signed URLs ¹⁶. This eliminated the costs associated with image download, leaving only the cost of S3 storage.

6. What's Next?

With this, we close another chapter in our journey to the serverless world! Today, we saw how to transform Laravel into a true cloud nomad, adapting it to live without the weight of a traditional server. But this is just the beginning.

In the next article, we'll dive into the heart of integration: we'll see how to transfer session and cache data to DynamoDB, how to use S3 for file management, configure SQS for queuing and use EventBridge to orchestrate scheduled tasks. See you in the next part!

In the meantime, have you migrated your Laravel application to serverless? Share your experiences in the comments! And for those who haven't, I encourage you to experiment with what we've implemented so far and share your doubts and experiences.

Como Logré Llevar Mi Aplicación Laravel al Mundo Serverless (Y como casi muero en el intento)

Hermann D. Schimpf — Tue, 11 Mar 2025 22:36:10 +0000

English version here.

En el primer capítulo de esta travesía, exploramos por qué migrar a AWS Serverless fue la mejor decisión para mi aplicación Laravel. Hablamos de escalabilidad automática, ahorro de costos y libertad del mantenimiento tradicional. Pero como en toda gran aventura, el camino tiene sus obstáculos.

Una de las preocupaciones que compartieron la mayoría de los lectores es que, dado que serverless hace toda la magia por ustedes y escala automáticamente, su billetera también tendría que hacerlo.

Y debo ser sincero con ustedes: caí en la trampa del serverless mágico. Mientras yo celebraba la ausencia de servidores, mi código se paseaba por la nube como un turista con tarjeta de crédito ilimitada: entusiasta, pero derrochando recursos a cada paso.

Pero hey! Para eso estoy hoy aquí—para revelarles lo que ningún tutorial me advirtió: el arte de escribir PHP consciente de Lambda.

Vamos a meternos de lleno en el cómo convertir nuestra aplicación Laravel en un verdadero guerrero serverless. Sí, atacaremos las optimizaciones necesarias y las precauciones que debemos tener.

Pero empecemos liviano con algunos conceptos nuevos.

1. La Magia Serverless

a) Lambda: El Chef de la Ejecución

AWS Lambda es, en pocas palabras, el chef que cocina el código justo cuando se le necesita. Su modelo basado en eventos significa que solo se activa ante solicitudes (HTTP, eventos de SQS, cron jobs, etc.) y, como en una cocina a la carta, solo pagan por el tiempo que se utiliza la estufa. Además, el nivel gratuito de Lambda les permite arrancar sin preocupaciones, siempre y cuando mantengan un ojo en los límites de uso.

Pero: ¿sabían que AWS Lambda, entre todos los lenguajes que soporta nativamente nativamente, PHP no es uno de ellos? 😤

Para nuestra tranquilidad, Lambda permite definir nuestros propios runtimes personalizados.

b) Bref: El Puente que une PHP y Lambda

Aunque me encantaría haber creado mi propia solución para ejecutar PHP en Lambda como sugirieron algunos (y gracias de antemano por confiar tanto en mis capacidades), a veces no es necesario reinventar la rueda.

Aquí es donde entra Bref, una herramienta esencial que nos permite ejecutar aplicaciones PHP en Lambda sin reescribir todo nuestro código.

¡Buenísimo! Pero, ¿cómo funciona?

Personalmente, me encanta conocer a fondo el funcionamiento interno de las cosas, pero para mantener la simplicidad, Bref opera de la siguiente manera:

Cuando una solicitud ingresa a tu aplicación, esta es capturada por API Gateway y enviada a ejecución en la función Lambda, donde el runtime de Bref inicia PHP-FPM en background y la redigire la solicitud vía FastCGI. Una vez obtenido el resultado, lo devuelve al API Gateway, para que a su vez sea enviado finalmente como respuesta al usuario final.

¿Simple, cierto?

c) Serverless Framework: El Pegamento que Une Todos los Componentes

¿Se imaginan la cantidad de configuraciones que necesitan realizar para poner en marcha una función Lambda, con un runtime personalizado, que ejecute Bref (y con éste, PHP-FPM) para que tu código Laravel pueda funcionar?

Pues ya puedes relajarte: el framework Serverless hace todo eso por ustedes. Solo tienen que definir los componentes necesarios en un fichero de configuración serverless.yml y, con un simple serverless deploy, ¡ya están en la nube! 🚀

2. Preparando Laravel para la Jungla Serverless

Primero deben entender que migrar a un entorno serverless implica que Laravel debe ponerse en "modo nómada". Esto significa adaptarlo para que sea stateless (sin estado).

¿Recuerdan que mencioné que Lambda es efímero? La forma más simple de imaginar Lambda es como conversar con alguien que tiene una memoria muy corta: cada vez que inician la conversación, tienen que volver a presentarte (por ej, los datos de sesión). ¿Le dan un cuaderno para que les anote algo y luego se lo devuelva (upload de archivos)? Olvídenlo, ni en el limbo de Inception lo encontrarán.

Por lo tanto, es necesario realizar algunos ajustes esenciales:

Logs a stderr: No tienen acceso SSH a Lambda, por lo que deben hacer que los logs se almacenen en CloudWatch.
Almacenamiento de solo lectura: El sistema de archivos en Lambda es de solo lectura, a excepción del directorio /tmp. Por lo que la subida de archivos debe ser almacenada en S3 (o similar).
Sesiones: Deben mover los datos de sesión a cookies o, mejor aún, usar DynamoDB para una solución más robusta.
Caché: Por simplicidad, optamos por DynamoDB.
Variables de entorno: Olvídense del fichero .env en producción; deberán utilizar variables definidas en el fichero de configuración serverless.yml.

El Kit de Supervivencia de Bref

Para facilitar estos ajustes, la comunidad de Bref ha creado un paquete llamado bref/laravel-bridge que automatiza la mayoría de los cambios mencionados anteriormente.

Manos a la Obra: Transformando Laravel en un Nómada Cloud

Es hora de ensuciarnos las manos.

Si quieren ir siguiendo el paso a paso, los requisitos a partir de este punto son los siguientes:

PHP (¡obviamente!)
Composer ¹
Node.js ²
serverless ³

Empecemos creando un proyecto de Laravel nuevo ⁴:

# Instalación de Laravel
laravel new laravel-above-the-clouds
cd laravel-above-the-clouds

# Creamos y migramos la base de datos (sqlite por defecto)
php artisan migrate

# Instalamos los paquetes de Node.js (Vite.js, Tailwind CSS, etc.) y compilamos los assets
npm install && npm run build

Instalamos los paquetes bref/bref y bref/laravel-bridge ⁵:

composer require bref/bref bref/laravel-bridge --update-with-dependencies

El paquete bref/laravel-bridge, como mencioné anteriormente, resuelve los ajustes necesarios para que Laravel funcione en un ambiente serverless.

Bref ya incluye un fichero de configuración serverless.yml preconfigurado que podemos utilizar como base para nuestro primer deploy:

php artisan vendor:publish --tag=serverless-config

Piensen en el fichero serverless.yml como las instrucciones de un set de LEGO para AWS: es la guía que le permite montar su aplicación de forma impecable.

Realicen el deploy del proyecto:

serverless deploy

Al finalizar, en la consola obtendrán la URL del API Gateway para acceder a su aplicación en AWS!

3. Pero, ¿qué ha pasado con mi CSS?

Lo primero que notarán es que los assets (CSS y JS) no cargan correctamente. Esto sucede porque, en un entorno serverless, no disponemos de Apache o Nginx para servir los assets estáticos; y aquí quiero hacer una breve pausa.

Llevar nuestra aplicación a un entorno serverless implica cambiar nuestro mind-set de que un único servidor es responsable de realizar todas las tareas para hacer funcionar nuestra aplicación. En un entorno serverless, cada componente debe ser gestionado por un servicio especializado.

En nuestro caso, algunos de los componentes principales en una aplicación Laravel son los siguientes:

Componente	Servidor Dedicado	AWS Serverless
Rutas, Controladores, ...	PHP-FPM	Lambda
Assets estáticos (imágenes, javascript, css)	Apache / Nginx	S3
Datos de sesión	Base de Datos / Cookies	RDS / DynamoDB
Caché	Disco local	DynamoDB / Redis
Upload de archivos	Disco local	S3
Tareas programadas (Schedule)	crontab	EventBridge
Cola de Eventos	SSH $ `php artisan queue:work` / quizás supervisor	SQS
Comandos `artisan`	SSH $ `php artisan ...`	Lambda
Log de Aplicación	SSH $ `tail -f storage/logs/*`	CloudWatch

Pero vayamos con calma, resolviendo un punto a la vez.

De la Complejidad a la Simplicidad: La Orquestación Serverless

De los puntos mencionados, el paquete bref/laravel-bridge ya resuelve el log de la aplicación y los datos de sesión. Se crea un grupo de logs en CloudWatch para los logs de aplicación, y los datos de sesión son almacenados en cookies (más adelante veremos cómo llevar los datos de sesión a DynamoDB).

Para poder servir los assets estáticos, tenemos dos alternativas:

La difícil: Agregar la creación de un Bucket S3 a nuestra configuración serverless.yml, obtener el nombre del bucket, armar la URL pública y asignarla en la variable de entorno ASSET_URL.
La simple: Utilizar el plugin serverless-lift ⁶, y dejar que la magia fluya.

Aunque aprendí mucho por el camino difícil (vengo acompañando el crecimiento de Bref desde 2020 ⁷), ustedes pueden aprovechar que la comunidad ha desarrollado herramientas que nos simplifican la vida.

Instalamos el plugin serverless-lift y agregamos una nueva sección ⁸ dentro del fichero serverless.yml:

serverless plugin install -n serverless-lift

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm

- # ...

  artisan:
    handler: artisan
    runtime: php-82-console

- # ...

+ constructs:
+   website:
+     type: server-side-website
+     assets:
+       '/build/*': public/build
+       # Agreguen aquí cualquier archivo o directorio que necesite ser servido desde S3

plugins:
  - ./vendor/bref/bref
+   - serverless-lift

Dentro de la sección constructs hemos definido un componente website del tipo server-side-website. Esto le dice al plugin serverless-lift que cree una distribución de CloudFront, la cual actuará como CDN para servir los archivos estáticos desde un Bucket S3, y a su vez como proxy reverso, redirigiendo las solicitudes a las rutas de tu aplicación PHP a través de API Gateway => Lambda.

serverless deploy

Este deploy demorará unos 5-7 minutos adicionales por única vez, ya que las distribuciones de CloudFront son creadas globalmente. Los siguientes deploys serán más rápidos, siempre que no modifiquen configuraciones que afecten a la distribución de CloudFront.

En el resultado de la consola verán que ahora disponen de dos URLs, una del API Gateway (que ya no utilizaremos), y otra de CloudFront, el cual servirá los assets estáticos desde el Bucket S3, y el resto de las rutas serán procesadas por Lambda.

¡Y ahora el CSS se carga correctamente! Felicidades, han desplegado su primera aplicación Laravel en ambiente serverless.

4. Optimizando para el Mundo Real: La Batalla Contra el Cold-Start

Seguramente habrán notado que la primera vez que ingresaron a su aplicación, esta demoró unos segundos adicionales en responder.

Así como mencioné en el artículo anterior, esto es llamado cold-start y ocurre cuando Lambda inicializa una nueva instancia para ejecutar su aplicación. Esta inicialización puede llevar 250ms o más, especialmente si tu aplicación es grande.

Lambda mantiene viva una instancia hasta 10 minutos después de procesar una solicitud, luego es destruida automáticamente.

Podemos abordar esto desde varios frentes.

a) Mantener siempre viva una instancia Lambda ⁹

En aplicaciones con poco tráfico, es normal que hayan periodos mayores a 10 minutos de inactividad, por lo que podremos tener un porcentaje mayor de solicitudes procesadas en un cold-start.

Bref dispone de un evento especial que podemos utilizar para mantener viva una instancia de Lambda. Simplemente debemos agregar un evento schedule en nuestro fichero de configuración serverless.yml con el payload {warmer: true}. Bref reconocerá este evento especial y responderá instantáneamente con el código de estado 100 ¹⁰ sin ejecutar tu código, manteniendo así viva la instancia.

service: laravel

- # ...

functions:
  web:
    handler: public/index.php
    runtime: php-82-fpm
    events:
      - httpApi: '*'
+       - schedule:
+         rate: rate(5 minutes)
+         input:
+           warmer: true

b) Reducir el tamaño de su aplicación

Durante un cold-start, AWS Lambda descarga el paquete de la aplicación, lo descomprime en un entorno temporal y carga el runtime junto con todas las dependencias y configuraciones necesarias. Este proceso, aunque está optimizado, añade latencia a la primera solicitud. Por ello, reducir el tamaño del paquete (por ejemplo, eliminando dependencias de desarrollo o módulos innecesarios) puede acortar considerablemente este tiempo de inicialización.

El fichero serverless.yml por defecto de Bref ya ignora ciertos directorios que no son necesarios en PHP, como por ejemplo node_modules.

Paquetes de desarrollo

Antes de realizar el deploy, podemos desinstalar los paquetes de desarrollo. Esto reducirá en gran manera el tamaño del directorio vendor, y en consecuencia, el tamaño total del código enviado a Lambda.

composer install --no-dev

Dependencias de servicios AWS

En la mayoría de mis aplicaciones, el paquete de composer que más ocupa espacio es aws/aws-sdk-php (requerido por bref/laravel-bridge).

Lo bueno es que la comunidad ha desarrollado un script de composer para limpiar los paquetes de servicios AWS no utilizados en nuestra aplicación ¹¹. Solo debemos especificar en el fichero composer.json los servicios que sí utilizamos:

{
  "name": "laravel/laravel",
  "type": "project",
  ...
  "require": {
    "php": "^8.2",
    "bref/bref": "^2.3",
    "bref/laravel-bridge": "^2.5",
    "laravel/framework": "^11.31",
    "laravel/octane": "^2.8",
    ...
  },
  "scripts": {
+     "pre-autoload-dump": "Aws\\Script\\Composer\\Composer::removeUnusedServices",
    "post-autoload-dump": [
      "Illuminate\\Foundation\\ComposerScripts::postAutoloadDump",
      "@php artisan package:discover --ansi"
    ],
    ...
  },
  "extra": {
    "laravel": {
      "dont-discover": []
    },
+     "aws/aws-sdk-php": [
+       "DynamoDb",
+       "S3",
+       "Sqs"
+     ]
  },
}

El script de limpieza correrá cada vez que ejecutemos composer install o composer update.

c) Impulsando el Rendimiento con Laravel Octane

Incluso cuando se producen cold-starts, Laravel Octane entra en acción para mantener la aplicación en memoria y reducir significativamente los tiempos de respuesta. Al evitar un arranque completo de Laravel en cada solicitud, se mejora notablemente la experiencia del usuario final.

Laravel Octane actúa como un acelerador que "mantiene caliente" la aplicación. Una vez que Lambda inicia la aplicación, Octane se encarga de conservarla en memoria, de modo que las siguientes solicitudes se atiendan casi de inmediato. Es como encender el motor de un coche y dejarlo listo para arrancar en cualquier momento, en lugar de encenderlo desde cero cada vez.

Pasos para implementar Laravel Octane:

composer require laravel/octane
php artisan octane:install

Una vez instalado, actualicen el fichero serverless.yml para utilizar Laravel Octane como handler ¹². Esto asegurará que tu aplicación se ejecute con el rendimiento mejorado que ofrece Laravel Octane:

service: laravel

- # ...

functions:
  web:
    handler: Bref\LaravelBridge\Http\OctaneHandler
    runtime: php-82
- # ...

Finalmente, desplieguen su aplicación con los cambios realizados:

serverless deploy

d) Métricas que Validan el Progreso

Aplicando todas las mejoras mencionadas, hemos reducido el tiempo de inicialización (cold-start) de nuestra aplicación. Y con Laravel Octane, no solo hemos mejorado el tiempo del cold-start, sino que mejoramos el tiempo de respuesta general de nuestra aplicación.

Podemos visualizar los tiempos de respuesta en los logs de CloudWatch que ya se configuraron automáticamente por nosotros.

Cold-start sin optimizaciones (499ms):

Cold-start con Laravel Octane y optimizaciones (190ms):

Tengan en cuenta que al utilizar Laravel Octane, se mantiene la ejecución de Laravel en memoria, por lo que deben cuidarse de los memory leaks ¹³.

5. Caídas y Aprendizajes: Los Errores que Todo Migrante Serverless Debe Conocer

Seguramente se dieron cuenta que hay una función llamada artisan en el fichero serverless.yml. Esa función utiliza la versión "consola" del runtime de Bref ¹⁴, la cual nos permite ejecutar comandos de Laravel Artisan en AWS Lambda.

Como no tenemos acceso SSH a las instancias de Lambda, Bref nos disponibiliza un puente para poder ejecutar comandos cli mediante el comando bref:cli de serverless.

serverless bref:cli --args="<comando artisan y sus opciones>"
serverless bref:cli --args="route:list"

Optimizaciones

Un punto muy importante que quiero reforzar es que debemos cambiar nuestra mentalidad al desarrollar aplicaciones para entornos serverless. En este nuevo paradigma, es crucial diseñar nuestros procesos y flujos de trabajo considerando las características únicas de la computación serverless, como la naturaleza efímera de las funciones y el modelo de facturación basado en el uso.

Serverless no es caro... pero el código mal adaptado sí lo es.

En mi primer mes migrando una de mis aplicaciones al entorno serverless, cometí el error de no revisar detalladamente ciertos procesos. Uno de ellos se encargaba de sincronizar los productos de la tienda en línea con un sistema de facturación externo, incluyendo la actualización de imágenes de productos. Y como mencioné en el artículo anterior, algunos procesos no son ideales para ejecutarse en un entorno serverless. En este caso, estaba pagando por tiempo muerto, durante la descarga de imágenes, mi código en Lambda no estaba realizando nada más que esperar 5-8 segundos por imágen. Con 65,000 artículos en la tienda y dos sincronizaciones diarias, esto resultó en una factura de ~$530 solo por el tiempo inactivo durante la descarga de imágenes.

Este incidente me llevó a rediseñar el proceso de sincronización. En un primer intento de optimización, implementé la descarga de múltiples imágenes en paralelo utilizando PHP ZTS, lo que me llevó a desarrollar la librería hds-solutions/parallel-sdk ¹⁵. Esta versión redujo los costos a ~160$, pero aún no era suficiente; mi objetivo era que los costos estuvieran por debajo de lo que gastaba originalmente en EC2.

En un segundo intento, trasladé el proceso de descarga de imágenes a una instancia EC2 dedicada. Aunque esto redujo significativamente los costos a ~50$, la aplicación quedó dividida en dos componentes separados.

Finalmente, en la tercera versión del proceso de sincronización, tras conversar con el cliente, implementé un pequeño script en el servidor del sistema de facturación. En lugar de que mi aplicación descargara las imágenes, este script enviaba las imágenes directamente desde el servidor del sistema de facturación a S3 utilizando URLs pre-firmadas ¹⁶. Esto eliminó por completo los costos asociados a la descarga de imágenes, quedando únicamente el costo de almacenamiento en S3.

6. ¿Qué Sigue?

¡Con esto, cerramos otro capítulo en nuestro viaje hacia el mundo serverless! Hoy vimos cómo transformar a Laravel en un auténtico nómada en la nube, adaptándolo para vivir sin el peso de un servidor tradicional. Pero esto es solo el comienzo.

En el próximo artículo nos adentraremos en el corazón de la integración: veremos cómo trasladar los datos de sesión y caché a DynamoDB, cómo aprovechar S3 para el manejo de archivos, configurar SQS para gestionar colas y utilizar EventBridge para orquestar tareas programadas. ¡Nos vemos en la siguiente entrega!

Mientras tanto, ¿han migrado su aplicación Laravel a serverless? ¡Compartan sus experiencias en los comentarios! Y para los que aún no lo han hecho, les animo a experimentar con lo que hemos implementado hasta ahora y a compartir sus dudas y experiencias.

Por qué Migré Mi Aplicación Laravel a AWS Serverless (Y Por Qué Podría Ahorrarte Tiempo y Dinero)

Hermann D. Schimpf — Wed, 29 Jan 2025 00:01:51 +0000

English version here.

Spoiler: No se trata solo de ahorrar dinero—aunque mi billetera no se queja.

Imagina esto: has creado una brillante aplicación en Laravel—tu obra maestra, una navaja suiza digital con funciones tan útiles que podrían cortar mantequilla... o los comentarios de los usuarios. Pero hay un detalle. Cada mes estás pagando por una instancia EC2 que está tan infrautilizada como una membresía de gimnasio después de enero. Mientras tanto, escalar se siente como intentar aparcar un crucero en medio de un huracán.

¿Te ha pasado? A mí también.

Hace tres años, hice algo que la mayoría de los desarrolladores llamarían una locura: desplegué PHP en AWS Lambda. “¿PHP? ¿En serverless? ¡Eso es como poner piña en la pizza!”, decían.

Pero aquí estoy, tres años después, comiendo mi pizza con piña con orgullo. Déjame contarte por qué Laravel en serverless es la actualización en la nube que no sabías que necesitabas.

1. El Problema del Hosting Tradicional con Laravel

(ó: Por qué mis instancias EC2 estaban teniendo una crisis existencial)

Antes de serverless, mi aplicación Laravel vivía en EC2. Para los no iniciados, EC2 es la versión de Amazon de un servidor privado virtual, donde alquilas una parte de una máquina para ejecutar tu código. Suena bien, ¿verdad? Hasta que la realidad te golpea más fuerte que un composer update rebelde.

a) Primero está: El Costo de Existir

Ejecutar una instancia EC2 es como tener un Tesla que dejas encendido las 24 horas del día, solo por si acaso quieres conducir. Mi aplicación no siempre estaba ocupada, pero eso no detenía el contador. Entre instancias EC2, balanceadores de carga y almacenamiento compartido, gastaba alrededor de $110/mes en un stack de servidores que pasaba la mayor parte del tiempo inactivo. ¿Mi billetera? Hundida como el Titanic.

Lo sé, no es mucho en el gran esquema de las cosas, pero como desarrollador/emprendedor en solitario, cada dólar cuenta.

b) Después: Las Pesadillas de Escalado

Las instancias EC2 son como ese amigo que reacciona de forma exagerada a todo.

¿Pico de tráfico? "¡Me voy a caer ahora, gracias!"
¿No hay tráfico? "¡Igual seguiré quemando tu dinero!"

Gestionar el autoescalado se sentía como enseñar a un pez a hacer malabares—es posible, pero ¿a qué costo? Ajustar manualmente los grupos de escalado, configurar balanceadores de carga y rezar para no provisionar de más se sentía como un segundo trabajo al que nunca me postulé.

c) Y finalmente: DevOps, el Interno No Pagado

Nadie me dijo que el desarrollo con Laravel venía con un lado de responsabilidades de sysadmin:

Aplicar parches de seguridad.
Depurar configuraciones de nginx/apache a las 3 AM.
Susurrar palabras bonitas a los comandos sudo, esperando que funcionaran esta vez.

No me inscribí para esta vida.

Fue entonces cuando comencé a explorar alternativas, y serverless se destacó como la solución perfecta para resolver estos dolores de cabeza.

2. AWS Serverless: El Resurgimiento de PHP en la Nube

Aclaremos un mito: serverless no significa "sin servidores". Solo significa que los servidores son el problema de otra persona. En este caso, AWS hace el trabajo pesado mientras yo me concentro en lo que realmente disfruto: programar.

a) Lambda: El Mago Impulsado por Eventos

AWS Lambda es como un superhéroe que solo aparece cuando lo necesitas. Ejecuta tu código en respuesta a eventos—solicitudes HTTP, mensajes de SQS, tareas programadas, tu nómbralo. Y cuando el trabajo termina, desaparece más rápido que una pizza gratis en una reunión de desarrolladores.

Sin costos inactivos: Solo pagas por el tiempo de ejecución (medido en milisegundos).
Magia de escalado automático: ¿Recibiste un pico de 100,000 solicitudes? Lambda las maneja sin sudar (ni vaciar tu cuenta bancaria).
Stateless por diseño: Es como un borrón y cuenta nueva cada vez, un diseño que te obliga a pensar de forma modular.

b) Servicios Administrados: Los Héroes Anónimos

Serverless no es solo Lambda—es un ecosistema. AWS reemplaza tu infraestructura DIY (hazlo tú mismo) con servicios administrados que "simplemente funcionan":

Base de datos: Opciones como Aurora Serverless (MySQL/Postgres) para los amantes de SQL.
S3: Almacena tus archivos sin preocuparte por quedarte sin espacio en disco.
SQS: Desacopla trabajos de larga duración y procésalos de forma asíncrona.

c) La Paradoja de PHP

Debo admitirlo: PHP no nació para serverless. Es como pedirle a un pez que trepe un árbol—se quejará, pero eventualmente lo hará. Laravel, tradicionalmente dependiente de PHP-FPM, necesitó algunos ajustes para prosperar en el mundo efímero de Lambda:

Sesiones: Muévelas a una base de datos externa, como MySQL o Redis.
Almacenamiento de archivos: Redirige todas las operaciones de almacenamiento a S3, usando el facade Storage de Laravel.
Gestión de colas: Configura SQS como el controlador predeterminado para la ejecución de tareas asíncronas.
Caching: Aprovecha servicios externos como Redis o DynamoDB en lugar de almacenamiento local.
Optimización del tiempo de arranque: Minimiza los inicios en frío (cold starts) recortando lo innecesario (dependencias no utilizadas).
Variables de entorno: Reemplaza los archivos .env con AWS Secrets Manager o Parameter Store para una gestión centralizada y segura de la configuración.

Recuerda que serverless no se trata solo de reemplazar servidores por funciones Lambda. Se trata de repensar tu arquitectura—dejando que AWS maneje los puntos de dolor operativos mientras tú te concentras en construir.

3. Cómo Serverless Desbloquea Todo el Potencial de Laravel

Entonces, ¿Laravel en serverless realmente cumple sus promesas?

Serverless no es solo una palabra de moda, es un cambio transformador. La belleza de Laravel en serverless radica en su capacidad para resolver los puntos débiles del alojamiento tradicional, al mismo tiempo que permite soluciones más rápidas, escalables y rentables. Pero la verdadera magia ocurre cuando profundizas en cómo se combinan estos beneficios. Vamos a desglosarlo.

a) Cold Starts: Separando el Mito de la Realidad

Los cold starts ocurren cuando Lambda inicializa una nueva instancia. Piensa en ello como si PHP despertara de una siesta. Los críticos los tratan como si fueran el apocalipsis, pero son manejables:

Realidad: Los cold starts típicos con PHP + Laravel rondan los ~3-5 segundos.
Soluciones:
- Laravel Octane: Mantiene la aplicación viva entre solicitudes, reduciendo los tiempos de inicio. Las solicitudes posteriores se procesan en ~200ms o menos.
- Concurrencia aprovisionada: AWS pre-calienta instancias para endpoints críticos (cuesta extra, pero vale la pena para puntos clave).

Para la mayoría de las aplicaciones, los retrasos menores a 3 segundos durante el tráfico bajo son aceptables. La mayoría de los usuarios no notará un cold start, especialmente durante cargas máximas de tráfico cuando Lambda permanece "caliente".

b) Escalado Sin Dolor

El escalado en el hosting tradicional suele parecer una batalla interminable. Con serverless, el escalado se vuelve muy sencillo: ya no es necesario ajustar las reglas de autoescalado ni cruzar los dedos durante un aumento repentino de tráfico. AWS Lambda elimina las conjeturas, escalando horizontalmente por defecto.

Aquí va un ejemplo:

Escenario: Tu aplicación se vuelve viral 🚀 yey!
Antigüa configuración con EC2: Comienza a experimentar latencia, corres a iniciar sesión en AWS, ajustas manualmente la cantidad de instancias, y rezas por lo mejor 🫠. Ah, y no olvides equilibrar correctamente esas instancias entre las zonas de disponibilidad.
Nueva configuración con Lambda: AWS crea automáticamente tantas instancias como sea necesario, manejando miles de solicitudes concurrentes sin que levantes un dedo. Agarras unas palomitas de maíz y observas las métricas de CloudWatch como si fuera una serie de Netflix 🍿.

Esto no es solo comodidad, es tranquilidad. Mientras tú te concentras en celebrar el éxito de tu aplicación, Lambda hace el trabajo pesado. ¿Y lo mejor? Solo pagas por el tiempo de computación que usas, no por la capacidad inactiva que podrías necesitar "por si acaso".

c) Eficiencia de Costos: El Jugador Más Valioso

Serverless no solo ahorra dinero, es como tener un buffet de $5 donde solo pagas por lo que comes.

Mi antigua configuración con EC2: ~$110/mes.
- 4x instancias EC2 t3.small: $60.00
- 1x Balanceador de Carga: $16.40
- 1x EBS (almacenamiento compartido entre instancias EC2): $7.80
- 1x instancia RDS MySQL (db.t4g.medium): ~26.00
Lambda: ~$34/mes (¡un ahorro del 60%!).
- Lambda, API Gateway ~2.5M solicitudes (~500ms / 512MB de memoria) /mes: $4.80
- Servicios gestionados (S3, SQS, CloudWatch): ~$2.90
- Instancia RDS MySQL (db.t4g.medium): ~26.00

Recurso	Costo EC2	Costo Lambda
Computación	$60.00	$4.50
Red (LB, API Gateway)	$16.40	$0.30
Almacenamiento	$7.80	$2.90
Base de datos	$26.00	$26.00
TOTAL	$110.20	$33.70

En resumen, serverless no solo ahorra dinero, libera ancho de banda mental. Cuantos menos recursos desperdicie preocupándome por el sobreaprovisionamiento, más puedo concentrarme en construir algo increíble.

Hasta ese momento, todavía utilizaba una instancia MySQL como motor de base de datos. Publicaciones posteriores explorarán cómo migrar a DynamoDB para reducir aún más los costos.

d) Libertad de Mantenimiento: Di Adiós a las Pesadillas Operativas

Serverless me liberó de las cadenas del mantenimiento de servidores. Aquí está cómo:

No más actualizaciones manuales: AWS maneja parches de seguridad, actualizaciones del sistema operativo y mejoras de tiempo de ejecución, lo que significa que siempre estás utilizando una infraestructura segura y actualizada.
Configuraciones simplificadas: Con servicios como API Gateway y S3, la complejidad de gestionar configuraciones nginx y despliegues personalizados se convierte en cosa del pasado.
Capacidad elástica: Olvídate de pagar de más por recursos de servidor no utilizados o de apresurarte a provisionar más durante picos de tráfico. Lambda escala automáticamente para satisfacer la demanda y deja de facturar cuando está inactivo.
Enfócate en las características, no en apagar incendios: El tiempo que antes dedicaba a aplicar parches o a depurar problemas en producción ahora lo invierto en crear características y mejorar la experiencia del usuario.

Serverless no solo reduce el mantenimiento, elimina las distracciones operativas que te impiden programar.

4. Pero, ¿Es Laravel Serverless para Todos?

Por muy revolucionario que sea Laravel en serverless, no es una solución universal. Para algunas aplicaciones, la naturaleza stateless y orientada a eventos de serverless puede parecer un sueño hecho realidad. Para otras, puede parecer como tratar de encajar un cuadrado en un círculo. Antes de subirte al tren de serverless, retrocedamos un poco y evaluemos si es adecuado para tu proyecto.

a) La Naturaleza Stateless: Una Espada de Doble Filo

Laravel adora las operaciones que guardan información entre interacciones, como almacenar archivos localmente y guardar sesiones en el sistema de archivos. Para pasar a serverless, debes cambiar:

Sesiones: Usa bases de datos (MySQL/Postgres) o Redis; nada más de depender del sistema de archivos.
Archivos: Redirige las subidas de archivos a S3, o evita completamente pasar por Laravel y utiliza URL pre-firmadas de S3.
Logs: Configura Laravel para transmitirlos a CloudWatch.
Configuración: Mueve las variables .env a AWS Secrets Manager o Parameter Store para una gestión centralizada.
Colas: Migra los trabajos a AWS SQS para manejar colas y mensajes de manera escalable.

b) Consideraciones Sobre la Dependencia del Proveedor (Vendor Lock-In)

Los servicios de AWS son mágicos, pero también son propietarios:

¿Migrar de SQS a colas Redis? Prepárate para reescribir código.
¿Quieres pasar de Lambda a Docker? Tómate un café: será una noche larga.

c) Cuándo No Optar por Serverless

Serverless no es una bala de plata para todas las cargas de trabajo. Debes evitarlo si:

Necesitas WebSockets: Aunque se puede lograr con servicios como API Gateway + WebSocket APIs o herramientas de terceros como Ably, añade complejidad.
Tu aplicación tiene cargas computacionales pesadas: Tareas como inferencia de IA/ML o codificación de video pueden alcanzar el límite de tiempo de 15 minutos de Lambda.
Dependes de servicios con estado: Las aplicaciones que asumen un disco persistente o un estado del servidor pueden ser costosas de refactorizar.

5. ¿Qué Sigue?

Laravel en serverless tiene el potencial de transformar la forma en que construyes y despliegas aplicaciones, pero la verdadera magia está en la implementación. ¿Estás listo para dar el salto y darle a tu aplicación Laravel el tratamiento serverless? Mantente atento a la Parte 2, donde te guiaré a través de los pasos exactos para llevar esta arquitectura a la vida.

Una pregunta para ti: ¿Cuál es tu mayor temor con serverless? ¡Compártelo abajo y abordaré los 3 principales en la Parte 2!

Why I Migrated My Laravel App to AWS Serverless (And Why It Could Save You Time and Money)

Hermann D. Schimpf — Tue, 28 Jan 2025 03:03:21 +0000

Versión en español aquí.

Spoiler: It’s not just about saving money—though my wallet isn’t complaining.

Picture this: you've built a shiny Laravel app—your magnum opus, a digital Swiss Army knife with features so sharp they could cut through butter... or user feedback. But there's a catch. Every month, you're stuck paying for an EC2 instance that’s as underutilized as a gym membership after January. Meanwhile, scaling feels like trying to parallel park a cruise ship during a hurricane.

Been there? I have too.

Three years ago, I did something that most developers would call madness: I deployed PHP on AWS Lambda. "PHP? On serverless? That's like putting pineapple on pizza!" they said.

But here I am, three years later, eating my pineapple pizza with pride. Let me tell you why serverless Laravel is the cloud upgrade you didn't know you needed.

1. The Problem with Traditional Laravel Hosting

(or: Why my EC2 instances were having an existential crisis)

Before serverless, my Laravel app lived on EC2. For the uninitiated, EC2 is Amazon’s version of a virtual private server, where you rent a slice of a machine to run your code. Sounds nice, right? Until reality hits you harder than a rogue composer update.

a) First there is: The Cost of Breathing

Running an EC2 instance is like owning a Tesla you keep running 24/7, just in case you feel like driving. My app wasn’t always busy, but that didn’t stop the meter from ticking. Between EC2 instances, load balancers, and shared storage, I was shelling out around $110/month for a server stack that spent most of its time idling. My wallet? Doing a Titanic impression.

I know, it’s not much in the grand scheme of things, but as a solo developer/entrepreneur, every dollar counts.

b) Then is: The Scaling Nightmares

EC2 instances are like that one friend who overreacts to everything.

Traffic spike? "I'll crash now, thanks!"
Traffic hush? "I’ll keep burning your money anyway!"

Managing autoscaling felt like teaching a fish to juggle—it's possible, but at what cost? Manually tweaking scaling groups, configuring load balancers, and praying I didn’t overprovision felt like a second job I never applied for.

c) And lastly DevOps: The Unpaid Intern

Nobody told me Laravel development came with a side of sysadmin responsibilities:

Applying security patches.
Debugging nginx/apache configs at 3 AM.
Whispering sweet nothings to sudo commands, hoping they’d work this time.

I didn't sign up for this life.

That’s when I started exploring alternatives, and serverless stood out as the perfect fit for solving these headaches.

2. AWS Serverless: PHP’s Cloud Glow-Up

Let’s clear up a myth: serverless doesn't mean "no servers". It just means the servers are someone else's problem. In this case, AWS does the heavy lifting while I focus on what I actually enjoy—coding.

a) Lambda: The Event-Driven Wizard

AWS Lambda is like a superhero that only shows up when you need it. It executes your code in response to events—HTTP requests, SQS messages, cron jobs, you name it. And when the job's done, it disappears faster than a free pizza at a dev meetup.

No idle costs: Pay only for execution time (measured in milliseconds).
Auto-scaling magic: Got a 100,000 requests spike? Lambda handles them without breaking a sweat (or your bank account).
Stateless by design: It's like a clean slate every time—a design that forces you to think modularly.

b) Managed Services: The Unsung Heroes

Serverless isn't just Lambda—it's an ecosystem. AWS replaces your DIY infrastructure with managed services that "just work":

Database: Serverless-friendly options like Aurora Serverless (MySQL/Postgres) for SQL lovers.
S3: Store your files without worrying about running out of disk space.
SQS: Decouple long-running jobs and process them asynchronously.

c) The PHP Paradox

I have to admit it: PHP wasn't born for serverless. It's like asking a fish to climb a tree—it'll complain, but it'll eventually get there. Laravel, traditionally reliant on PHP-FPM, needed some love to thrive in Lambda's ephemeral world:

Sessions: Move them to an external database, like MySQL or Redis.
File storage: Reroute all storage operations to S3, using Laravel’s Storage facade.
Queue handling: Set up SQS as the default queue driver for async task execution.
Caching: Leverage external services like Redis or DynamoDB instead of local storage.
Boot time optimization: Minimize cold starts by trimming fat (unused dependencies).
Environment variables: Replace .env files with AWS Secrets Manager or Parameter Store for secure and centralized configuration management.

Keep in mind that serverless isn't just about swapping out servers for Lambda functions. It’s about rethinking your architecture—letting AWS handle the operational pain points while you focus on building.

3. How Serverless Unlocks Laravel’s Full Potential

So, does serverless Laravel actually deliver on its promises?

Serverless isn't just a buzzword—it's a game-changer. The beauty of serverless Laravel lies in its ability to solve the pain points of traditional hosting while enabling faster, more scalable, and cost-effective solutions. But the real magic happens when you dive into how these benefits come together. Let’s break it down.

a) Cold Starts: Separating Fact from Fiction

Cold starts occur when Lambda initializes a new instance. Think of it as PHP waking up from a nap. Critics treat them like the apocalypse, but they’re manageable:

Reality: Typical cold starts with PHP + Laravel are ~3-5 seconds.
Solutions:
- Laravel Octane: Keeps the app alive between requests, reducing boot times. The subsequent requests are processed in ~200ms or less.
- Provisioned Concurrency: AWS pre-warms instances for critical endpoints (costs extra, but worth it for critical endpoints).

For most apps, sub-3s delays during low traffic are acceptable. Most users won't notice a cold start, especially during peak traffic loads when Lambda stays warm.

b) Scaling Without Tears

Scaling in traditional hosting often feels like fighting a never-ending battle. With serverless, scaling becomes effortless—no more tweaking auto-scaling rules or crossing your fingers during a traffic surge. AWS Lambda eliminates the guesswork, scaling horizontally by default.

Here's an example:

Scenario: Your app goes viral 🚀 yey!.
Old EC2 Setup: It starts getting latency, you scramble to log into AWS, manually adjust instance counts, and hope for the best 🫠. Oh, and don't forget to balance those instances properly across availability zones.
New Lambda Setup: AWS automatically spins up as many instances as needed, handling thousands of concurrent requests without you lifting a finger. You grab popcorn and watch CloudWatch metrics like it’s a Netflix series 🍿.

This isn’t just convenience—it’s peace of mind. While you focus on celebrating your app's success, Lambda does the heavy lifting. And the best part? You’re billed only for the compute time you use, not for the idle capacity you might need "just in case".

c) Cost Efficiency: The Real MVP

Serverless doesn't just save money—it’s like having a $5 buffet where you only pay for what you eat.

My old EC2 setup: ~$110 /month.
- 4x EC2 t3.small instances: $60.00
- 1x Load Balancer: $16.40
- 1x EBS (shared storage between EC2 instances): $7.80
- 1x RDS MySQL instance (db.t4g.medium): ~26.00
Lambda: ~$34 /month (a 60% saving!).
- Lambda, API Gateway ~2.5M requests (~500ms / 512MB memory) /month: $4.80
- Managed services (S3, SQS, CloudWatch): ~$2.90
- RDS MySQL instance (db.t4g.medium): ~26.00

Resource	EC2 Cost	Lambda Cost
Compute	$60.00	$4.50
Networking (LB, API Gateway)	$16.40	$0.30
Storage	$7.80	$2.90
Database	$26.00	$26.00
TOTAL	$110.20	$33.70

In short, serverless doesn’t just save money—it frees up mental bandwidth. The fewer resources I waste worrying about over-provisioning, the more I can focus on building something amazing.

At that time, I was still using a MySQL instance as database engine. Later posts will explore migrating the database engine to DynamoDB to cut costs further.

d) Maintenance Freedom: Say Goodbye to Ops Nightmares

Serverless freed me from the shackles of server maintenance. Here’s how:

No more manual updates: AWS handles server patching, operating system updates, and runtime upgrades, meaning you’re always running on secure, up-to-date infrastructure.
Simplified configurations: With services like API Gateway and S3, the complexity of managing nginx configs and custom deployments becomes a thing of the past.
Elastic capacity: Forget overpaying for unused server resources or scrambling to provision more during traffic spikes. Lambda automatically scales to meet demand and stops billing when idle.
Focus on features, not firefighting: The time I once spent applying patches or debugging production issues now goes into building features and improving user experience.

Serverless doesn't just reduce maintenance; it removes the operational distractions that keep you from coding.

4. But, "Is Serverless Laravel for Everyone?"

As revolutionary as serverless Laravel is, it's not a one-size-fits-all solution. For some apps, the stateless, event-driven nature of serverless can feel like a dream come true. For others, it might feel like trying to fit a square peg into a round hole. Before you jump on the serverless bandwagon, let’s take a step back and evaluate whether it’s the right fit for your project.

a) Statelessness: The Double-Edged Sword

Laravel loves stateful operations like storing files locally and caching sessions in the filesystem. To go serverless you must change:

Sessions: Use databases (MySQL/Postgres), or Redis—no more filesystem reliance.
Files: Reroute uploads to S3, or bypass Laravel entirely via pre-signed S3 URLs.
Logs: Configure Laravel to stream them to CloudWatch.
Configuration: Move .env variables to AWS Secrets Manager or Parameter Store for centralized management.
Queues: Migrate jobs to AWS SQS for scalable queueing and message handling.

b) Vendor Lock-In Considerations

AWS services are magical, but they’re also proprietary:

Migrating from SQS to Redis queues? Have fun rewriting code.
Want to move from Lambda to Docker? Grab a coffee—it’ll be a long night.

c) When Not to Go Serverless

Serverless isn’t a silver bullet for every workload, you should consider avoiding it if:

You need WebSockets: While achievable with services like API Gateway + WebSocket APIs or third-party tools like Ably, it adds complexity.
Your app has heavy computational workloads: Tasks like AI/ML inference or video encoding may hit Lambda’s 15-minute timeout.
You rely on stateful services: Applications that assume a persistent disk or server state can be costly to refactor.

5. What’s Next?

Serverless Laravel has the potential to transform the way you build and deploy applications, but the real magic is in the implementation. Are you ready to make the leap and give your Laravel app the serverless treatment? Stay tuned for Part 2, where I'll walk you through the exact steps to bring this architecture to life.

Question for you: What’s your biggest serverless fear? Share below—I’ll tackle the top 3 in Part 2!