Re:Going Serverless: AWS and Compelling Science Fiction
by mdergosits on Friday November 11, 2016 @04:52PM
(#12934804)
Wouldn't loop detection be equivalent to solving the halting problem? Obviously a naive approach would be disallow recursion/ mutual recursion, but there are valid use cases for those that may not result in infinite execution
Re:Going Serverless: AWS and Compelling Science Fiction
by harlanji on Friday November 11, 2016 @05:30PM
(#12935091)
I helped design a large scale JS execution engine. We used Babel to rewrite code with loops that could be interrupted by our system. Eg. `for(...){mycode();}` would be recompiled to `for(...){if(!running()){halt();}mycode();}`. The technical reason is that tight loops wouldn't respond to SIGINT, if I recall correctly. So while it doesn't stop infinite loops, it can control the program. I wasn't involved in productionizing it.
Re:Going Serverless: AWS and Compelling Science Fiction
by duaneb on Friday November 11, 2016 @08:31PM
(#12936028)
Sorry--couldn't be interrupted by SIGINT? That's arguably the point of signals. Does the runtime just queue signals rather than respond in the signal handler itself?
Re:Going Serverless: AWS and Compelling Science Fiction
by dllthomas on Friday November 11, 2016 @06:40PM
(#12935491)
As I understand it, this is mutual recursion accross services, which is a much more specific case. Forbidding it may be viable.
Re:Going Serverless: AWS and Compelling Science Fiction
by marktangotango on Friday November 11, 2016 @03:04PM
(#12933833)
Ha, got the Sqlite case covered! Full disclosure lite-engine.com is my service, the idea here is SQL as a service, literally. The net result is basically MS Access backend for the web, with html/css/js for the frontend:
https://www.lite-engine.com/blog/api_queries.html
Edit: To the downvoters: self promotion is allowed on this site, and in fact encouraged!
Re:Going Serverless: AWS and Compelling Science Fiction
by ohstopitu on Friday November 11, 2016 @03:14PM
(#12933918)
Thanks for the reply!
1. Loop detection does seem harder to implement but I'll definitely look into it (if the api service is used, it would be trivial to implement)
2. but multi-datacenter has almost been implemented (you can select from different service providers, regions or a combinations of each - and the functions would scale accordingly).
As for a database/key store...would integrating with database solutions from other cloud providers be of some consideration? (from GC / AWS / Azure?).
Keep in mind that all users would have access to environment variables (across projects/functions etc.) by default.
2) Multi-datacenter -- I want to deploy to two places at least so my risk goes down
The lack of database and/or storage would be a big showstopper. It would mean that if I want build anything with state, I need to store it in another service, which costs money to move data out of. Even a very basic key store would better than nothing. You could actually build one pretty easily on top of Postgres or even SQLLite (although you'd need one per customer w/ SQLLite).