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.
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.)
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".
I don’t disagree that FaaS and CGI are wildly different but I’m not sure I understand your distinction between containers and processes. Containers are processes decorated with networking namespaces, control groups, and chroot.
The thing I'm driving at is that containers create much stronger isolation than shared hosting does.
Both are processes, but the administrative overhead is lower when you can contain the blast radius with namespaces and cgroups. The illusion of isolation is much more complete to the containerised process than for an uncontainerised one.
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. :)
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.
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.
Your product is not interesting to me if it doesn't integrate with Prometheus, a CNCF-backed project. It sounds like you could stand to swallow your pride and interact with the community more.
I’m certainly proud of what we’re building and the great team we’ve pulled together. We happily support our own community of tens of thousands and growing, in the past two months alone we’ve sponsored five student Hackathons and introduced thousands of young, excited minds and the future of software development to “serverless” workflows.
These developers have built everything from passive notifiers to help the elderly [0] to smart city garbage collection bins that integrate with City’s Slack teams to notify when bins need to be changed [1].
Our team is active 24 hours per day at these events and more, shipping releases to both paying customers and free tier developers into the wee hours of the morning. We’re very lucky to have a small but motivated team of the most competent engineers I’ve ever had the pleasure of working with and we’re humbled to be working with companies tens to hundreds of times our size that do hundreds of millions of dollars in revenue combined.
So, pride? Certainly. :) I just don’t think it’s the deadly-sin type you may be insinuating. It would be disingenuous to my team, our customers, and our Enterprise partners if I wasn’t proud of the work we’re doing (that’s not to say there’s not plenty of room for improvement! We’re constantly growing and responding to customer and developer needs.). However, we don’t have a single customer that has asked for (or even suggested) any sort of foundation membership at this point. We simply don’t have the resources to be part of a committee: we are already stretched thin with many boots on the ground doing work that, yes, we’re proud of. I’m not precluding it from the future, it’s just not on our roadmap right now.
Happy to understand how you think Prometheus may help us, though!
Just to be clear, membership in CNCF is not required to participate in any of our workgroups (including serverless [0]) or projects, such as Prometheus [1].
Thank you so much for this. I received your e-mail as well and it means a lot you’d go through the effort to reach out directly. The team is really appreciative. Will follow up shortly - in the midst of travel. :)
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.