> The serverless concept solves this problem, because it requires no DevOps to build and deploy applications at scale<p>This is wonderfully naive. A great goal, but hopelessly unrealistic. E.g. currently it is not handling data persistence at all, so for starters it's targeting "the easy bit", yet there's hardly any mention of things like logging, or what do to when their Consul cluster decides to start complaining because membership has gotten messed up (ever had a Consul node rejecting most messages as "suspect"? ever had the same node get registered twice? all kinds of fun stuff), how to analyse performance issues, networking problems etc.<p>It looks like an interesting platform, but anyone thinking this gets them out of understanding ops concerns will have tough times ahead..
Interesting bit from the FAQ:<p>"We rely heavily on Docker and Docker Swarm for containers, orchestration and networking. Other pieces of tech we use are Consul for service discovery and gRPC with Protobuf for the RPC."<p>Awesome that it's using gRPC under the hood. But, I'm still missing if there's an orchestration service running somewhere that takes care of the load balancing, or if it's distributed?<p>"When deploying Lever, you allocate a number of servers to it. Lever can then manage resources and auto-scale services running on it - but this is only limited to the servers you have allocated to it."<p>It would be awesome (and critical to our use case) if it could provision instances, even if it's via a shell command manually entered into a config file. From the stack description quoted above, it sounds like it would do okay if it was coupled with an autoscaling group that does this function for now...<p>Finally, I love the sticky resource routing, with the use case being data sharding.<p>Excited to try this out.
Isn't a core tenant of DevOps that your developers are the ones doing the Ops too? I keep hearing things like "Hiring DevOps" or "According to the Stack Overflow survey there is 1 DevOps for every 30 developers.", and that feels like... an Ops role, right?
This is really great initiative! Despite some fundamental critics and misconceptions, I'd like to say: Congrats, Vlad Alexandru!<p>In my humble opinion, this is not even close to "serverless", but rather "cross-platforms". The best description to current "serverless trend" that I've heard is that "infrastructure comes with no-ops and pre-scaled at massive scale, that only providers like Amazon's AWS, or Google's GCP, or Microsoft's Azure and alike can provide" ;)
So... this is backend infrastructure (i.e. it runs on a server) to let your team deploy "severless" apps...<p>So they're serverless. Except the server you're running it on. And the lamba/style code they wrote and uploaded to it.<p>But serverless, because no ops staff required. Except the ones who installed and maintain this.<p>This is like a snake eating its own tail and wondering what hurts.<p>Edit: despite my sarcasm, it's <i>always</i> good to see open-source solutions to reduce reliance (or risk of reliance) on closed vendor solutions. Just stop calling it serverless, and I'll stop telling you how fucking ridiculous that name is.
I was developing something similar with effe[1] e effe-tool[2], the idea is similar.<p>You wrote your service in go following in such a way that it expose 3 function and it get compiled down to a single binary, then you can dockerize your application (images usually are smaller than 6MB) and deploy it, wherever and whenever you want.<p>Of course everything is open source.<p>I explained it a little better here: <a href="http://redbeardlab.tech/2016/03/05/effe.html" rel="nofollow">http://redbeardlab.tech/2016/03/05/effe.html</a><p>[1]: <a href="https://github.com/siscia/effe" rel="nofollow">https://github.com/siscia/effe</a><p>[2]: <a href="https://github.com/siscia/effe-tool" rel="nofollow">https://github.com/siscia/effe-tool</a>
I don't know why HN is being so critical, because this sounds awesome and really useful! Similar to what I've been trying to do with databases ( <a href="http://gun.js.org" rel="nofollow">http://gun.js.org</a> ).<p>It is sad to see so much elitism in the tech world that is dismissive of anyone/anybody that knows less than them. This same attitude seems to come out a lot to dismiss really cool tools like this ( <a href="http://leveros.com" rel="nofollow">http://leveros.com</a> ) that help solve frustrations and problems. Could we try to be more encouraging of newcomers and of tools that automate (laziness is a programmer's virtue) those gaps?
It looks like Serverless? <a href="https://github.com/serverless/serverless" rel="nofollow">https://github.com/serverless/serverless</a>
A big part of the value of AWS Lambda is that it allows you to glue together other AWS services with custom application logic, similar to stored procedures in a database. Without the other AWS services and the event triggers they expose to Lambda, "serverless" is a lot less interesting.
So I know something like this (or AWS Lambda) is good for quickly putting up an endpoint and scaling it to theoretically unlimited nodes.<p>Could anybody shed some light on how this might be used in practice? It seems at the point that you have multiple endpoints, you may as well just deploy a full application.
This reminds me of Zappa [0], only Zappa actually runs on AWS Lambdas. Although they readily admit it takes a lot of hacks to get WSGI working within a Lambda function.<p>0: <a href="https://github.com/Miserlou/Zappa" rel="nofollow">https://github.com/Miserlou/Zappa</a>