Costs and Performance for iFaaS (Lolo) vs FaaS (AWS)

Serverless architecture is a powerful system design that lets developers build and run code without managing servers and without paying for idle cloud services.

AWS is one of the largest cloud service providers, where you can create a robust Serverless system. However, there are three perspectives below that we’d like to touch on the differences between Lolo Code (integration function-as-a-service) and AWS (function-as-a-service) in making Serverless Apps.

• Cost
• Performance
• Efficiency

Cost to Build & Run a Serverless App

AWS Pricing

AWS offers you a pay-as-you-go approach for pricing. In other words, you’ll pay for how much you’ve used AWS resources.

Pricing Example AWS

An API is used in a Serverless Web Application that invokes Lambda to return dynamic webpage content. The site gets 10,000 page loads per minute. Each API request is 12KB and the response is 46 KB.

This will be a total of 432 million requests per month.

Monthly costs = $418.8 ($0.97 per million)* in Amazon API Gateway costs (not including Lambda nor DynamoDB)

Lolo Code Pricing

Lolo Code also offers you a pay-as-you-go model but it’s more straightforward, you pay for the amount of events your app needs to process concurrently rather than the total of events.

You can subscribe to 1 Application with 1 LCU (or Replica) with 256 mb memory and 0.125 cores (CPU) starting at 9 euros a month. Free tier includes two apps with 1 LCU each but requires you to engage with the app once a week to keep it running. If you want to increase your replicas for a free-tier app the price starts at 9€ each.

Pricing Example Lolo Code

Taking the same example as above for API Gateway we did some calculations.

If the site gets 10,000 page loads per minute and each API request is 12KB and the response is 46 KB, we need to process 10k req/min for a Lolo app. This requires 0.131 (cores) and 85 mb memory. Consequently, this requires two replicas at 9€ each but we will still have room for more requests within that app. The result is

Monthly costs = €18 per month cost for the Lolo app.

Lolo could be seen as a combination of AWS Lambda and API Gateway. You can also use Lolo’s baked in state store to store your dynamic webpage content. This way there would be no hidden costs. The total you would pay would simply be €18 per month.

Performance Differences between iFaaS and FaaS

AWS may offer everything you need, and you can design a large-scale app with redundancy, scalability, and high availability. On the other hand, you should know network systems well and be familiar with the AWS architecture to unlock its potential. Serverless also comes with its downsides. One of them is the notorious “cold start.”

To illustrate, your app will wait for a certain period until a container is ready to run code. This request takes longer to process because a Serverless app needs to spin up the function (i.e. download code, library, modules/etc, and initialize an environment to run code). This issue appears in any Serverless apps either in Lolo Code or AWS.

AWS

AWS has gotten notoriously better since the Lambda fleets migrated to the Firecracker technology in 2018. However, as the function still needs to spin up cold starts will prevail.

In AWS, you can wake up Lambda with a minimum number of containers. But you’ll have to pay an extra cost to run it continually.

We had a user do a test* on AWS Lambda’s delayed starts this summer (using AWS EU). The result of the experiment is below.

| 1 min | 180 ms
| 15 min | 750 ms
| 3h | 1467 ms
| 10h | 2060 ms

Lolo Code

Apps on Lolo Code also have the “Cold Start” issue but your Lolo App keeps running until you stop it. I.e. since Lolo Code is working with containers your app will technically always be running until you stop it. Essentially you shouldn’t have to care about cold starts.

However, the user from above that did the test on AWS did the exact same test in Lolo Code.* His results are shown below.

| 1 min | 172 ms
| 15 min | 210 ms
| 3h | 602 ms
| 10h | 890 ms

He was operating in India using Lolo’s EU runtime which is something to keep in mind.

Something else to consider is if your script is running for too long, then AWS may not be the best choice. AWS Lambda’s max timeout 900 seconds (15 minutes) whereas Lolo does not have max timeout.

Efficiency: How to build and manage a Serverless app?

Building APIs in both AWS and Lolo Code is straightforward. However, there are difference.

AWS

In AWS you build your Lambda function and later hook it up with another service, API Gateway, that will act as its trigger. Here you have an anonymous function that will get triggered when something happens. This is the very ideal of FaaS, an anonymous function that only gets triggered when an event happens.

As the function is stateless, you’ll need to fetch data elsewhere, in this case you may use AWS DynamoDB to store and fetch data.

This looks like a scalable and robust design, however, you need to consider some important factors:

• How to manage changes to software code?
• How to deploy or customize your app quickly?
• Where to start checking across the services in case of any infra issues?

You will find it a hassle to manage your app whenever you need to change and test your code quickly on any cloud service provider such as AWS, GCP, Azure/etc.

See a full tutorial on how to build an HTTP API with Lambda, API Gateway and DynamoDB here.

Lolo Code

With Lolo Code you can add an HTTP trigger and then use the baked in state store for a database. You can add a new raw function to act as your lambda (to follow the exact use case from above).

Your Lolo application may look like this.

You will decide what is in the code blocks by simply changing its code (NodeJS) and then rename it.

Furthermore, Lolo Code offers Library functions that you can copy and use existing template functions and create your own templates. For the API case, we can use the Lolo/CRUD API v3 function to quickly create a CRUD API. This will be faster than setting up our own from scratch.

You don’t have to change too many things on different places. With Lolo Code, all your work is in one place.

Once you save and run your application you do not have to worry about maintaining or provisioning your own servers to keep it running (i.e. it is completely “serverless”). Unless you decide to use a private runtime in your own public cloud account or private datacenter. See Lolo runtime-d docs here. Runtime-d is a standalone binary that turns any laptop or linux server into a Lolo runtime.

Summary

AWS is a widespread cloud platform, offering fully featured services from data centers globally.

With AWS, you can do many things, but it also requires decent effort and time to turn your idea into an app and deploy it on AWS. Lolo Code will help you to speed up your development and keep it running for less. Although Lolo Code uses the AWS cloud to deploy apps, it also offers you the ability to use your own runtimes, making it cloud agnostic.