7 ms·

Show HN: Serverless meets Microservices

191 points by vladaionescu 10y ago

fortytw2 10y 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-AL 10y 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 10y 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.
    - UK-AL 10y ago
      I didn't realise I was offensive, sorry. If operations is moving towards being automated by software it's only natural to want to move more towards programming side. I'm not saying this a bad thing, only natural. If infrastructure people see traditional server management moving towards automated deployments/monitoring/automated server setup. Then a lot of them would want to move into those skills, which a lot did. Is there anything wrong in wanting to cross-functional? Most DevOps people are developers who automate infrastructure, or Infrastructure people who move into programming so they can automate. You need to have both to be really good at it. That's what crossfunctional means. Btw I am actually devops, and I've been working on it for a few years.
    - toomuchtodo 10y ago
      > 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. Thanks, as an ops guy. I work hard every day to make the best tools available for our developers, and to ensure we have the highest levels of reliability.
      - UK-AL 10y ago
        What a myth here, whats garbage? If you look at the early history of devops, a lot of it was developers who had previous infrastructure experience and roles writing software for automating deployment, and sever creation. It sounds to be me you have chip on your shoulder, any mention of programmer help makes you angry? When in reality programmers appreciate modern DevOps people. What makes you thing programmers dislike you? You seem to assume I am a programmer?
        toomuchtodo 10y ago
        No chip on my shoulder, nor assumption you're a developer. You said: "Originally yes, it was about being more cross functional instead of separate silo's." Which strikes me as the continuation of requiring someone to be familiar with everything in the stack. So you get people who are mediocre at every skill they need, and not particularly good at any single task. Also, you said: "However operations people had an issue with that" Not in the slightest. As an ops person, I embrace the DevOps model. My problem is when someone like yourself makes a broad, unsubstantiated generalization such as this. Ops people want systems to run smoothly, and also want to have a life outside of work (I'm assuming? Perhaps another broad generalization). DevOps means I work with developers to ensure their code works as expected in production as it did in development and staging, and that they're not just throwing it over the fence to me and hoping for the best.
        UK-AL 10y ago
        I didn't mean issue with it in a bad way. Just that a lot operational people noticed it was trend occurring and adapted to it. They didn't avoid it. As a DevOps can you develop code to automate things, like deployment, builds, ci, server setup? Can you setup servers, networks, monitoring? If you can do all of these things your cross functional. Originally before devops, operational teams and developer teams were completely separate. Often separate rooms. At the company I'm at devops and developers are actually on the same team. Same room and attend the same stand up meetings. We have devops people that have helped create code, and we have developers that are on call for making sure that they are on duty in case their new code falls over. Skills gradually start to overlap. We also have people have switched their focus, developers who moved to more ops skills and vice versa. We aren't different groups of people. That' what I mean by not separate silos.
- nilved 10y 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.
- vidarh 10y 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 10y 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.
    - vidarh 10y ago
      Yeah, I keep getting clients come to me because of the complexity of their cloud setups, and they invariably end up paying far more than the guys running stuff on dedicated hosting. Most of them also pay 2x-3x as much for the hosting itself... I think a lot of these setups grow by accretion because people are able to push things onto them within purchasing mandates they have because of monthly fees that can slowly grow through discrete approvals rather than having to justify large capital expenditures upfront, or even seeking approval for contracts for monthly payments vs. running up per-minuter or per-hour or per-GB charges... I suspect a lot of the enthusiasm for these services would vanish if more engineering teams actually had to produce cost estimate, budgets and after-the fact accounting of operational costs for the stuff they build... I think as a startup, though, offering these kind of platforms as open source is ingenious, because you get mindshare, but people soon enough will run into enough pain to want to offload the pain on someone else - either hiring devops/ops people, contracting it out, or coming to your startup begging you to run it for them. Certainly, it's great for people like me who do consulting part time that people don't know how to do this, as it's far easier to justify my rate when I can ask to see their hosting costs and be able to point out to them that the monthly cost savings they'll get will cover the fees in 3-4 months.
