Creating tiny serverless service

In an environment that is fully migrated to "cloud", running delayed or planned operations using CRON is not only old fashioned, but mainly expensive. This short article will show how we solved this in Webnode on our platform running fully in AWS

What are we trying to solve?

1. We want to run delayed operations based on some user action and we want it to use native (cheaper) AWS service.
   -> Clear Solution: Amazon EventBridge Scheduler
2. Event Bridge needs to call "something" and that "something" needs to run anytime scheduler wants and not be needlessly expensive when not needed.
   -> Our best solution: AWS Lambda
3. But now we need some way to deploy AWS Lambda functions, that will:
   | Run on language we know (PHP)
   | Will be automatically deployed
   | Can switch easy between x86 and ARM (to choose best possible price-performance solution)
   | Can run on our multiple environments (testing/staging/production)
   | Can be easily upgraded.
   | Whole environment should be configurable

Lambda: Bref comes to rescue

Bref and its integration with open-Source version of Serverless solves all of our problems. All we need to do is prepare the serverless.yaml configuration and a PHP "script" to handle the required functionality.

This approach allows us to develop the Lambda function like any other application we're familiar with. Additionally, we have the advantage that, unlike other programming languages, in PHP, the Request (or Event, in this case) already runs as a unique process.

Our Usecase

We need one of our applications to check the status of a customer's order one hour after it was created and if the order was not completed, notify the customer. A similar use case you might be familiar with is an e-shop reminding you that you have items in your cart and prompting you to complete your order.

We already have an application that tracks order creation and an API endpoint for checking order status and performing subsequent actions. All we need is to call this API one hour after the order is created.

In our previous on-premises solution, we would have achieved this by creating a new CRON job that periodically checked for unprocessed events and processed them once their time had expired. This approach required a CRON process running continuously, even if no events were scheduled.

Now, we can simply create an event that triggers a Lambda function. This function serves as a lightweight intermediary between the delayed schedule and our API.

How Our Lambda function is implemented

Our implementation is built using a single repository that includes a pipeline capable of deploying itself to AWS. This repository can be imagined in segments:

• Serverless configuration
• Index.php
• Task to be ran.
• Gitlab deployment

Serverless configuration

In this step, we set up key aspects of the Lambda function, such as its name, access rights, environment variables, PHP runtime, and processor architecture.

Index.php

In our case, this is a small file that initializes a Task with its constructor dependencies using our Dependency Injection (DI) setup.

Task

Here, we can work as if this Task was part of a larger application. We can leverage dependencies, use any Composer packages, and essentially work as if we are in any other application, without needing to understand how everything else in this setup functions.

Gitlab Deployment

We use gitlab and gitlab-ci.yml for deployment. In this file we have configuration that allows to:

1. From merge request deploy to testing
2. From master deploy to testing/staging/production

Monitoring

Currently, we have two levels of monitoring for the Lambda function.

Application Logs

By integrating existing packages into our Lambda function, we have access to detailed logs and tracing. This enables us to track logs from the point of creation in Webnode Checkout all the way to the final action processed by the Webnode API, which is triggered by this Lambda.

Cloudwatch

In AWS CloudWatch, we can monitor and review each run of the Lambda function, track its billed time, and configure alarms to detect and address any issues.

Conclusion

Overall, this represents a new approach for us in handling planned or delayed events. We are transitioning away from relying on CRON and instead leveraging cloud-specific solutions to reduce costs while optimizing for speed and reliability.

Those of us who worked on this project hope that this trend of adopting new and exciting technologies will continue, providing even more stories to share with you in the future.