Show HN: Serverless meets Microservices

https://blog.leveros.com/introducing-lever-os-d10a857f210e

by vladaionescu • 10 years ago

191 61 10 years ago

blog.leveros.com

fortytw2• 10 years ago

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?

UK-AL9• 10 years ago

Originally yes, it was about being more cross functional instead of separate silo's.

However operations people had an issue with that(not in a bad way, just observing where stuff is going), and decided to obtain devops skills. So you ended up with pure devops people.

A lot the first devops people were developers, who also knew about infrastructure issues and been in those roles. They were fairly rare.

meandor• 10 years ago

No. Originally it was about operations and developers collaborating more closely, including cultural change (devs don't throw things over the wall to ops, ops doesn't hide prod from devs), increasing automation (applying development methodologies to operations), improving learning between the ops and dev teams, and such.

These days it's sometimes used:

- to mean traditional ops

- to mean that devs do all of their own ops

- to mean that there's a separate silo between the dev and ops silos that make tools

- to mean the original thing about collaboration and a shift on the ops side to be more programmatic.

Your explanation is a complete and total myth, though. It's just some garbage from a programmer who didn't know what it meant and decided to be a huge jerk about it.

nilved• 10 years ago

I don't think the term is well-defined. At first, it was about liaising between developers and operations. These days it seems to be about infrastructure-as-code like Chef.

vidarh4• 10 years ago

The day I see most developers doing ops well will be the days pigs fly.

My background is development, yet I've always done ops too, but what I see from most developers is that exceedingly few of them even know the extent of what taking responsibility for ops includes.

E.g. I strongly believe that one of the drivers for a lot of the extremely costly cloud solutions people use is that most developers these days have an acute lack of knowledge of hardware. But to do the ops side right you need to be able to choose cost effective solutions and you need to understand the trade-offs, or you may easily end up costing your business 10x as much in hosting for no good reason.

Thinks like capacity planning, risk management related to the hosting, backup strategies, failover/ha are areas very few developers have much experience with.

I spend a lot of the time I do consulting on mentoring development teams and/or providing advice in those areas, and most places are _very_ far away from having integrated teams that can safely and cost-effectively handle the ops side.

xorcist• 10 years ago

exceedingly few of them even know the extent of what taking responsibility for ops includes

When you don't know the extent of your ignorance, everything seems trivial. A.k.a. "how hard could it be?".

I have a feeling the more ops-y things I do gets more in demand as organizations move towards the cloud. Measuring performance is not trivial in a shared environment and failure scenarios can get very complex. And every development decision suddenly affects the bottom line when billing gets granular.

MattRogish• 10 years ago

DevOps is one of those terms, kind of like Agile or XP, that means different things to different people. To me, DevOps means Developers and Operations working more closely together, and walking a mile in each other’s shoes (you’ll hear the word empathy thrown around a lot). Developers should support their applications in production (including pager rotation!) and architect, design, and build applications with infrastructure supportability in mind, and Operations needs to engineer infrastructure using better development techniques: test driven development, automation, and with developer ergonomics in mind (providing a standardized, scalable platform and not just isolated snowflake systems).

stephenr5• 10 years ago

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.

UK-AL9• 10 years ago

But web developers should know how SSL works anyway. Otherwise your probably not a great developer.

I defiantly learned about SSL, and pki infrastructure through developer knowledge.

mgkimsal2• 10 years ago

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.

nickpsecurity8• 10 years ago

"when previously you needed just two servers in failover setup, with capacity to spare."

I don't know if you were there but I said the same shit to people here on HN in a hosting discussion. Some company had downtime on AWS and/or a bunch of servers. I said something along lines of how hard can it be to buy four servers at $1-2k each, set them up as HA pairs of pairs, send two to a colo, and manage that? And optionally send another pair to a third, geographical area if one wants more uptime? It's not that hard given we've been doing it since friggin' VMS clusters on refrigerator-sized VAXen. Just dirt cheap now for basic solution. OSS tools are even good enough for homebrewing it with little risk now.

Nah, though, let's pay for a bunch of VM's we have to manage anyway that we don't even control on sites with less uptime. (rolls eyes)

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

LOL. That's great. Someone with a meme generator needs to make an image out of this: "DevOps: Replaces Admins, Can't Deploy SSL." I can imagine quite a few more in capacity and disaster planning. Now what image would go with that...?

siddhant• 10 years ago

To me this sounds like the developers weren't tested for ops skills before being brought on to a team while everyone knew that developers are required to do ops.

Of course, specialisation helps. But the most pleasant work experience I've had was at companies where there was no distinction between dev and ops.