- MattRogish 10y 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).
- stephenr 10y 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-AL 10y 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.
    - nickpsecurity 10y ago
      If library is done well, then you shouldn't have to know much about SSL to be able to use it. Just an abstract idea of it plus how to use the library. SSL from an ops perspective is quite different. That's why it's better to have pro's in each working together on it.
      - UK-AL 10y ago
- zer00eyz 10y 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-devops.html#CHg4UHoQS6FCg8oo.99"* http://rewrite.ca.com/us/articles/devops/a-short-history-of-... From: http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html 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.
- biot 10y 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.
toddnni 10y ago
Is this a community project or built by a startup? I didn't find the information.
- deleted 10y ago
  [deleted]
- piotrkubisa 10y 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-exp-company-name https://www.linkedin.com/vsearch/p?company=Lever+OS&trk=prof...
Thaxll 10y ago
It looks like Serverless? https://github.com/serverless/serverless https://github.com/serverless/serverless
- ewindisch 10y 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".
  - nickpsecurity 10y 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. :)
vidarh 10y 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..
- stephenr 10y 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).
  - fapjacks 10y 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.
  - vidarh 10y 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.
jackcosgrove 10y ago
Your documentation says you support Node and Go. Do you have plans to support any other technologies?
- vladaionescu 10y ago
  Absolutely, Python and Java are next. It's based on gRPC so adding new languages is relatively easy.
stephenr 10y 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.
- nickpsecurity 10y 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.
  - deleted 10y ago
    [deleted]
  - stephenr 10y 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.
    - nickpsecurity 10y ago
zbjornson 10y 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.
- vladaionescu 10y 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.
kolanos 10y 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 https://github.com/Miserlou/Zappa
siscia 10y 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 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
marknadal 10y 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 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?
- deleted 10y ago
  [deleted]
eistrati 10y 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" ;)
skrowl 10y ago
I'm not sure I fully understand. Can you compare this to AWS Lambda?
biznickman 10y ago
So how is this better than Lambda or Iron.io Push Queues?
danielrhodes 10y 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.
csears 10y 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.
- deleted 10y ago
  [deleted]

191 points by vladaionescu 10y 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-AL 10y 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 10y 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.
  - UK-AL 10y ago
    I didn't realise I was offensive, sorry. If operations is moving towards being automated by software it's only natural to want to move more towards programming side. I'm not saying this a bad thing, only natural. If infrastructure people see traditional server management moving towards automated deployments/monitoring/automated server setup. Then a lot of them would want to move into those skills, which a lot did. Is there anything wrong in wanting to cross-functional? Most DevOps people are developers who automate infrastructure, or Infrastructure people who move into programming so they can automate. You need to have both to be really good at it. That's what crossfunctional means. Btw I am actually devops, and I've been working on it for a few years.
  - toomuchtodo 10y ago
    > 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. Thanks, as an ops guy. I work hard every day to make the best tools available for our developers, and to ensure we have the highest levels of reliability.
    - UK-AL 10y ago
      What a myth here, whats garbage? If you look at the early history of devops, a lot of it was developers who had previous infrastructure experience and roles writing software for automating deployment, and sever creation. It sounds to be me you have chip on your shoulder, any mention of programmer help makes you angry? When in reality programmers appreciate modern DevOps people. What makes you thing programmers dislike you? You seem to assume I am a programmer?
      - toomuchtodo 10y ago
        No chip on my shoulder, nor assumption you're a developer. You said: "Originally yes, it was about being more cross functional instead of separate silo's." Which strikes me as the continuation of requiring someone to be familiar with everything in the stack. So you get people who are mediocre at every skill they need, and not particularly good at any single task. Also, you said: "However operations people had an issue with that" Not in the slightest. As an ops person, I embrace the DevOps model. My problem is when someone like yourself makes a broad, unsubstantiated generalization such as this. Ops people want systems to run smoothly, and also want to have a life outside of work (I'm assuming? Perhaps another broad generalization). DevOps means I work with developers to ensure their code works as expected in production as it did in development and staging, and that they're not just throwing it over the fence to me and hoping for the best.
        UK-AL 10y ago
        I didn't mean issue with it in a bad way. Just that a lot operational people noticed it was trend occurring and adapted to it. They didn't avoid it. As a DevOps can you develop code to automate things, like deployment, builds, ci, server setup? Can you setup servers, networks, monitoring? If you can do all of these things your cross functional. Originally before devops, operational teams and developer teams were completely separate. Often separate rooms. At the company I'm at devops and developers are actually on the same team. Same room and attend the same stand up meetings. We have devops people that have helped create code, and we have developers that are on call for making sure that they are on duty in case their new code falls over. Skills gradually start to overlap. We also have people have switched their focus, developers who moved to more ops skills and vice versa. We aren't different groups of people. That' what I mean by not separate silos.
