Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Apache OpenWhisk – A serverless, open-source cloud platform

openwhisk.apache.org

Post reply on HN
Print view View original

131–140 of 146 posts

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#131

Post by chris_wot »

mr_toad wrote: post #66
masukomi wrote: post #38

Can someone explain to me WHERE the servers exist for this "serverless" platform? Is this code i run on lamda and lamda competitors? Is apache hosting it? Do i have to set up my own servers to run the code? All the intro docs and FAQs seem to assume that "serverless" is literally no servers, just magical cloud fairies or something. I get that it uses docker containers, but where can i / am i expected to run those?

I get the impression that Apache are running the servers themselves, but it’s not clear from skimming the documentation. Edit: I could be wrong, looks like there is an OpenWhisk offering from IBM: https://console.bluemix.net/openwhisk/

The main page is incredibly ambiguous and confusing. Full of market speak and totally unclear.

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#132

Post by bontoJR »

I am somewhat confused about this product. I think the Function as a Service approach has really some good advantages on more classic approaches sometimes, but if I want to go that path, what is the advantage to actually use an open source product and maintain the server with all the maintenance required (security updates, platform updates, handling scale, etc...)?

Wouldn't be an out of the box solution provided by AWL Lambda, Google Cloud Functions, etc... a better and more straightforward option on this space?

I am just wondering if I am the only one with this opinion, what is your experience on this topic?

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#133

Post by themihai »

bontoJR wrote: post #132

I am somewhat confused about this product. I think the Function as a Service approach has really some good advantages on more classic approaches sometimes, but if I want to go that path, what is the advantage to actually use an open source product and maintain the server with all the maintenance required (security updates, platform updates, handling scale, etc...)? Wouldn't be an out of the box solution provided by A…

Freedom to deploy anywhere is quite important to some people. One can truly appreciate it only after gets burned by one of these "cloud" provides(i.e. Google appengine/cloud).

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#134

Post by thomasj »

bontoJR wrote: post #132

I am somewhat confused about this product. I think the Function as a Service approach has really some good advantages on more classic approaches sometimes, but if I want to go that path, what is the advantage to actually use an open source product and maintain the server with all the maintenance required (security updates, platform updates, handling scale, etc...)? Wouldn't be an out of the box solution provided by A…

IBM offers that open-source platform as a managed service, IBM Cloud Functions (https://console.bluemix.net/openwhisk/).

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#135

Post by sm64 »

amelius wrote: post #5

Since it's serverless, I assume it runs on the client. How does it scale then? And is the client really the right place to run these functions, in view of performance, and perhaps battery use?

I'm curious to know whether what your describe actually exists.

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#136

Post by CodeM0nkey »

polskibus wrote: post #122
CodeM0nkey wrote: post #91

Earlier quoted context omitted.

> Even better if it is open source, in contrast to GOOG/AMZN/MSFT offerings! Most of the Azure Functions codebase is actually open source under the MIT License: https://github.com/Azure/Azure-Functions

That's great but it would be good to know what's missing? Can I take that repo, deploy it and start selling FaaS?

I don't know the answer to that myself unfortunately. I know the entirety of the runtime itself is OSS and when you do local run/debug of a Function it's the same runtime that Azure uses.

It's not an apples to apples comparison though since OpenWhisk is intended to be self deployed.

I mentioned Functions here just because many folks don't know that most Azure SDKs, runtimes, tooling, etc are OSS by default.

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#137

Post by dingaling »

oh-kumudo wrote: post #129
cocktailpeanuts wrote: post #64

Nowadays when someone claims to be "serverless", there can be two interpretations: 1. It's a server actually. It's just that the server serves up functions, without state. So a more correct terminology would be "stateless servers" 2. Truly P2P (Like blockchain), therefore there truly are no "servers". Used to think Amazon did a great job coming up with the jargon that's great for marketing, but lately as we see more…

Serverless means you don't have to explicit manage hosts yourself. They are transparent to you. In that case Lambda is no different from blockchain, where you have either AWS/server farm to run the actual code for you. Which in term, makes this project weird. Because in order to use it, you still needs to hosts a group of servers yourself. If someones else hosts it for you, you don't really care what framework they a…

> Serverless means you don't have to explicit manage hosts yourself

So they say but it still sounds daft.

I have a ticket to fly from London to NYC but all I have to do is turn-up and sit in a seat, someone else manages the imfrastructure. Aeroplaneless architecture!

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#138

Post by tinymollusk »

bri3d wrote: post #113
tinymollusk wrote: post #99

Earlier quoted context omitted.

I remember CGI; curious if you're able to elaborate how you see the analogy.

Pure CGI applications (before the mod_x / long-running workers strategy took over) are "stateless" / "function as a service" insofar as the application's internal state can only live for one request lifecycle. However, they generally ran with the external state (ex. local filesystem) preserved between requests, so the approach was still often a bit different than it is for modern FaaS applications, where state can on…

Is something like mod_php what you'd consider a CGI application? I always think of CGIs from before the day when webservers made it easy to integrate a runtime. For me, CGIs were usually binary executables that the webserver handed data to. I always thought it was about the data exchange, instead of about application state, because http requests are by default generically stateless.

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#139

Post by polskibus »

CodeM0nkey wrote: post #136
polskibus wrote: post #122

Earlier quoted context omitted.

That's great but it would be good to know what's missing? Can I take that repo, deploy it and start selling FaaS?

I don't know the answer to that myself unfortunately. I know the entirety of the runtime itself is OSS and when you do local run/debug of a Function it's the same runtime that Azure uses. It's not an apples to apples comparison though since OpenWhisk is intended to be self deployed. I mentioned Functions here just because many folks don't know that most Azure SDKs, runtimes, tooling, etc are OSS by default.

That's the problem though. It doesn't matter much that it's open source if it is not usable in a sense that you can't easily deploy it yourself or repurpose, without committing (and paying) for the rest of Azure stack.

Re: Apache OpenWhisk – A serverless, open-source cloud platform

#140

Post by BraveNewCurency »

ausjke wrote: post #95

so, serverless is (fastcgi + container) these days? at least fastcgi website is down for long time, and seems abandoned already along with cgi.

Yes, FastCGI would work, as long as you don't mind wasting money.

But what happens when you have billions of scripts, each executed infrequently? You need some way of fetching the scripts dynamically (they are changing constantly), and way to time-multiplex their execution so you don't waste RAM on inactive scripts. Oh, and load-balancing suddenly becomes non-trivial because you prefer to route to one script spun up on one box (as long as the usage doesn't justify multiple boxes), instead of accidentally spinning up that script on every box.

What's new is the layer that is managing fetching, starting, and stopping the scripts. For developers, it's 'kinda the same'. But for operators, it's a massive change in how things work that enables a different paradigm.

Post reply on HN