Things like AWS Lambda and/or Google Cloud Functions are basically just replacements for traditionally lightweight tasks that smart people realized could be done without a server. Right now, you can create these serverless functions in languages you might expect: Javascript, Python, Go, etc.
I am wondering if those who know more about this might be able to comment on the possibility of using Julia in this capacity. I imagine that one big hurdle is startup/compilation time?
@tbeason I had similar thoughts. It would be amazing to call Julia functions by an AWS Lambda. Function as a Service.
This thread may be useful:
Avik Sengupta pointed out to me that this had been looked at, however there is a limit on the payload size for lambda functions.
As I remember there are intrinsically supported languages for lambdas. If you want to add your own you must install it - such as Julia. Then you hit the size limit.
That was some time ago - perhaps you coud revisit this,.
A deployment package is a ZIP archive that contains your function code and dependencies. You need to create a deployment package if you use the Lambda API to manage functions, or if you need to include libraries and dependencies other than the AWS SDK. You can upload the package directly to Lambda, or you can use an Amazon S3 bucket, and then upload it to Lambda. If the deployment package is larger than 50 MB, you must use Amazon S3.
The first step I see to effective Julia on Lambda is publishing a Julia Lambda container image with a runtime interface client to ECR Public. From what I can tell, this means a base install of Julia running a loop over HTTP Lambda Runtime API calls, fetching events and executing them and then reporting status. A service for running that HTTP server locally is available here. An example of the thing we’d need to implement in Julia is available here.
I’ve created a package to make this a little easier here: https://github.com/harris-chris/julia-for-aws-lambda
As others have said, there’s no native runtime for Julia in AWS Lambda, meaning the function has to be containerized, but this works fine. The only minor pain point is that if the container is cold-started then it takes a little longer than usual (say, 2s) to start. If warm-started it is very fast. I’m currently working to bring in PackageCompiler.jl, which should bring cold-start times down to that of warm-start times.