
Show HN: Serverless meets Microservices - vladaionescu
https://blog.leveros.com/introducing-lever-os-d10a857f210e
======
vidarh
> The serverless concept solves this problem, because it requires no DevOps to
> build and deploy applications at scale

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.

It looks like an interesting platform, but anyone thinking this gets them out
of understanding ops concerns will have tough times ahead..

~~~
stephenr
> anyone thinking this gets them out of understanding ops

I haven't looked at it specifically, but given how much the blurb focuses on
'you don't need ops, developers can do this, its all automatic and built-in'
(thankfully they don't use the term 'magic') makes me think that when said
devs inevitably _do_ need ops help to make it work, the required work for said
ops will be increased because they can't just say "well the problem is your
load balancer is doing X instead of Y because of config Z" \- its going to be
a shit fight of fighting against the 'automaticness'.

Maybe they want to be the new cPanel (the web hosting product, not the generic
nickname for a control panel).

~~~
vidarh
Hey, I look forward to the day I can charge high rates going in to fix
underlying problems for this stuff... So far, those of my clients doing cloud
setups typically end up spending 2x-3x as much for my services to sort out
their systems than those doing dedicated hosting, on top of usually spending
more on hosting as well...

There are certainly exceptions that are using cloud technology for the things
they are genuinely cost effective for (e.g extremely spiky traffic; bulk
processing; or to manage their own dedicated hardware), but the amount of
money that's blindly thrown out the window because the people authorising the
expenses don't know how to estimate the costs of these things is staggering.

------
zbjornson
Interesting bit from the FAQ:

"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."

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?

"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."

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...

Finally, I love the sticky resource routing, with the use case being data
sharding.

Excited to try this out.

~~~
vladaionescu
Thanks man. To answer your question about load balancing, it is made via the
'leveroshost' agent itself. Each contains a HTTP/2 proxy that routes and
loadbalances traffic as needed. Each RPC goes through 2 of these agents: one
on the node originating from and one on the node going to. The decision of
where to send the request next (load balanced / routed) is based on
information from Consul.

------
fortytw2
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?

~~~
stephenr
> Isn't a core tenant of DevOps that your developers are the ones doing the
> Ops too?

Im sure it means that to a lot of developers, and definitely some managers.

The developers see it as "no more ops telling me that I need to use a TLS
connection to the database because it's over a WAN", or "no more ops telling
me I can't use the 0.0.0.1-pre-pre-alpha version of <insert
runtime/framework/daemon> in production".

The managers particularly see it as "we don't need those pesky ops people, so
we've just saved ourselves $X per year". They don't tend to factor in the lack
of relevant skills by their remaining developers, which tends to result in
less efficiency (i.e. taking longer to do shit) and greatly increased risk.

And then the developer says "hey we'll just use AWS because thats what HN all
suggest and it's cheap" and you end up paying a heap of extra cash each month
because they just run 10 on-demand EC2 instances 24x7 and a host of assorted
services to deal with the lack of persistence on EC2 instances, when
previously you needed just two servers in failover setup, with capacity to
spare.

I've seen what happens when developers "do ops", as I was leaving a company.
When you're asked by someone "can you help, I'm trying to install this SSL
cert on a server (for a soon to be production system) but I don't really
understand how any of this SSL stuff works", there is just one realistic
response. Run. Then run some more, hide, change your email and don't answer
your phone. Because that shit is about to go down like the titanic.

~~~
mgkimsal
> And then the developer says "hey we'll just use AWS because thats what HN
> all suggest and it's cheap"

Never understood this, except from developers who've never actually had to pay
for anything out of their own pocket. AWS is nice, and has a place.

And I do hear it from people, a lot. It's cheap compared to buying your own
hardware and dedicated staff, yes. But for a lot of the standard webapp stuff
you might want to do starting out, it's not as cheap as just getting a
dedicated VPS someplace.

I've been independent/self-employed for a long time, and while I use various
AWS services (including EC2 for some projects), it's rarely ever cost which is
the driving factor when AWS is chosen. But it's because the $ is coming,
directly or indirectly, from me.

~~~
UK-AL
Running your own stuff becomes more expensive when you want monitoring, Load
Balancers, HA, VPN's into your corporate network and constant database
backups. And then making it really robust.

Hiring all the staff for that can be expensive.

Problem is there are lot of developers who think setting up a virtual machine
putting a db on it, and then a webserver on another without thinking about all
the other stuff that can go wrong.

~~~
mgkimsal
There's a balance to be had, and there's very likely different periods in a
business lifecycle where some environments make more sense than others.

There's a pretty big cost to learning how to manage and get value all the AWS
stuff, and in the early days of a project - especially true in the 'startup'
world - there are probably more areas where $ can be spent to create more
value.

I've seen far too many people spin up multiple AWS and tie themselves to
expensive AWS setups when a small linode or other VPS (managed or otherwise)
would have been more than adequate for the first year.

There's this weird view people that have it's either 100% AWS or hire full
time developers and buy a bunch of bare metal. There's a lot of middle ground
which can provide a good amount of value while giving you time to ramp up.

The fact that you're referencing tying VPNs to a corporate network means
you're already far more advanced than a lot of the smaller orgs I've run in to
tying themselves to AWS when far less expensive alternatives exist.

Again, saying this as someone who uses and likes Amazon stuff, just not
exclusively.

~~~
UK-AL
It can still be an issue. It would still be a disaster if in the first year,
the database got corrupt or hacked?

Lone developers might tempted just to setup database without setting up a
backup solution and HA. Amazon has that at click of a button.

For a developer/infrastructure guy probably 1/2/3 days if you know what your
doing. If you don't know what your doing for your specific brand of database,
you might not set it up right which is a big risk which only shows up once
it's failed. There's a reason DBA's can get paid a lot, because there's a lot
to know.

I think as a startup, you need to take all the shortcuts you can grab. Getting
it out, and time to market is very important. Focusing on price at first can
cost more than its worth.

It depends on if you want to pay more for having quick setup and having
amazons engineers looking after backups and HA or do you want to pay less,
spend more time doing it yourself and getting the skills to make sure its
setup correctly.

------
eistrati
This is really great initiative! Despite some fundamental critics and
misconceptions, I'd like to say: Congrats, Vlad Alexandru!

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" ;)

------
stephenr
So... this is backend infrastructure (i.e. it runs on a server) to let your
team deploy "severless" apps...

So they're serverless. Except the server you're running it on. And the
lamba/style code they wrote and uploaded to it.

But serverless, because no ops staff required. Except the ones who installed
and maintain this.

This is like a snake eating its own tail and wondering what hurts.

Edit: despite my sarcasm, it's _always_ 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.

~~~
nickpsecurity
Seriously. We got serverless being the most BS term I've heard in a while.
Then DevOps: a term I still don't understand as I've never seen a concrete
description of it, its advantages, and specific examples. We have
microservices that people either brag or warn about in HN articles.

Combine them to get... something! Um, something I'll avoid for now until the
Cloud of confusion clears up.

~~~
vladaionescu
Hey, at least I didn't use "cloud-native" or "12-factor app"! On a serious
note, though, yeah I can't say I'm keen on the terms. I've known DevOps since
it was called SRE 10 years ago, at Google. Just trying to use same terms other
people on HN seem to use.

~~~
nickpsecurity
Haha, I hear you. Yeah, cloud-native would've been worse I agree. What's SRE
mean? Site Reliability Engineering? Or is my guess way off?

Btw, I really enjoyed reading 12-factor app [1] compared to most since the
page was a clear description of obviously good practices and debatable
recommendations that were at least clear. It was also about apps with a list
of 12 things to consider. That fits the name. Page was over 70% specific
justifications and technical answers with almost no hype or zealotry. I was
impressed the cloud crowd was capable of that. Mainstream needs to do terms
and explanations that way more often. ;)

