Intriguing venture. I have some feedback, please forgive the terseness:
[1] Documentation: too dense, starts off with running a shell script, but it's not immediately clear it's a quickstart, or to set up a dev environment, or what's going on. At least have an intro, or a table of contents, or something.
[2] Speaking of documentation, I'm unclear where your product stands. Is it a 'build your own Lambda-as-a-Service provider', or some kind of meta-proxy-orchestrator that abstracts away from the actual LaaS provider? (if it's not the latter, why link to every commercial LaaS offering? Aren't they competitors?)
[3] Our Team: "coming soon". I sympathize with having a lot to do on a website, but I care about your credentials if I am to run some code. Or maybe I don't, since lots of projects are popular on github and you don't necessarily know all of their authors in detail. But if you don't have it yet, don't highlight it in your menu.
[4] Your github is barebones and links back to the aforementioned docs page. It's a bit like running in circles. Have a short readme on github, then you can link somewhere else!
[5] On the front page, all 'learn more' buttons go to the same place. But, why have these at all? (see, #2. maybe move these into a 'Why' page that explains your pitch and how LaaS is big and these are the big players that are also doing it)
[6] Edit: the slides are good and they help me understand what's going on.
After staring at it a long while, and clicking a bunch of things, I assume it -must- be a build your own Lambda-as-a-Service. Otherwise, the steps to spin up a load balancer and Docker images make no sense at all. But it certainly isn't clear.
I'm always intrigued by any new development in the "serverless" space, but this website seems pretty undercooked and at the moment it doesn't do a good job of explaining what the heck OpenLambda actually is.
After a lot of poking around I read through the linked slides and discovered that OpenLambda aims to let anyone run their own lambda engine - i.e. run AWS Lambda on your local machine. The goal seems to be to let anyone research and innovate on serverless architectures, instead of just waiting to see what Amazon, Google, or Microsoft release. It doesn't really seem to be intended for production use, more just R&D. It also seems to be a student/educational project (?)
Author of Zappa[0] here - glad to see more F/OSS implementations in this space - see also OpenWhisk and I think there was another (IronIO? MetalIO? Something like that?) - but I think an important piece that's missing is a F/OSS implementation of API Gateway! That's part of the reason the AWS is still the leader of the pack IMO.
Something I recently stumbled upon through a coding challenge was https://webtask.io/
Having used ApiGateway + AWSLambda + AWSCloudwatch, I found Webtask to be infinitey easier to use and deploy. The only downside of Webtask, for some users, is that it is all Javascript, where AWSLambda allows multiple languages.
Yeah. I had a similar idea of a system of distributed serverless computing. Much to the chagrin of certain users who badmouth, it has much more to do with distributing computation on any machine.
My idea was to run a cluster of Erlang nodes, connect them by Tor Hidden Services. Each machine would have 2 HSdirs, one for the unique name for that node, and a shared HSdir that will randomly talk/load balance via a DNS-like mechanism.
The backend storage substrate would be IPFS. A user would write their program and add it to IPFS. My cluster would have /ipfs and /ipns mounted, and could run erlang programs and functions directly from that.
That was my idea thus far. Obviously, choosing Erlang would be rather erudite and exclusive to a small subset of programmers... But its tools of distributed actors and much of the hard stuff done for you just seemed like a shoe-in.
On the contrary, neither of things are required. Most tellingly, Lambda itself was first released as an event-driven service; there was no endpoint to invoke in a client-server fashion.
Moreover, although function-as-a-service requires hardware to run on (duh), the need for server-grade compute infrastructure is obviated by the short execution times. You could run a FaaS-based offering on a massive array of smartphones.
So sure, if you build a FaaS platform you'll need a scheduler, but you won't need a server, not in the client-server sense and not in the hardware sense either.
So some marketing-oriented people will think that "serverless" is just a buzzword to mean you're not managing the OS & hardware, but there's actually a more positive reading of this term that undermines all the negativity.
Do you have a process listening on a port, that accepts connections and handles what is sent through them? If the answer is yes, you have a SERVER. That's the definition of a server.
If connection handler is short lived, well, so it is the case in a HTTP server. It's just a repackaged idea.
The wrapper to fit Lambda into a client-server synchronous-invocation world is API Gateway.
But Lambda was built as an event consumer e.g. listening to a SNS queue. If you look at the broader set of AWS services you have a full toolbox of event-driven pub/sub message/event-driven tools to play with: Lambda / Kinesis / S3 / DynamoDB / SNS / SQS / Cognito / IoT and more.
It's enough of an integration & compute lego kit to build complete distributed/asynchronous pub/sub applications. However the tools are kinda .. developmental, you'll be doing much of the wiring up yourself.
> The wrapper to fit Lambda into a client-server synchronous-invocation world is API Gateway.
So yes, there is a server indeed. Why call it "serverless" then ? because one part of the stack uses pubsub ? then call that part a worker queue because that's what it is.
Well, as you posted this after another post that addressed this criticism rather elegantly, I will repeat the relevant bit - " We're OK with 'wireless' access to Internet, although it's pretty clear that the packets will hit a wire at some point. Wireless means I'm not pulling a cord along with my phone. "
Non-technical people may assume no server infrastructure. From the developer perspective -this is accurate-; the actual hardware is handled by someone else, there is no concept of it that the developer has to work around.
I'm not sure why you'd think someone would believe no software would be needed; even when servers are involved, there is software located elsewhere, on a mobile phone or a web browser or similar. No one is going to say "Oh, serverless? Then I don't need my software development team any more!"
Like? The point of it is there are no servers to manage. That's the sell, that's the differentiator. Hence the name. But by all means, if you have a better term for it I'd love to hear it.
> The point of it is there are no servers to manage
If I deploy a PHP script on a shared host there is no server to manage either. My PHP script doesn't listen communications on a socket connection. It doesn't make it "serverless". At some point the stuff you deploy, on a server no matter what you think it is, needs to communicate with the outside world through a server. It is not "serverless".
Well thing is you ARE indirectly managing server resources. For example, you have to deal with "autoscaling" or else it can run out of control.
Why not say "fully-managed" or "serverside fully-managed"?
In serverless, everyone is a "client" and you run things client-side. Things like P2P file sharing in the browser is serverless. Things like AWS lambda obviously have a server.
There is no technology anywhere that is called "Wireless internet". There is wireless networking, which does exactly what the name implies, it transfers packets from point A to point B, without wires.
That it might be connected to wires at each end is irrelevant because that is a different technology.
"Serverless" is a misleading name - it inherently requires a server, as it's specifically a server-side technology (an event driven function runner).
So, after having read the PDF I eventually realized that this is not a tool to cross develop and deploy to the three lambda clouds, but to self host your lambdas on your servers.
It's interesting and I might use it but I suggest to make it very clear on the home page of the project. The way it's designed now tells more about AWS, ECS and Azure than about the project itself.
I already counted 5 smart people saying in "serverless" there are already "servers". You are very intelligent and reminding me those guys who repeatedly said "there is definitely a string over there dude" while we were watching David Copperfield's show together.
Apex is a framework used to help build and deploy applications on Lambda. This project appears to be a way to run your own Lambda service locally. There are other projects out there like OpenWhisk[1], Iron Worker[2], Gestalt[3], and Funktion[4].
And for all those who disagree with "Serverless", come to Serverlessconf London (london.serverlessconf.io) and we can debate it there. In fact, would love to see everyone there!
> And for all those who disagree with "Serverless", come to Serverlessconf London (london.serverlessconf.io) and we can debate it there. In fact, would love to see everyone there!
Nobody disagree with anything but the marketing. "Serveless" is just an inaccurate description of what is actually going on. There is a server otherwise how do you communicate with the outside world? You need an API gateway to your pubsub architecture. Thus calling it "serverless" is misleading. Look we all know, buzzwords and marketing are here to sell, but when marketing is misleading it actually hurts the whole profession, leading to bad choices.
I am sure people have said this but it's "serverless" from the perspective of the user (who is a developer in this case). The developer doesn't have to deal with servers/infrastructure so for them the system is serverless.
I guess it's like wireless... Something could be wireless from the perspective of the end user but there are still wires actually there.
I honestly think that serverless is a lot less ambiguous and misleading than something like "cloud" which is completely abstract.
> I guess it's like wireless... Something could be wireless from the perspective of the end user but there are still wires actually there.
It's a bad analogy. As a developer you are supposed to know they are wires somewhere. That's why all this marketing is dangerous. the obfuscation which makes everything sound like "voodoo and black magic".
> The developer doesn't have to deal with servers/infrastructure so for them the system is serverless.
Yes he does, he has to configure and manage the whole thing on Amazon dashboard. Sure he doesn't have to spin upcontainers, but autoscaling doesn't make something "serverless". And again, you need API gateway to communicate with the outside world. So there is still a server fronting the whole thing.
I think we might be thinking about Serverless slightly differently. To me serverless is not just AWS Lambda. It's a broader theme that encompasses Function-as-a-Service technologies like Lambda and Backend-as-a-Service technologies like Firebase & Auth0.
Combining FaaS, BaaS, and using certain techniques and patterns is what makes Serverless. As a developer I am plenty aware that there are servers - I don't feel that there is any voodoo or black magic. However, when someone says that they have a serverless system I immediately understand what they are trying to say. They are saying that they don't need to manage, provision, scale, and look after servers. Honestly, the world "serverless" is a lot less confusing than "cloud".
I am not sure what you mean by "there is still a server fronting the whole thing". You don't need to scale the API Gateway yourself (again it's a managed service). Same goes for Azure functions, Google Cloud Functions and OpenWhisk as they all have HTTP listeners built in.
> However, when someone says that they have a serverless system I immediately understand what they are trying to say.
Obviously we don't as I don't consider the expression "serverless" accurate in describing what is really happening. Call it what it really is : pubsub, calling it "serverless" is misleading marketing.
> You don't need to scale the API Gateway
You still need API Gateway to communicate with the outside world, here is your server, you know exactly what I mean. What you call "serverless" didn't invent autoscaling in PAAS.
It's interesting by the way that you keep using product names "Lambda", "API Gateway" which aren't concepts but Amazon products. That's marketing. It's like calling all social networks "Facebooks". "Serverless" is a marketing device to sell Amazon services, I think people get it by now.
> It's interesting by the way that you keep using product names "Lambda", "API Gateway" which aren't concepts but Amazon products. That's marketing. It's like calling all social networks "Facebooks". "Serverless" is a marketing device to sell Amazon services, I think people get it by now.
Amazon is a leader in this area right now but let's not use them. We can talk about Microsoft, IBM, or Google. They use "serverless" to describe their products. Google calls cloud functions a "serverless platform" and "serverless microservices" (https://cloud.google.com/functions/).
Azure functions talk about "processing events with serverless code" and so on. I only meant to use Amazon is an example because people are more familiar with their products.
Serverless is just a descriptor for these kinds of technologies and patterns.
Both serverless and cloud are words that essentially mean that you are running back-end stuff on someone else's computer. That's not necessarily a problem, but these words appear chosen for their hype value and lack of actual semantic meaning. They are also irksome and downright impractical when you want to get down to what it really is or does due to all the marketing fluff and misinterpretation surrounding them.
If you want to talk nuts and bolts about some cool technology or interesting concept; why not use an unambiguous term that means just that one thing — e.g., platform-as-a-service (PaaS), function-as-a-service (FaaS), or simply a hosted solution.
> I am sure people have said this but it's "serverless" from the perspective of the user (who is a developer in this case).
It's specifically not server-less. The developer is writing code that will be run on a server. They just don't control that server. That is literally no different than people who push regular Ruby/Python/PHP/NodeJS/Perl/etc apps to platforms platforms like Heroku, or like developers pushing CGI/PHP scripts to regular shared-hosting providers via FTP back in the day.
In all cases, the developer has very limited, if any control over the server, and just uploads their code to run.
> I guess it's like wireless... Something could be wireless from the perspective of the end user but there are still wires actually there.
No, it fucking isn't. "Wireless" describes a specific type of connectivity - either WiFi/Bluetooth style short-range local networking, or Cellular/WiMax style long-range "last mile" networking. For the specific connectivity that is described as "Wireless" THERE ARE NO FUCKING WIRES. It is very possible to operate a 100% wireless network - e.g. bluetooth device networking, or wifi LAN networking. You will only be able to connect to other devices on the same network, but internet access isn't what's being claimed, and it will be completely wireless.
In the single specific definition of the "serverless" architecture, there is very much a server (and more than likely several), and without that server, you have nothing.
> I honestly think that serverless is a lot less ambiguous and misleading than something like "cloud" which is completely abstract.
With terms like Cloud, the term has actual technical background. Network diagrams often include a "cloud" component, which literally signifies something you don't control, usually a WAN/internet connection. See for example, this diagram with reference to a local IPX network (the page it's from isn't in English but references 1996): http://soback.kornet.net/~silicon/network/Tunneling.files/im...
Yes, the term has been expanded upon but there is still a basis of the same concept in its use: something you just use, you don't manage/control.
"Serverless" is a technically incorrect and very misleading term. The term would be better applied to something like HTML/JS Single-Page Apps that use things like offline storage/etc to allow truly offline browser based apps.
That is literally no different than people who push regular Ruby/Python/PHP/NodeJS/Perl/etc apps to platforms platforms like Heroku
It is different. On Heroku, you have to think (a little) about server configuration, and (especially) about how many servers you need.
In the 'cloud', they're someone else's servers, but they're at least somewhat visible to you. In 'serverless', you don't see them and don't have to worry about them (one hopes).
We've all got these peeves; the one that gets me is 'isomorphic'. But language evolves one annoying incorrectness at a time, and it's tedious and off-topic to vent about this every single time it comes up. (I'm not saying that to you personally but in response to all these subthreads.)
Sure, but it's fundamentally wrong. The only upside is that it's catchy.
It's tiresome to point it out from time to time but if I go to a bar and each time I say Jeronimo and each time I get slapped and explained that they don't like it that there, after a while I'll stop and just ask for a beer like normal people do :)
Indeed there may not be. You do not require server-grade hardware to build a function-as-a-service platform. Moreover you do not need a client-server endpoint. If you do have either of those things, it's an implementation detail. Case in point, AWS Lambda was launched without one of them.
If you have a better suggestion for a catchy name for function-as-a-service, the world of tech marketing awaits you.
I don't mind this name. We're OK with 'wireless' access to Internet, although it's pretty clear that the packets will hit a wire at some point. Wireless means I'm not pulling a cord along with my phone. 'serverless' similarly means my code is not listening on a socket, although the request does come from some socket, of course
There is still a server, otherwise how do you call your functions from outside ? The most accurate description of "functions as service" is a simple pub sub architecture, some service listens to events, starts a container and execute some script/binary/whatever. In order to send events to the former service, you need a server anyway. Just because it's a different service doesn't make the stack "serverless". Whether it is on Amazon or Azure, you're still paying for the API gateway service. Here is your server.
We are at a point where some dubious marketing hurts development, because that marketing is completely inaccurate and misleading. Every single developer which engages into that misleading marketing should be called out publicly for his bullshit.
Your 'wireless' analogy is the most convincing explanation I've heard for the term yet. When I was struggling with accepting 'serverless' as a legitimate name for Function-calls-as-a-Service, I reminded myself that there's no server to SFTP or SSH into to muck about on its filesystem.
Wireless refers to the lack of cables _between_ my device and the router. "Serverless" things however are part of the same infrastructure that serve other web services. They are sitting on servers. Computers which has a CPU to execute the functions. We call them servers, therefore serverless is meaningless term.
[1] Documentation: too dense, starts off with running a shell script, but it's not immediately clear it's a quickstart, or to set up a dev environment, or what's going on. At least have an intro, or a table of contents, or something.
[2] Speaking of documentation, I'm unclear where your product stands. Is it a 'build your own Lambda-as-a-Service provider', or some kind of meta-proxy-orchestrator that abstracts away from the actual LaaS provider? (if it's not the latter, why link to every commercial LaaS offering? Aren't they competitors?)
[3] Our Team: "coming soon". I sympathize with having a lot to do on a website, but I care about your credentials if I am to run some code. Or maybe I don't, since lots of projects are popular on github and you don't necessarily know all of their authors in detail. But if you don't have it yet, don't highlight it in your menu.
[4] Your github is barebones and links back to the aforementioned docs page. It's a bit like running in circles. Have a short readme on github, then you can link somewhere else!
[5] On the front page, all 'learn more' buttons go to the same place. But, why have these at all? (see, #2. maybe move these into a 'Why' page that explains your pitch and how LaaS is big and these are the big players that are also doing it)
[6] Edit: the slides are good and they help me understand what's going on.