Hacker News Reader

Comment by sytse | Hacker News Reader

The trend is to have applications use less memory. On bare metal an application used all memory, a virtual machine has the OS overhead per application, on a container an application uses just one process, and with serverless even the processes can be reused.

If I understand correctly AppEngin uses containers that do not re-use processes, so not serverless according to the above classification.

I wonder why AppEngine didn't take off, the best answer I heard was that the security sandbox was too small and people wanted more flexibility. What do people think?

BTW As for Functions-as-a-service (FaaS) we're thinking about running the Lambda code (which is open source) on Kubernetes https://gitlab.com/gitlab-org/gitlab-ce/issues/43959#note_74... how hard would that be?

View on HN

- App devs were not ready for GAE's model. - Google was distracted by social & mobile, and is investing in YouTube as well. - Google apparently was not convinced that Cloud is the next big thing. - Many other things ...

This is why company like IBM can live, because tech is only a part of a large number of factors to build a successful business.

Thanks for sharing your perspective. I wonder if App developers where not ready since they did embrace Heroku.

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

2M annual revenue...

Note that AWS Lambda under the hood runs containers. I don't believe any serverless implementation is reusing processes.

Please review the serverless frameworks that already run well on top of Kubernetes: s.cncf.io (and see the installable platforms section at the bottom).

I'm happy to connect you with the Kubeless, OpenFaaS, and Fission folks, who would all love to see an implementation in GitLab.

Thanks for commenting Dan!

Interesting that AWS Lambda is also running containers instead of reusing processes. Their pricing suggests that Lambda is more efficient then containers, but maybe they priced it while anticipating being able to re-use processes later on.

We're already talking to the great people of Kubeless and OpenFaaS. Implementing either of them (or both) would be less work for us then getting Lambda to work on Kubernetes. But all the production usage and real world examples on the internet seem to be around Lambda so that gives us pause.

Since we're not trying to monetize a serverless framework we might be the only ones that can afford to make Lambda work on Kubernetes.

In the end we want to make something people want. And for me it is hard to judge what that is at the moment.

> The trend is to have applications use less memory. On bare metal an application used all memory, a virtual machine has the OS overhead per application, on a container an application uses just one process, and with serverless even the processes can be reused.

Processes on App Engine are reused between requests. We cache some things in instance memory.

I think what I meant to say is the processes are reused for different applications. I assume that on AppEngine one process is used only for one application (like our application servers on GitLab.com).

Ahh! Yes, each App Engine app lives in its own container & process. App Engine Standard further sandboxes things (you can't use arbitrary C modules from your Python code, for example).

I tried to use GAE back in the day, and it suffered from cold-start issues. Same story as if you tried to develop lambda-backed website with Java on AWS, and your lambda may take 20 seconds to start from cold.

Interesting. Heroku had cold start issues when you were on the free tier and didn't have any questions for a couple of minutes. Did GAE work the same?

Yes, exactly. They would shut down your container (or whatever it was).

Makes sense. With Heroku I used to run a monitoring service that made a request every minute to prevent this.

Yeah, other languages (Go, Python, Node) can cold start much more quickly.

Lambda also has very long (15+ second) cold start times if you start lambda functions attached to a VPC (such as lambda functions that connect to your MySQL server).

If you want to self-host FaaS, there's OpenWhisk. The problem that I have seen with the whole concept of self-hosted FaaS though is that you lose some of the key benefits of "serverless": no maintenance of underlying systems and pay for exactly what you use. Self-hosted means you have to maintain the underlying systems and you have to pay to keep those servers running 24/7 with sufficient scale to support your usage model. It may make deployment easier once you adapt to it, but it's not really giving you the full benefit.

So far everyone I meet that uses it production is using Lambda. It might be because they want to consume it as a SaaS. But maybe a self-managed solution would have to be compatible with Lambda to gain adoption.

Of course self-hosted is more work then SaaS, but I'm not sure that maintenance and scale are much worse. With Kubernetes you can autoscale things easily.

What would the goal of self-hosting a FaaS solution be?

On-premise deployment might be one goal.

Indeed! That's a good one.

> pay for exactly what you use

Is that a pragmatic consideration, though, or just a conceptual one?

My main concern is with the word "exactly", since cloud providers can charge a remarkable markup, which means that, though one is paying proportional to ones use, but that's not necessarily desirable, if the alternative is, for example, to pay less-than-proportionally (e.g. via an economy of scale).

Is the FaaS markup significantly lower? Higher? Do the decision makers even care?

I'm somewhat familiar with the possibility of reducing costs at IaaS providers like AWS with things like dedicated instances and the marketplace. Is that available with FaaS? Does that not matter because it, essentially, removes the benefit of minimal support?

I sometimes think people are overly keen to look for a Reason why something did or didn't take off, when attributing it to the whims of fate would be closer to the mark.

Reply on news.ycombinator.com