nilved 10y 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.
vidarh 10y 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 10y 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.
  - vidarh 10y ago
    Yeah, I keep getting clients come to me because of the complexity of their cloud setups, and they invariably end up paying far more than the guys running stuff on dedicated hosting. Most of them also pay 2x-3x as much for the hosting itself... I think a lot of these setups grow by accretion because people are able to push things onto them within purchasing mandates they have because of monthly fees that can slowly grow through discrete approvals rather than having to justify large capital expenditures upfront, or even seeking approval for contracts for monthly payments vs. running up per-minuter or per-hour or per-GB charges... I suspect a lot of the enthusiasm for these services would vanish if more engineering teams actually had to produce cost estimate, budgets and after-the fact accounting of operational costs for the stuff they build... I think as a startup, though, offering these kind of platforms as open source is ingenious, because you get mindshare, but people soon enough will run into enough pain to want to offload the pain on someone else - either hiring devops/ops people, contracting it out, or coming to your startup begging you to run it for them. Certainly, it's great for people like me who do consulting part time that people don't know how to do this, as it's far easier to justify my rate when I can ask to see their hosting costs and be able to point out to them that the monthly cost savings they'll get will cover the fees in 3-4 months.
MattRogish 10y 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).
stephenr 10y 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-AL 10y 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.
  - nickpsecurity 10y ago
    If library is done well, then you shouldn't have to know much about SSL to be able to use it. Just an abstract idea of it plus how to use the library. SSL from an ops perspective is quite different. That's why it's better to have pro's in each working together on it.
    - UK-AL 10y ago
zer00eyz 10y 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-devops.html#CHg4UHoQS6FCg8oo.99"* http://rewrite.ca.com/us/articles/devops/a-short-history-of-... From: http://rewrite.ca.com/us/articles/devops/a-short-history-of-devops.html 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.
biot 10y 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.

toddnni 10y ago

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

deleted 10y ago
[deleted]
piotrkubisa 10y 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-exp-company-name https://www.linkedin.com/vsearch/p?company=Lever+OS&trk=prof...

Thaxll 10y ago

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

ewindisch 10y 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".
- nickpsecurity 10y 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. :)

vidarh 10y 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..

stephenr 10y 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).
- fapjacks 10y 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.
- vidarh 10y 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.

jackcosgrove 10y ago

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

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

stephenr 10y 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.

nickpsecurity 10y 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.
- deleted 10y ago
  [deleted]
- stephenr 10y 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.
  - nickpsecurity 10y ago

zbjornson 10y 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.

vladaionescu 10y 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.

kolanos 10y 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 https://github.com/Miserlou/Zappa

siscia 10y 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 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

marknadal 10y 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 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?

deleted 10y ago
[deleted]

eistrati 10y 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" ;)

skrowl 10y ago

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

biznickman 10y ago

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

danielrhodes 10y 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.

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

deleted 10y ago
[deleted]