Comment by ohstopitu | Hacker News Reader

Comment by ohstopitu | Hacker News Reader

Let's talk about serverless/lambda/FaaS for a minute:

I'm currently working on a side project (which if successful can easily be a product in itself) to create a service that would be the Digital Ocean of FaaS (lots of talk - I understand).

What would be the core features that devs/users/managers are looking for? (something you downright expect for v1 that would compel you to put the service to use for development/production)

Currently some of the items top of my list (in no particular order) are:

* API development (like AWS's APIG)

* Support for more languages by default

* Ability for users to a custom defined language easily

* Creation of an opinionated framework / workflow for FaaS development (you don't need to do this if you don't want to...but FaaS first apps would be done better/easier this way)

* Rewriting common products (Wordpress, Ghost, Jekyll etc.) for to be served via FaaS.

Things I don't want to work on (or would prefer to not jump into):

* Storage service (S3 alternatives)

* Databases (there are so many out there...building a cloud is hard, building a database is even more so)

Who do I feel would pay for this?

* Front end & Mobile devs who don't want to complicate a backend

* Mobile devs who don't want to complicate a backend

* Enterprises maybe?

1) Loop detection -- don't let me shoot myself in the foot an make an infinite loop of two functions calling each other

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).

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!

https://news.ycombinator.com/item?id=12559012

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.

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

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.

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?

As I understand it, this is mutual recursion accross services, which is a much more specific case. Forbidding it may be viable.

If you're using lambda you have access to dynamodb, which is reasonably priced (and runs on a similar "pay what you use" and very generous free plan).

The real value people see with AWS Lambda is having the ability to easily glue together their AWS services which they run, one of which is an API, a lot of which is stateful services. Requiring users to write the interfaces between their stateful services and stateless functions via APIs may be more effort than what your target audience would want to deal with, there may be clever ways to make this almost as easy as mouse clicks as it is in AWS Lambda while also allowing the flexibly to be using something other than AWS.

I would also like to have something I could point at a docker api which would manage the end to end lifecycle of a function. Building it into a container, exposing itself over an API for management, telling it when it should run and of course running it on my docker machine(s). This idea I don't imagine is appealing to your audience however.

I will try my best to integrate AWS/GC/Azure as much as possible to reduce that issue in the first place (obviously I can't create alternatives to all AWS services for example, but I can integrate as much as possible via their SDK to reduce the friction users would face as you mentioned).

> I would also like to have something I could point at a docker api which would manage the end to end lifecycle of a function. Building it into a container, exposing itself over an API for management, telling it when it should run and of course running it on my docker machine(s).

Could you please go into a bit more detail? I don't understand what you are trying to do. (or it's use case)

The use case is the same, I want to run functions based on events from a variety of sources (API/DB/Storage). I just want to in particular run it on whatever hardware that I have which exposes a docker api, whether it be a computer in my room or in datacenter or cloud service. Most people do not care about having that flexibility, if someone is using software as a service usually they have already decided on using other cloud services as well and those who like to self host probably don't like the idea of having a service which has control over their machines.

I am actually building this on top of Docker, so technically that's already implemented (I'm actually testing this locally).

However...it does have some current caveats (can only run on a single machine, and definitely not something you'd want to run in production).

But it's (with more features obviously) something I've considered for v1 as an enterprise/maybe OSS feature (as most enterprises would love to host it themselves/behind their firewall/on their private cloud)

Reply on news.ycombinator.com