Data-scientist who loves to use #datascienceforgood, especially in ecology, energy and the environment. Bonsai, gardening, bikes and music when I'm not at a keyboard.
I've spent a lot of last year putting up some (simple) data science services on was lambda in both python and r. These services interface with our monolithic laravel PHP product.
I've been planning on writing up my experience more fully in a post. I've started a while back, but never got it to a publishable state. I'll try and get it done by the end of the month.
Generally, my experience was positive, and though I got both python and R services up in production, getting the R service up was a lot more of a faff. A key issue was database connection. For some still mysterious reason, it still doesn't work, so we send the data in the body of the API. It's good enough for now at least. Bakdata make a lovely R layer for Aws lambda that was key to the solution.
What do you mean by double billing? It's a term I haven't heard before.
So double billing would generally refer a vendor charging the customer for the same product twice. In the case of FaaS vendor’s double billing refers to the synchronous invocation of other functions. When a function makes a call to another service, you pay for the waiting time — even if the code is using async I/O. This means you wait for the result of each function called, and hence must pay for the wait time. This wait time is directly correlated to section.
So in all. this additional billing violates one of the serverless principles: pay for what you use, not idle time!
Without intrinsic support from the FaaS vendor, it is impossible to avoid double billing while still maintaining the core principle of the serverless computing model.
Data-scientist who loves to use #datascienceforgood, especially in ecology, energy and the environment. Bonsai, gardening, bikes and music when I'm not at a keyboard.
I've spent a lot of last year putting up some (simple) data science services on was lambda in both python and r. These services interface with our monolithic laravel PHP product.
I've been planning on writing up my experience more fully in a post. I've started a while back, but never got it to a publishable state. I'll try and get it done by the end of the month.
Generally, my experience was positive, and though I got both python and R services up in production, getting the R service up was a lot more of a faff. A key issue was database connection. For some still mysterious reason, it still doesn't work, so we send the data in the body of the API. It's good enough for now at least. Bakdata make a lovely R layer for Aws lambda that was key to the solution.
What do you mean by double billing? It's a term I haven't heard before.
Curious about what
Hey Dave!
So double billing would generally refer a vendor charging the customer for the same product twice. In the case of FaaS vendor’s double billing refers to the synchronous invocation of other functions. When a function makes a call to another service, you pay for the waiting time — even if the code is using async I/O. This means you wait for the result of each function called, and hence must pay for the wait time. This wait time is directly correlated to section.
So in all. this additional billing violates one of the serverless principles: pay for what you use, not idle time!
Without intrinsic support from the FaaS vendor, it is impossible to avoid double billing while still maintaining the core principle of the serverless computing model.
Got it. Cheers :)