zer00eyz• 10 years ago

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

This isn't how it started.

"deliver a seminal talk known as “10+ Deploys per Day: Dev and Ops Cooperation at Flickr.” The talk is an energetic presentation in which Allspaw and Hammond basically act out the classic “fingerpointy” conundrum of Dev versus Ops—“It’s not my code, it’s your machines!” (and vice versa)—to a roomful of developers. They make the case that the only sensible way to build, test and deploy workable new software is to make development and operations transparent and integrated. Read more at http://rewrite.ca.com/us/articles/devops/a-short-history-of-...

From: http://rewrite.ca.com/us/articles/devops/a-short-history-of-...

Honestly if you go back to the early 2000's Operations and Engineering were often playing the blame game if not at outright war. I can't tell you how many SA's told me to "file a ticket" when asking for basic factual information (not changes).

The idea of a "full stack" engineer is mostly a myth. If your starting out small hiring a generalist who can do it "all" is probably a good thing. The issue is finding folks who can do everything well is HARD. Once you hit a certain scale, you need people dedicated to each JOB (Front end, back end, operations, database, networking). When you get to the level of having a lot of specialists, having someone do "DevOps" to act as a bridge, to speak able to speak to specialists and convey issues can be vital.

Reply

biot• 10 years ago

To avoid confusion, I assume you mean "tenet" as in principle, not "tenant" as in "occupying someone else's property", which could get confusing when talking about containers, cloud computing, and using some provider's resources.

Reply

toddnni• 10 years ago

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

Reply

piotrkubisa• 10 years ago

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

Reply

Thaxll• 10 years ago

It looks like Serverless? https://github.com/serverless/serverless

Reply

ewindisch• 10 years ago

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

Reply

nickpsecurity8• 10 years ago

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

Reply

vidarh4• 10 years ago

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

Reply

stephenr5• 10 years ago

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

Reply

fapjacks• 10 years ago

Well, yeah. The whole idea that you can somehow "save" on ops by doing X is just accruing technical debt, moving the point at which you will need ops into the future and also thus making it far more expensive when that time comes. It will be a fire that maybe only expensive outside (ops) consultants can put out. Imagine that: A fire that no one at the startup can put out. That's a lottery I don't want to play. If that doesn't scare people out of this kind of "we don't need ops anymore!" hooey, I feel like they deserve whatever comes their way down the line.

Reply

vidarh4• 10 years ago

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.

Reply

jackcosgrove• 10 years ago

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

Reply

vladaionescu3• 10 years ago

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

Reply

stephenr5• 10 years ago

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.

Reply

nickpsecurity8• 10 years ago

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.

Reply

stephenr5• 10 years ago

"Serverless" is wrong in a very technical way - they have a very distinct meaning in their head, but they're just choosing to wilfully ignore a huge part of the stack so they can call it that.

DevOps has as many different definitions as practitioners, and few will completely agree on the same definition.

Cloud is one of the worst frankly, because it is so hand-wavy and it's made it into every day language. My assumption is that this name came from the 'cloud' icon used in a lot of technical diagrams to represent something outside of your control and outside of your scope for the current project. I guess in some ways that makes "Cloud" the perfect term to describe things like AWS/et-al: something that is out of your control.

Reply

vladaionescu3• 10 years ago

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.

Reply

leoncrutchley• 10 years ago

ha I think serverless was just to get a reaction! I def agree that the devops has been neglected in terms of OS and hope this will help

Reply

nodesocket• 10 years ago

Agree this is not serverless, but still looks awesome. Just remove the serverless piece. I'd say this is a platform for running "lamba" on your own infrastructure.

Reply

illumin8• 10 years ago

This should be called what it is: a PaaS that automates some of your continuous delivery pipeline, specifically the deployment of your containers across a cluster of servers.

It's disingenuous and not likely to generate a lot of enthusiasm when you glom onto the flavor of the month (serverless) and try to recast a technology that pre-dates it (PaaS) as being serverless, when in fact its not.

Reply

zbjornson• 10 years ago

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.

Reply

vladaionescu3• 10 years ago

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.

Reply

kolanos• 10 years ago

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

Reply

siscia• 10 years ago

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

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

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

Reply

marknadal• 10 years ago

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

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

Reply

eistrati• 10 years ago

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

Reply

skrowl• 10 years ago

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

Reply

biznickman• 10 years ago

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

Reply

danielrhodes• 10 years ago

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.

Reply

csears• 10 years ago

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.

Reply

Show HN: Serverless meets Microservices

Related Stories