[1] [http://12factor.net/](http://12factor.net/)

------
toddnni
Is this a community project or built by a startup? I didn't find the
information.

~~~
piotrkubisa
From the LinkedIn we can find out the author has established the company
called "Lever OS" [1], so it looks like a startup product.

[1]:
[https://www.linkedin.com/vsearch/p?company=Lever+OS&trk=prof...](https://www.linkedin.com/vsearch/p?company=Lever+OS&trk=prof-
exp-company-name)

------
siscia
I was developing something similar with effe[1] e effe-tool[2], the idea is
similar.

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.

Of course everything is open source.

I explained it a little better here:
[http://redbeardlab.tech/2016/03/05/effe.html](http://redbeardlab.tech/2016/03/05/effe.html)

[1]: [https://github.com/siscia/effe](https://github.com/siscia/effe)

[2]: [https://github.com/siscia/effe-tool](https://github.com/siscia/effe-
tool)

------
jackcosgrove
Your documentation says you support Node and Go. Do you have plans to support
any other technologies?

~~~
vladaionescu
Absolutely, Python and Java are next. It's based on gRPC so adding new
languages is relatively easy.

------
marknadal
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 (
[http://gun.js.org](http://gun.js.org) ).

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 (
[http://leveros.com](http://leveros.com) ) 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?

------
Thaxll
It looks like Serverless?
[https://github.com/serverless/serverless](https://github.com/serverless/serverless)

~~~
ewindisch
LeverOS seems to be an open source implementation of a lambda service for
running event-driven, "serverless" applications, aka an implementation of the
idea that drives AWS Lambda, Google Cloud Functions, Azure Functions.

The Serverless Framework is one of several frameworks for writing serverless
applications. The name of this framework is unfortunate as "serverless" is a
generic term referring to event-driven applications, but has certainly
benefited from the confusion that its authors have caused.

Those less familiar with these products can look at this as "RPC as a
Service".

~~~
nickpsecurity
"term referring to event-driven applications" "Those less familiar with these
products can look at this as "RPC as a Service"."

BOOM! You use words connected to real-world IT practice and suddenly I know
what it does. They should try that. Appreciate it. :)

------
csears
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.

------
danielrhodes
So I know something like this (or AWS Lambda) is good for quickly putting up
an endpoint and scaling it to theoretically unlimited nodes.

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.

------
kolanos
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.

0: [https://github.com/Miserlou/Zappa](https://github.com/Miserlou/Zappa)

------
skrowl
I'm not sure I fully understand. Can you compare this to AWS Lambda?

------
biznickman
So how is this better than Lambda or Iron.io Push Queues?

