Live data from Hacker News

CNCF Serverless Whitepaper v1.0

github.com

1–10 of 18 posts

Re: CNCF Serverless Whitepaper v1.0

#2
I've worked on a PaaS and currently work on a FaaS. This whitepaper is thorough and quite fair. I have a few nitpicks by they're minor in comparison to the bulk of it.

Personally I think of FaaSes as having more in common with PaaSes than anything else, so I'm motivated to reuse existing technologies where possible.

Particularly, I expect the FaaS I work on (Project Riff) will eventually use buildpacks as the onramp. It helps that I work across the aisle from the Cloud Foundry Buildpacks team.

Kudos to the WG.

Re: CNCF Serverless Whitepaper v1.0

#3

I've worked on a PaaS and currently work on a FaaS. This whitepaper is thorough and quite fair. I have a few nitpicks by they're minor in comparison to the bulk of it. Personally I think of FaaSes as having more in common with PaaSes than anything else, so I'm motivated to reuse existing technologies where possible. Particularly, I expect the FaaS I work on (Project Riff) will eventually use buildpacks as the onramp.…

I agree with you 100%. It's the same old thing with barely any changes. There is truly nothing new under the sun and we keep reinventing the same things.

I like to think this industry is full of smart people, but it always makes me surprised how willing are we to drink the kool aid.

Guess being smart and having a herd mentality are not mutually exclusive. (Perhaps they are actually correlated? :P - Ie. my professor advised me to use the Linux Distro my friend uses, because then I get ask for help from someone.)

Re: CNCF Serverless Whitepaper v1.0

#4
I noticed this non-exhaustive list has left out StdLib [1], an all-in-one API development, provisioning, and FaaS platform with tens of thousands of developers. (Disclaimer: am founder :))

We don’t work directly with the CNCF because we’re a four person team; we don’t have the bandwidth to engage in committees. We innovate as best we can with our platform and deliver value directly to customers.

The reason you, as a developer and reader of Hacker News, should know about us is because we’re consensus building with some of your favorite companies and we’re the easiest way to manage your entire API: from development (we have a local dev story) to deployment, documentation, automatically generated SDKs for your customers, custom docs pages and more.

You’ll be learning a lot more in the coming weeks and we’re very excited to share what we’ve been building and the relationships we’ve secured as a platform.

If anybody from the CNCF would like to reach out, I’m keith@ (our domain). Same goes for any developers or curious Hacker News readers: my Inbox is open. :)

[1] https://stdlib.com/

Re: CNCF Serverless Whitepaper v1.0

#6

I noticed this non-exhaustive list has left out StdLib [1], an all-in-one API development, provisioning, and FaaS platform with tens of thousands of developers. (Disclaimer: am founder :)) We don’t work directly with the CNCF because we’re a four person team; we don’t have the bandwidth to engage in committees. We innovate as best we can with our platform and deliver value directly to customers. The reason you, as a…

CNCF member company employee here. The working groups I've paid close attention to are very collaborative and open, they even preface their slide decks with a strict antitrust notice. Redpoint has an investment in and obviously some level of interest in one of their portfolio company's FaaS offering. It's kind of surprising that you prefice your comment on being "left out" while mentioning the aid of Redpoint. Has the CNCF or one of its working groups not been receptive when you or a team member has looked to contribute? How does your "censensus building" differ from what they are doing?

In any case, this thread might be a good place to call out specific differences between StdLib and those other, more established CNCF members.

Re: CNCF Serverless Whitepaper v1.0

#7
post #5

Following predictable comment thread coming in, 1. Serverless is meaningless hype, we already have CGI. 2. There are servers so it shouldn't be called serverless.

Not really... if anything, this is the submission that tries to clarify those concerns.

-Someone who dislikes the name and the hype

Re: CNCF Serverless Whitepaper v1.0

#8
post #6

I noticed this non-exhaustive list has left out StdLib [1], an all-in-one API development, provisioning, and FaaS platform with tens of thousands of developers. (Disclaimer: am founder :)) We don’t work directly with the CNCF because we’re a four person team; we don’t have the bandwidth to engage in committees. We innovate as best we can with our platform and deliver value directly to customers. The reason you, as a…

CNCF member company employee here. The working groups I've paid close attention to are very collaborative and open, they even preface their slide decks with a strict antitrust notice. Redpoint has an investment in and obviously some level of interest in one of their portfolio company's FaaS offering. It's kind of surprising that you prefice your comment on being "left out" while mentioning the aid of Redpoint. Has th…

I don’t have any bones to pick with the CNCF: we’ve had opportunities to get connected and become involved, it’s just not in our best interests at this point to be super proactive. There’s so much surface area left to innovate upon and we have a finite amount of resources (we doubled our team size recently and will be doubling again shortly). You’re doing a fantastic job, and this whitepaper is great! I’d love to add in our $0.02 in the future, but that’s probably best done over e-mail: you can email me or I’m happy to reach out.

The differences in consensus building we’re doing are specifically around Serverless APIs and Serverless technology as a means to lower the barrier to entry into software development as a whole. There are some moving parts here that I’m not comfortable sharing publicly yet, but they’ll be announced likely by end of quarter.

Re: CNCF Serverless Whitepaper v1.0

#10

I've worked on a PaaS and currently work on a FaaS. This whitepaper is thorough and quite fair. I have a few nitpicks by they're minor in comparison to the bulk of it. Personally I think of FaaSes as having more in common with PaaSes than anything else, so I'm motivated to reuse existing technologies where possible. Particularly, I expect the FaaS I work on (Project Riff) will eventually use buildpacks as the onramp.…

I agree with you 100%. It's the same old thing with barely any changes. There is truly nothing new under the sun and we keep reinventing the same things. I like to think this industry is full of smart people, but it always makes me surprised how willing are we to drink the kool aid. Guess being smart and having a herd mentality are not mutually exclusive. (Perhaps they are actually correlated? :P - Ie. my professor a…

There isn't anything new, but it's also worth remembering Mark Twain's quip: history doesn't repeat itself, but sometimes, it rhymes.

FaaSes do add some twists on CGI. In CGI the short-livedness is the process, in a FaaS it's the container. A CGI program can get away with relying on local modifications to a file system in a shared environment. FaaSes somewhat point away from that.

There's also the speed of scaling. Insofar as FaaSes rely on lower layers to insulate the layer between process and machine, it becomes plausible to grab a number of machines relatively quickly. There's a cold start cost, to be sure, but the cold start on "launch this container" is probably better than "install this software and then launch it".

Post reply on HN