5 ms·

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 con

by sytse 8y ago

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_74835448 https://gitlab.com/gitlab-org/gitlab-ce/issues/43959#note_74... how hard would that be?

dankohn1 8y ago
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.
- sytse 8y ago
  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.
watt 8y ago
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.
- sytse 8y ago
  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?
  - watt 8y ago
    Yes, exactly. They would shut down your container (or whatever it was).
    - sytse 8y ago
      Makes sense. With Heroku I used to run a monitoring service that made a request every minute to prevent this.
- dangoor 8y ago
  Yeah, other languages (Go, Python, Node) can cold start much more quickly.
- joecot 8y ago
  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).
contextfree 8y ago
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.
justicezyx 8y ago
- 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.
- sytse 8y ago
  Thanks for sharing your perspective. I wonder if App developers where not ready since they did embrace Heroku.
  - justicezyx 8y ago
    https://news.ycombinator.com/item?id=11028831 https://news.ycombinator.com/item?id=11028831 2M annual revenue...
azurelogic 8y ago
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.
- sytse 8y ago
  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.
  - dangoor 8y ago
    What would the goal of self-hosting a FaaS solution be?
    - sunnyP 8y ago
      On-premise deployment might be one goal.
      - dangoor 8y ago
        Indeed! That's a good one.
- mmt 8y ago
  > 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?
dangoor 8y ago
> 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.
- sytse 8y ago
  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).
  - dangoor 8y ago
    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).

by sytse 8y ago

dankohn1 8y ago

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.

sytse 8y ago
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.

watt 8y ago

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.

sytse 8y ago
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?
- watt 8y ago
  Yes, exactly. They would shut down your container (or whatever it was).
  - sytse 8y ago
    Makes sense. With Heroku I used to run a monitoring service that made a request every minute to prevent this.
dangoor 8y ago
Yeah, other languages (Go, Python, Node) can cold start much more quickly.
joecot 8y ago
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).

contextfree 8y ago

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.

justicezyx 8y ago

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

sytse 8y ago
Thanks for sharing your perspective. I wonder if App developers where not ready since they did embrace Heroku.
- justicezyx 8y ago
  https://news.ycombinator.com/item?id=11028831 https://news.ycombinator.com/item?id=11028831 2M annual revenue...

azurelogic 8y ago

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.

sytse 8y ago
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.
- dangoor 8y ago
  What would the goal of self-hosting a FaaS solution be?
  - sunnyP 8y ago
    On-premise deployment might be one goal.
    - dangoor 8y ago
      Indeed! That's a good one.
mmt 8y ago
> 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?

dangoor 8y ago

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

sytse 8y ago
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).
- dangoor 8y ago
  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).