Adobe Developer App Builder — The Power of Scaling at Your Fingertips

Built on top of Adobe I/O Runtime, App Builder provides a unified development framework for extending and customizing Adobe solutions without worrying about the physical infrastructures. I/O Runtime, which is Adobe’s serverless compute platform, helps developers to scale quickly by providing auto-scaling features. But on the other hand, it doesn’t necessarily mean you can throw everything at it all at once and hope it will magically work out for you. So let’s take a little closer look at how it should be efficiently leveraged.

First, let’s step back with some basics. When talking about scalability, a common use case coming into mind is batch processing such as processing assets, and documents in the hundreds or thousands. With a simplified example, let’s say you have 10 assets and 1 VM, you probably can do something like the image above.

︎

If each asset’s processing takes 2 seconds, then it would take 20 seconds to process them all. if those assets don’t necessarily depend on each other, this approach apparently is the least efficient since it processes them sequentially.

Certainly, parallel jobs can be introduced to boost the efficiency but any given VM has its capacity boundaries that can only support up to n number of jobs concurrently hence wait time in between is usually required. Assuming the current VM can only support 2 jobs at a time and each job can take up to 3 assets, plus a 2 seconds delay is required before bringing up the next jobs, it may look like this,

︎

︎

The total processing time would be around 14 (6+2+6) seconds, which is a 30% reduction from the first approach. Not bad right, but what if you got another VM to help? Then all 4 jobs can be executed at the same time.

︎

︎

In this case, the total processing time would be just 6 seconds, which is a significant 70% reduction. This is excellent but you know in reality getting additional VMs or hardware means more cost (💰) and time (⏳).

I/O Runtime, Adobe’s serverless compute platform serves such use-cases in a cost-efficient manner by leveraging the container’s auto-scaling capabilities. With that, you can easily achieve the same 6-seconds processing SLA through a typical serverless design pattern called fanout like this,

︎

︎

As you can see, in I/O Runtime, VMs become containers that can be auto-scaled up or down based on the loads. Jobs become activations, the invocations of your deployed node.js code that handles the assets processing. During executions, the lifecycles of those containers and activations are well orchestrated in the cloud without any of your intervention.

Furthermore, if we want to scale up the above use case exponentially to a level of hundreds or thousands, and I am telling you to rest assured as such loads can be well managed by a number of containers balanced through a set of throttling configurations you can set in App Builder’s app.config.yaml, isn’t that really the power (🔋) of scaling at your fingertips (☝️)?

︎

︎

Of course, implementing such a solution that can handle processing hundreds or thousands of assets still depends on how you design your batch management but at the platform level, I/O runtime can provide the power you really need through a few settings. Now let’s take a look at what those settings are first. in app.config.yaml, this is how you usually define an action:

︎

︎

Notice there are a few settings under limits. Please note it’s not mandatory to define those settings before you can get the auto-scaling but having a better understanding and setting them with proper values based on testing with estimated loads would definitely help drive your application to success.

timeout

memorySize

concurrency

There are a couple more “hard” limits that are usually not configurable at app.config.yaml level. These are part of the safeguards to ensure the serverless platform always runs in a stable state since it is shared cloud infrastructure.

minuteRate

concurrent

For more information about those settings, please refer to https://developer.adobe.com/runtime/docs/guides/using/system_settings/