20 ms·

Serverless Architectures

• themihai 10y ago
  The vendor lock-in alone is enough to make BaaS dead on arrival. Some seem to lock you not only on specific platform APIs but also on a single programming language(i.e. javascript) like it wasn't worse enough to have a single language on the client.
  • Mizza 10y ago
    I got burned by Parse on this already. One of the nice things about Zappa (https://github.com/Miserlou/Zappa https://github.com/Miserlou/Zappa) is that you can return to a non-serverless architecture if you want to.
  • mseebach 10y ago
    You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks.
    • nickpsecurity 10y ago
      You may be misunderstanding the concept of Lockin. It says you are stuck with whichever vendor you used that created the lockin. Benefits of services always seem to increase. So, whatever benefits exist for a current service isn't worth forgoing all potential benefits of all future competitors. That's what lock-in creates. That's why it's always bad for anything meant long-term. Now, short-term projects that can disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
      • themartorana 10y ago
        I still see this as flawed. Avoiding all vendor lock-in means making every possible piece of software you write completely generic - no GIS from Postgres, no third-party queue/messaging servers/services - none of it. We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of AWS have been huge for us, and anyone saying they're outweighed by the potential downside has no idea what they're on about. The right tool for the job is sometimes a vendor with specific services that, yes, sometimes have a lock-in component, even for long-term use. In this specific case this particular BaaS implementation may not be full-cooked enough to entice you onto it, but saying vendor lock-in is bad as a blanket statement or incontrovertible truth is just silly.
        • idunno246 10y ago
          we use dynamodb heavily, among other services, and the lockin question always comes up. and its like, would you rather get to market a month earlier, or spend a month building something just in case one day it doesn't work - it seems like a no-brainer that lockin is often a cost to push off to later especially considering you may never have to pay it.
          • themihai 10y ago
            The question is how much are you willing to trade-off for the managed infrastructure benefits. The database is a level but BaaS is a totally different level. Next would be the programming language. Would you feel comfortable to base your project on a proprietary amazon programming language? (i.e See Apex of SalesForce). Maybe yes but I can't see this becoming mainstream anytime soon. It would be a backward step. I use some managed/proprietary services too but I always consider it a liability/short term workaround. Most of the AWS services were successful because they are based on open source/3rd party software (i.e. the OS, DB engine etc). BaaS changes totally changes that. It's all proprietary except the programming language which may not be one of your preferred one either. Google lost a lot of ground on cloud service because it promoted a proprietary platform(GAE). The concept was great but we can see how it played out. These are the reasons why I think the current BaaS offers are dead on arrival.
            • krakensden 10y ago
              GAE is a great example of the lockin problem- they changed the pricing model, bills skyrocketed, and it was super hard to get out.
            • beat 10y ago
              But it's not on a proprietary Amazon language! The three most common/dominant languages in the back end app development world are already covered. Why are you inventing a problem that doesn't even exist to complain about? For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.
      • Spooky23 10y ago
        Lock-in is fine if it has value.
        • nickpsecurity 10y ago
          People keep saying that without a context. Non-lock-in usually has value too. Many times for similar or lower cost. And with way less risk. So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
          • Spooky23 10y ago
            Everything is situational. Nobody is going out and buying an IBM Mainframe because of my comment. I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
    • themihai 10y ago
      Well, the point is that the benefits don't outweigh the drawbacks because of the vendor lock-in. Whenever you hit a limitation there is NOTHING you can do. No duct tape! Also on long term the vendor roadmap may not align with your business(i.e. pricing, features etc). Do you have a migration roadmap? Of course you don't... you are already too busy dealing with the BaaS restrictions/APIs. Definitely BaaS have their place along with PaaS, DBaaS and IaaS but if you are locked-in to a specific vendor your options become quite limited very quickly. Maybe when something like Docker for BaaS appears I would reconsider this. The BaaS is not really more than a framework with various constrains so there is nothing stopping you to implement your own BaaS on top of an existing PaaS(to avoid managing servers). I'm actually doing just this and it works well but I can see how Lambda or any other vendor offer would not work due the amount of customisation required.
      • mseebach 10y ago
        For you. At the moment. "Dead on arrival" has a meaning, and this isn't it.
        • themihai 10y ago
          Well if I can't use it now due the constrains mentioned above it is dead to me. Would you bet your project on Google functions[0]? [0] https://cloud.google.com/functions/docs/ https://cloud.google.com/functions/docs/
          • scrollaway 10y ago
            That isn't what DoA means. "DoA" doesn't care for whether an individual can use it, it cares for the collective. I'm sure Stallman couldn't use the iphone when it came out because of constraints, that doesn't mean the iphone ever was DoA.
            • themihai 10y ago
              I can't speak for the collective. As far as I'm concerned the current offers of BaaS are dead on arrival. Time will tell. I could see some value in the iPhone but I don't see much value in the current BaaS offers. Not enough to switch from the current alternatives. They are not transformative like the iPhone was. To complete your analogy we had smart phones before just like we have various BaaS services now.
    • golemotron 10y ago
      > You can't evaluate a technology by looking at drawbacks alone, you have to consider the benefits as well, and whether they outweigh the drawbacks. For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.
  • nileshtrivedi 10y ago
    This is not a concern if the platform is open-source (like RethinkDB's Horizon) and you can choose to self-host.
    • themihai 10y ago
      RethinkDB doesn't seem to be a general purpose BaaS. I definitely don't think BaaS is a bad thing. It's just that the current flavours are not worth it. They are mostly some kind of MVPs. Edit: I'm not very familiar with Horizon. It looks promising but I assume it's tightly coupled with RethinkDB?
  • davidw 10y ago
    Once you've written a bunch of code in a language, you're pretty much locked in - without a massive effort - in any event.
    • safeignorance 10y ago
      In almost all cases, there's a significant difference in the sort of risk that comes from B/FaaS dependencies and the sort of risk that comes from PL lock-in. The former leads to technology lock-in and vendor lock-in, while the latter almost never[1] leads to vendor lock-in. Technology lock-in without vendor lock-in isn't that huge of a liability. A popular PL under an appropriate license isn't going to disappear tomorrow, and its creator doesn't have the power to hold your business at gunpoint. Conversely, B/FaaS providers upon which you truly depend definitely can extract (or by disappearing simply destroy) much more value than you originally anticipate. [1] If you use Wolfram Language or Matlab then your choice of PL causes vendor lock-in, but most PLs aren't like this.
      • davidw 10y ago
        I agree - "vendor lock-in" seems like a valid point, although I don't know the details of many of these services. "Locked into a programming language" is something that will probably happen kind of naturally anyway.
    • themihai 10y ago
      I don't follow. You can write other modules in different languages. The data sources are language agnostic. Nobody forces you to do use a specific programming language in the first place unless the platform is close sourced. The point is that with a close source BaaS you have no control on the tools or costs or availability(i.e. deprecation policy) of the service.
    • nawitus 10y ago
      Locked in maybe, but not vendor locked in if the language is open source.
      • 10y ago
  • scrollaway 10y ago
    I like to think that vendor lockin is something I care greatly about, for the correct reasons. In the case of AWS Lambda however, it doesn't apply. Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app. When I hear people say they're trying to "be generic", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is. If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism. Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place. PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.
    • theptip 10y ago
      Parent post didn't say anything about abstracting away "serverless". Lock-in refers to (as the OP article discusses) the fact that if you use AWS Lambda, you are tied to their APIs and deploy mechanisms. If you want to move to Google's FaaS offering, you have a lot of work to do, and may need to restructure your app logic as well.
      • scrollaway 10y ago
        And that's wrong; a complete misunderstanding of how both serverless in general and Lambda specifically works. You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run. The extraction is very simple. Here, take a look at a SNS-triggered lambda: https://github.com/HearthSim/HSReplay.net/blob/e12a6b8217b3b691bc3617fcd3b0815900710bd7/hsreplaynet/lambdas/uploads.py#L87-L104 https://github.com/HearthSim/HSReplay.net/blob/e12a6b8217b3b... One line of code is vendor-specific. I could move to a different vendor in a heartbeat. Yes, bits and pieces are using SNS/S3; some of which are already abstracted away, the rest which can be easily replaced. And frankly, when dealing with platforms as large as AWS, the vendor you choose is a big deal. You're not supposed to change every week... so it doesn't matter if it takes a little cleanup to move to another vendor. If it's taking you more than a few hours, your code is making assumptions it shouldn't about the underlying architecture and that's your fault, not amazon's.
  • jakub_h 10y ago
    Then why not have standardized APIs? You could just switch implementations, then, if you stop liking your current vendor. (Or maybe the future lies in call-by-meaning architectures and automated adapter generation?)
    • prodigal_erik 10y ago
      Someday a standardized API will become popular enough that AWS will need to support it, but they aren't going to do anything to hasten it.
  • beat 10y ago
    The language lock-in issue seems to be mostly an issue with Lambda at the moment, and I suspect it will resolve itself over time. As it, even on Lambda you have the choice of JS, Python, and Java, which is a lot of flexibility. I expect we will see "official" Go, Ruby, JVM languages like Clojure and Scala, etc. If you can't use some obscure hipster language, that might be a problem. But my biggest gripe at the moment is lack of Ruby, and I'm sure Amazon will fix that.
  • morgante 10y ago
    That's true for things like Parse, but much less true for Lambda. For the most part, Lambda code is just normal JavaScript/Python. It would take fairly minimal effort to take that code and package it up to deploy on a normal (non-Lambda) server.
  • pbreit 10y ago
    Shouldn't serVER architectures be/get easy enough that the flexibility/transferability far outweighs whatever the BaaS's are providing? Is it really that hard to run a server in this day-in-age?
    • blowski 10y ago
      Depends what you're doing. If your code is simple but serving at scale is the problem (Twitter?) then I can see why this kind of architecture appeals.
  • toddmorey 10y ago
    I completely disagree that it's DOA. In fact, I think it's clear that is the future of development. Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how it makes sense.
    • themihai 10y ago
      I didn't say the technology is DOA. Just the current offers which seem locked in to specific vendor implementations. The current BaaS offers are too intrusive and just not good enough to worth the switch from a PaaS to a BaaS.
      • BraveNewCurency 10y ago
        > good enough To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: - Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda Is there a reason to re-write your backend? No. Is there a reason to consider it on your next project? Possibly.
        • dragonwriter 10y ago
          > To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things: Since any site "may or may not radially change their business model" at any time, you really only list two substantive options: (1) Use an VPS, or (2) Use Lambda But, really, there's a more choices: (1) Use a VPS or IaaS (with full sysadmin overhead), (2) Use a PaaS (like Google AppEngine) and avoid sysadmin overhead (but probably have more code than a "serverless" function host like Lambda), or (3) Use a "serverless" function host like Lambda You probably don't want to do #1, since for low-volume and trivial logic its (1) comparatively expensive, and (2) high sysadmin and programming overhead compared to the other options. #2 is lower overhead (particular on the sysadmin side), but still more than #3. But possibly cheaper (e.g., if the requirements fit within the free quotas for AppEngine.) #3 may be the best solution for some things, but its not as stark as a choice as you present it to be.
  • joeyspn 10y ago
    (ahem) Serverless v1.0 is multi-cloud and multi-language... https://github.com/serverless/serverless/tree/v1.0 https://github.com/serverless/serverless/tree/v1.0
  • tcarey83 10y ago
    Well for AWS Lambda, they offer three languages: Java, Javascript, and Python. Even then, its really just running in a container and you have access to anything in their standard Linux AMI and whatever else you include with your code, so you could really use almost any language you want. I'm using wkhtml2pdf with my Python code which is a c++ executable. Also, although the Python is 2.7, you can easily use the existing Python 3 environment or include your own. As far as lock in, it is trivial to utilize the same code on your own servers. I do that for my Python code for development using a simple Cherrypy setup in less than 100 lines of code.
• 0xmohit 10y ago
  Previous (recent) discussion at https://news.ycombinator.com/item?id=11921208 https://news.ycombinator.com/item?id=11921208
  • runesoerensen 10y ago
    I submitted this link: http://martinfowler.com/articles/serverless.html#drawbacks http://martinfowler.com/articles/serverless.html#drawbacks with the title "Serverless Drawbacks", as that was the recently added section. Guess someone changed it, but it's not a dupe :) In any case, it seems that "Benefits" has also been added since the last HN discussion (revision history: http://martinfowler.com/articles/serverless.html#SignificantRevisions http://martinfowler.com/articles/serverless.html#Significant...).
• skewart 10y ago
  I'm cautiously optimistic that the vendor lock-in will fade away over time. Hopefully open source frameworks can provide a jQuery-like abstraction layer over all of the vendor-specific implementation details. Of course, there are lots of challenges when you start getting into deeper architectures - queues triggering layers of lambdas interacting with various caches and data stores. But I we'll see best practices emerge that help people keep things simple and flexible. For testing it should be possible to run everything in a mock vendor system on your local machine - not that such a system exists today, but theoretically it could. Overall, my sense is that Serverless architectures will never be useful for everyone. They'll always be better for smaller, simpler systems that don't see tons of traffic. The Serverless community should focus on these use cases. The thing is, there are tons and tons of apps that are over served by all the flexibility EC2 provides. And there is another set of unborn apps that haven't been created only because the barrier to setting up and managing the backend was a _little_ too high. I'm really excited to see serverless bring these apps to life.
  • themihai 10y ago
    I actually think the opposite. Serverless architectures are the future for most of the app servers that need a language agnostic API. Maybe I didn't get it right but to me BaaS is just a PaaS with a common API interface(i.e. authentication, input/output serialization, cache etc).
    • beat 10y ago
      There's a pragmatic definition buried in the article... if you can't spin up your app in 20ms and run it for half a second effectively, it's PaaS, not serverless.
• rainhacker 10y ago
  If successful this could lead reduction in developers needed in companies that use say AWS lambda.
  • spriggan3 10y ago
    > If successful this could lead reduction in developers needed in companies that use say AWS lambda. How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?
    • buckbova 10y ago
      You can't. Isn't everyone using the same language simple? Convenient? Maybe not.
    • nawitus 10y ago
      > cheaper relative to hosting fees maybe Currently serverless is more expensive in the average case from what I gather, mainly since it's new and there's little competition.
      • taurath 10y ago
        If avg case is that you stay within an average load for long periods of time, then it'll likely be more expensive (given a certain floor of actual load - for in-dev apps its dirt cheap - you won't have many servers running doing nothing.
    • rainhacker 10y ago
      > What if I want to use language XYZ not supported by lambda ? Such problems can apply to any ready made solution. In general, a vendor product may or may not suffice custom needs and a user is free to build one from scratch. Abstraction of major pain points that fits a wide variety of user needs, if handled properly, can pave the way for a competitive solution.
  • tschellenbach 10y ago
• rhinoceraptor 10y ago
  Aren't 'serverless' PAASs just a reinvention of PHP hosting?
  • deleted 10y ago
    [deleted]
  • themihai 10y ago
    Well they are. I've always asked myself why there is no such service..then it was GAE and then docker and here we are!
  • jameslk 10y ago
    I see similar parallels, but where as PHP shared hosting often meant one server handling multiple sites upon request, FaaS seems to be more generic with multiple (virtual) server instances handling multiple site functions upon request. So while each site was a PHP monolith on shared hosting, a FaaS architecture could be many smaller units of code, spun up on demand to handle a specific need of a service, possibly across multiple servers.
    • paulgb 10y ago
      A better comparison might be PHP on MediaTemple's Grid service circa 2006 (https://techcrunch.com/2006/10/17/media-temple-crushes-shared-hosting/ https://techcrunch.com/2006/10/17/media-temple-crushes-share...)
  • theptip 10y ago
    Adrian Cockcroft: "If your PaaS can efficiently start instances in 20ms that run for half a second, then call it serverless." https://twitter.com/adrianco/status/736553530689998848 https://twitter.com/adrianco/status/736553530689998848
    • kowdermeister 10y ago
      No, call them extremely fast lifcycle servers.
• buckbova 10y ago
  I wanted a good tutorial/walkthrough on this topic. Has anyone gone through https://pragprog.com/book/brapps/serverless-single-page-apps https://pragprog.com/book/brapps/serverless-single-page-apps? The example material looks good. Overall it could be a bit short.
• eloycoto 10y ago
  I'm early adopter of serverless applications, few weeks ago was released a tool that make manage our Amazon lambda applications even easy. https://github.com/jorgebastida/gordon https://github.com/jorgebastida/gordon A few examples can be found here, and it's a good point to start if you're using Aws Lambda https://github.com/jorgebastida/gordon/tree/master/examples https://github.com/jorgebastida/gordon/tree/master/examples
• idoco 10y ago
  Sort of related, I've implemented a GitHub pages based serverless app demo, that uses GitHub API to execute git operations from the browser. Though slightly weird, I really enjoyed this experiment, and think there might be something to this concept. https://github.com/idoco/GitMap https://github.com/idoco/GitMap
• tschellenbach 10y ago
  There's a big difference between Paas, where you hand over control of your backend. Compared to Faas, where you just outsource a small part of your infrastructure. FaaS solutions like algolia, getsentry, getstream.io. mapbox, layer, keen.io, twilio, stripe etc only run a small part of your application. They scale well, are more reliable and often more cost-effective than an in-house solution. If you're ever not happy with them it's easy to switch to an alternative. If Algolia no longer works for you, simply switch to Elastic. If you're not happy with Mapbox, use google maps. No longer like, getstream.io, use Stream-Framework. It's relatively easy to change since you're not handing over your entire backend. Also see my post on HighScalability about this: http://highscalability.com/blog/2014/12/22/scalability-as-a-service.html http://highscalability.com/blog/2014/12/22/scalability-as-a-...
  • nostrademons 10y ago
    Twilio, Stripe, etc. aren't what the article is referring to as FaaS (which, incidentally, I've never heard of outside this article but seems pretty descriptive). They're talking about things like Amazon Lambda, Google Cloud Functions, and Parse Cloud Code, where you write code that runs on a third-party service. The entry & exit points of the code are under the control of hosting provider, which distinguishes it from PaaS, where they normally take a well-known platform that'd work fine on your laptop and then perform hosting and administration. Think of it as the API vs SPI distinction that we used to have back in Windows-land. API-only services like Twilio or Stripe are usually just called SaaS.
  • nickbauman 10y ago
    With the downside being the lack of cohesion with the rest of your system(s).
• SNvD7vEJ 10y ago
  What a ridiculous and strange definition this is. Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers... Why not just call it "Multiserver" instead. If they mean "containerless servers" or "microservices", then why don't they say so? If they mean "distributed servers" why not call it that. If they mean that the client relies on multiple services (each hosted on different servers) why not just call it a thick/fat/stateful client? Even a database is a remote service (if not embedded), that is run on some sort of server. Calling anything serverless is just ridiculous as long as it depends on services on the network. This smells really bad of just another attempt at marketing a pointless definition just to get more business.
  • deleted 10y ago
    [deleted]
  • Illniyar 10y ago
    No, the idea is simple - the servers are invisible to the user, he doesn't know what or how many are in use. Since the servers are completely abstracted away, they could have just as well not be - hence serverless. An analogy escapes me but I sure there are some.
    • SNvD7vEJ 10y ago
      So it is about how the user perceives the application?! If so, why is it called "an architecture"? Or do you mean that the user don't have to care on how to configure the application? Then "Zero-configuration" is a better name. Or do you mean that the application hides that it use services on the net? Then it is even worse.
      • freyr 10y ago
        > So it is about how the user perceives the application The user here is the developer. Here's an explanation from the article: > "some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party ... One way to think of this is Functions as a Service." FaaS is probably a better name.
• bitwize 10y ago
  So apparently "serverless" means you don't have to requisition a cloud instance to run the service. I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else. Just because you're doing something old "in the cloud" now doesn't make it a new thing. Just like you can't append "...with a computer" to an existing method and get something patentable.
  • justinhj 10y ago
    Does it matter whether something is new or not? The fact is there are services such as AWS lambda that people are using and talking about, so we need terminology for that.
    • bitwize 10y ago
      Not really, as long as it's useful. But call it what it is -- hosted services. Don't make up a new, nonsensical name.
      • justinhj 10y ago
        Hosted services doesn't really differentiate what they are. DynamoDB is a hosted service. So is EC2 and ECS.
        • bitwize 10y ago
          Then call it function hosting or business-logic hosting. "Serverless" means "there is no server" which is demonstrably false. Or should I assume that words don't mean things?
    • collyw 10y ago
      I think it does matter in a lot of circumstances. Take NoSQL which was hyped as something new 5 or 6 years back. Because of that everyone under a certain age decided that they had to use it. The older more cynical of us realized that this was how people has been writing software before SQL came along, and realized we were throwing out a whole host of features and benefits because this was the "new" way of doing things.
• happyslobro 10y ago
  For my first serverless project, I built a service that manages an advertising account, by analysing ads and optimising the spend spread for a configured goal. I was surprised to find that one of the most difficult aspects, was in throttling outgoing API requests. Basically, I needed to avoid abusing a 3rd party service by hammering it with parallel or rapid fire requests. I discovered all kinds of weird solutions: - Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm to fire when the queue length was >= 1 for at least one second. Have a variety of lambdas respond to the alert by checking if the have any work to do, and then racing to pop the queue and do one operation. I think I needed SNS in there too, for some reason. Fanout? - Build a town clock on an EC2 and have it post "admit one" tokens to SNS. Nice and simple, but I was evaluating serverless, and adding a server felt like defeat. Might as well just run the whole thing on that EC2. - Have on lambda pop request descriptions from a queue, and sleep for one second after sending each one. The request responses would have been pushed onto another queue. All of the other lambdas could just handle the events they cared about as quickly as data became available. Sleeping in a lambda just felt wrong, but for one second, it probably would have been fine. In the end, I was still experimenting and exploring when my estimate loomed near, so I just wrapped up all of the application code and piped it all together with delays in loops that made API requests. Deployed it to Heroku in a hurry with minimal fuss. What I learned: - There are bad use cases for serverless, and I had started on one (SLS doesn't wait on no one) - Serverless does encourage a clean architecture, from a code perspective: I was able to quickly transform it into a completely different type of application. - AWS's services have lots of little surprises in their feature set: SQS doesn't fire any kind of event. SNS can't schedule events in the future (maybe I should have expected that one). Cloud watch events can only trigger a single lambda. - There is a need for a town clock / scheduler as a service in AWS'. How many people have built that themselves?
  • rockmeamedee 10y ago
    I'm no experienced Lambda user either, but here's a couple helpful things I've found: * I think API Gateway can throttle requests. Not sure if that was part of your pipeline or if your lambda had a different trigger. * There is a Town clock SNS event https://alestic.com/2015/05/aws-lambda-recurring-schedule/ https://alestic.com/2015/05/aws-lambda-recurring-schedule/
• naveen99 10y ago
  What if the web had the equivalent of 900 numbers. Something like http900://foo.bar.com
• be_erik 10y ago
  We're currently exploring lambda for certain applications as well. My coworker wrote up a nice little post about it: https://product.reverb.com/2016/07/16/deploying-lambdas-with-s3-jenkins-and-gulp/ https://product.reverb.com/2016/07/16/deploying-lambdas-with...
• glic3rinu 10y ago
  I expected the article to be about the goodness of some peer-to-peer architecture that doesn't require central servers, not a twisted definition of cloud computing.
• mpdehaan2 10y ago
  One of the bigger problems with serverless architecture (beyond catastrophic lack of good debugging and development tools) is the idea of managing multiple users, working on multiple code branches, and all needing environments that somewhat closely mirror production. This leaves servless as a decent way to hook an event callback to some AWS event (new file uploaded to S3, etc) but IMHO not anything that approximates any kind of business logic - or anything that will need to be iterated on by more than one developer. I feel it is a massive reach to market this to anyone at this point, and if this catches on, would really make me hate programming compared to what local development in VMs feels like - where I have much greater tools. It's inefficient both for the developer and at runtime.
  • deleted 10y ago
    [deleted]
  • WalterSear 10y ago
    With that in mind, serverless architecture seems to be a micro-optimization that is of the greatest benefit to enterprise customers whose scale is large enough to benefit from reducing their server load to the barest minimum, at the cost of greatly increasing development costs. I don't see how this would be much fun to work on in a team. We have enough trouble her squabbling over who gets to use the staging server next.
    • snom380 10y ago
      I'm pretty sure that if you're considering using Lambda, you'd want to automate creating and deploying the Lambda functions in such a way that you could create any number of them for each developer to play with. That said, the problem with debugging stands (for AWS lambda, at least).
  • nickbauman 10y ago
    I completely agree with you regarding debugging. Especially with Lambda. But App Engine allows you to connect a python REPL directly to your app in the cloud. It doesn't get any better than that. And I've noticed that because mobile developers don't get to pick much to develop to (the device maker dictates) they seem to move much faster than your typical server-side developer who bit twiddles VMs, Dockerfiles and distributed services much more than they admit with the time left to write actual functionality much lower. Too much choice is also a prison.
• deleted 10y ago
  [deleted]
• deleted 10y ago
  [deleted]
• klodolph 10y ago
  I recently evaluated these, and I'm dying to use something like this. I would really love to be able to do this with sandboxed apps written in arbitrary languages like Go, Haskell, Rust, or even C++. Ideally, I wouldn't be managing docker containers or VMs to get certain jobs done. Unfortunately, it's limited to JavaScript, Python, and Java for now. Google Cloud Functions is similarly limited to JavaScript. I know that these languages were chosen because they can be easily sandboxed, but it would be nice to support something more generic without having to create docker containers for everything.
  • nsm 10y ago
    Have you checked out https://github.com/iron-io/lambda https://github.com/iron-io/lambda. Their is a tool for docker container creation, and also AWS Lambda compatibility.
• gshx 10y ago
  One big challenge is the expense that is otherwise avoided via usage of connection pooling. Without the hack to keep the backing containers alive, tearing down and restarting them is expensive and wipes out all hot path optimizations made by JIT compilers besides having to reestablish connections and pay the handshake prices. Apart from the simplest of use-cases at this time, imho this is not an efficient model if sustained performance and low latency are of interest.
  • audleman 10y ago
    I've been wondering this same thing. We use gunicorn to handle our web requests and it pre-loads our code so it's ready at the drop of a hat to serve a request. It takes a few seconds to load up our site, so wouldn't Lambda have to pay that cost with every web request? I've been going under the assumption that it's just not the right use case for Lambda, though I'm hoping I'm wrong.
  • jwatte 10y ago
    If you have any kind of real load, there skills always be instances running. If you have less load than that, you are not a case worth optimizing for, because you pay less than a few hundred per month. Also, small instances are cheap to keep around, and as you pay per request, it's in the providers best interest to make that efficient. Well, that's the sales pitch, anyway...
• jokoon 10y ago
  It doesn't seem the author knows how network programming works. This is all high level abstraction and diagrams, but no simple comparison of what are the pro/cons, what are the constraints, etc.
• cyberpanther 10y ago
  Serverless sounds like CGI evolved past needing a server anymore. Oh yeah and remember spawning CGI processes for every request never scaled well. :-)
  • zwily 10y ago
    Lambda does keep processes running and reused between requests if they're coming quickly. You do, however, only get to handle one request at a time which is not the norm with node backends.
• up_and_up 10y ago
  How is this different then something like Heroku and their add-on ecosystem?
  • snikch 10y ago
    Heroku gives you servers, but manages them for you - so you have long running processes, for web or worker etc. Lambda allows you to have the process run for literally the lifecycle of the job (request, streaming job etc.). In fact, your job can't run for more than a few seconds or it is terminated. Heroku charges you for the hours your dynos run - but what if they're idle most of the time? You still pay for them - not with lambda.
• zpallin 10y ago
  I think a major problem with Serverless architecture, as much as it is awesome, is that to manage it you would need to be already familiar with the underlying systems that provide it. Hence, it would imperative that you already have worked with the architecture you are planning on replacing. Unless there is some elegant factor to Serverless that I am missing. I just can't shake the feeling that at the end of the day this is just a sales tactic. Nevertheless, I opt to use serverless BaaS solutions whenever I can afford to.
• srcreigh 10y ago
  One issue people are talking about is vendor lock-in. I would like to note that this drawback is only valid for non-prototype software. For prototypes, hackathons, or "one time use" websites, these BaaS tools (such as Firebase) are essential. Here is a case study: Last year I was working on an SMS app, QKSMS [1]. We offered a premium version for $2. We did a promotion on reddit where we gave away 10k free premium versions. So, take a second and ask yourself: how quickly do you think you could implement a promo code system + a website for distributing codes for one time use? We did it in about 5 hours. It costed about $100. The website was (and still is) statically hosted on Github. [2] The website source code is ~22 lines of JavaScript. It pulled 12 promo codes from Firebase; and when a promo code was removed, it would (in realtime!) collapse it from the list and display a new promo code at the bottom. The mobile app code was also very simple. First, check if the promo code is available (one API call); if so, enable premium and remove the code (another API call). The reason why it costed about $100 is because we had too many concurrent users: the Firebase free plan allows only 50 concurrent users, and at our peak we were seeing ~500. Since the promo was only for a day, we bought an expensive plan that got pro-rated for just that day. It was an extremely successful promotion. [3] The final result was very interactive. It was amazing to watch the codes disappear in real-time. It was like a game: you had to be fast to enter the code, because the codes were being used so quickly. All in all, I believe we made more money in people buying it anyways (despite the promotion) than it costed to serve it. And keep in mind we built the entire system in about 5 hours. And I'm not even a web developer. An actual web developer could have implemented this in an hour or two. For reference here is the entire JavaScript powering the promo code website: var all_codes = new Firebase("https://qksms-promo.firebaseio.com/public_codes"); all_codes.on('value', function(data){ $('#remaining').text(data.numChildren()); if (data.numChildren() === 0) { $('#status').text('No more codes!'); } }) all_codes.orderByValue().limitToFirst(12).on('child_added', function(data){ $('#status').remove(); var str = '<div class="code" id="'; str = str.concat(data.key()); str = str.concat('">'); str = str.concat(data.key()); str = str.concat('</div>'); $('#wrapper').append(str); $('#'.concat(data.key())).hide().fadeIn(300); }); all_codes.orderByValue().limitToFirst(12).on('child_removed', function(data){ $('#'.concat(data.key())).slideUp(300, function(){ $(this).remove(); }); }); [1] https://github.com/moezbhatti/qksms https://github.com/moezbhatti/qksms [2] http://qklabs.com/qksms-promo/ http://qklabs.com/qksms-promo/ [3] https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_ago_today_i_showed_you_qksms_the/ https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_...
• deleted 10y ago
  [deleted]
• hopfog 10y ago
  I'm using the following setup for one of my sites: Client -> post -> API Gateway -> AWS Lambda -> upload JSON to S3 Client -> get -> S3 Works pretty good!
  • themihai 10y ago
    Is it cost effective? I mean roughly.
    • Cub3 10y ago
      Very very cheap, as long as you're writing your lambdas as performant as possible we've costed our app at ~2c / user / month with heavy api / database / lambda usage
      • themihai 10y ago
        It seems you are estimating the costs per user. I think an estimation per request and perhaps compared with raw EC2 servers would make more sense. Anyway, it's encouraging to hear that's cost effective. My experience with managed/ server-less platforms is quite bad in terms of costs.
• sinzone 10y ago
  If you're looking for an open-source API Gateway (less lock-in) with Lambda Integration then Kong (https://github.com/Mashape/kong https://github.com/Mashape/kong) could be a useful complementary tool for your serverless architecture.
  • snikch 10y ago
    I think you're missing the point of the 'serverless' part, as Kong still requires you to have a dedicated server to run it. One of the early stage benefits of the serverless architecture and AWS's api gateway is that you don't have to pay for resources that you don't consume - so if you've only got a small amount of customers, you don't have to pay for dedicated instances to be running.
    • sinzone 10y ago
      imho serverless architecture doesn't mean that your app is without servers 100%. Backend still serverless, but everything on top (like an API gateway, load balancer, service discovery, etc) can have dedicated resources.
      • snikch 10y ago
        Fair enough - there are definitely use cases where I could see that making sense. I love the value lambda provides for early stage, when every penny counts.
• Sanddancer 10y ago
  One of the big issues here that is only very very slightly glossed over is the security you give up. The only sort of security filtering you get is AWS' WAF, which is considerably weaker than a firewall like mod_security with a default ruleset, or even apache's .htaccess. Inbound filtering, you're limited to a tiny ruleset with only a few conditions, and outbound filtering doesn't exist at all. This lack of firewalling continues up and down the stack. As such, it's a lot harder to create rules regarding any API calls you make to third party services, harder to audit how your app interacts with any datastores, and generally an administrative nightmare. It may be useful for some apps, but just feels like a nightmare to maintain for any decently sized setup.
  • snikch 10y ago
    This may definitely be a concern for some organizations, but I think there's a lot of focus on serverless being all about apis and web requests. Serverless is also a great way to manage stream processing, and job queues - where these issues are less relevant.
  • jwatte 10y ago
    The sales pitch is that the fabric vendor does the administration, and people like you are out of a job. Because the framework infrastructure is supposed to solve all of that behind the curtains, so developers cannot shoot themselves in the foot. (Other than through excessive resource consumption)
  • jwatte 10y ago
    The sales pitch is that the fabric vendor does the administration, and people like you are out of a job. Because the framework infrastructure is supposed to solve all of that behind the curtains, so developers cannot shoot themselves in the foot. (Other than through excessive resource consumption)
  • anthony_barker 10y ago
    Did you look at Lambda scheduled events? http://docs.aws.amazon.com/lambda/latest/dg/with-scheduledevents-example.html http://docs.aws.amazon.com/lambda/latest/dg/with-scheduledev...
• eldavido 10y ago
  Aren't we kind of already there (serverless)? A lot of web frameworks enforce the shared-not-that-much (not quire "shared nothing", but close) style of programming where every HTTP request is essentially just an "event" that hooks into a controller-handler? And if you want anything to stick around from one request to the next, you keep it in memcache/db/BaaS/third-party service, not your own process? I don't think this is as radical a shift as many here might think, especially given the move to containers is already well underway.
  • collyw 10y ago
    Kind of like "schemaless".
• kuharich 10y ago
  Previous discussion: https://news.ycombinator.com/item?id=11921208 https://news.ycombinator.com/item?id=11921208
• EGreg 10y ago
  Why is it called serverless if it uses Amazon Lambda instances?
  • jwatte 10y ago
    Because you, the developer, do not buy or pay for "servers," only ephemeral "code invocations."
    • EGreg 10y ago
      Sweet! So by that logic, all static sites are serverless because I pay for "file hosting" right?
• tomc1985 10y ago
  We used to have serverless architecture... it was called standalone desktop apps! No servers, no backend, no nothing, just you and the code. It was great!
  • smt88 10y ago
    It wasn't great. Updating apps was a huge pain, which meant that bugfixes were fewer and farther between. You couldn't sync preferences/settings between computers. Remember getting a new computer or wiping one? You knew you had hours of work ahead of you, just reconfiguring it. Did you write a shell script to do that for you? Too bad, it did something weird along the way, and now you have to spend hours figuring out what's wrong. And don't even get me started on installing dependencies...
    • tomc1985 10y ago
      It honestly wasn't so much of a bother. Updates were really the only pain point but then programs received updates periodically at best. (Talking dial-up era here) The cost of distribution motivated developers to release much higher-quality code, relatively-speaking, as not doing so cost you more (in terms of disks+shipping, additional bandwidth, etc) and well as earned a much greater amount of ire from your users. If you were smart you had a system for dealing with migrating between computers. Maybe it was a script, maybe you knew which folders to copy, maybe you were extra careful with where you saved everything. Maybe you didn't care. Some of the modern shit is nice (I fondly</s> remember setting up a personal Active Directory+Exchange server to get a private LDAP sync, compared to Google now) but as a whole the current model encourages carelessness and mindless profiteering. There's too much of the equation nowadays in control of people who want to charge you for it, whereas before the user was had control. I miss the days when it was considered rude to require a network connection unnecessarily. Plus, nowadays a product you love can turn to mush and there's nothing you can do about it save stop paying for it (and lose its services in the process), which will never amount to anything unless people do it en mass. Features regularly disappear because some bullshit business reason or another, or some user metric said only 2% of people used it. Well, fuck those 2% guys right?!? Before, if I didn't like your patch I could just revert to the old install discs. Nowadays I have to pray you don't alter your deal further. edit: and don't get me wrong, as a developer the evergreen model is great. But as a power user, I hate it. edit2: not to say older software didn't have its crap. Lots of fussy stuff to deal with. But compare the initial release of Windows 3.1 to Windows 10...
• ianamartin 10y ago
  The main problem I see here is the problem we run into with every hot new abstraction of a thing that some people find troublesome as developers. Someone already mentioned virtual hosting. I'd like to bring up ORMs. There's this idea that you can forget about the datastore--abstract it away, manage it in code, whatever. You don't have to learn about databases, table structures, or SQL if you don't want to. Just think about your models and don't worry about the rest. I'm not against ORMS and find them both amazing and useful in certain ways. What I am against are systems developed entirely by developers who refuse to think about these things. Especially when I have to come into the situation after they have left and do something genuinely unforeseeable, like provide reporting and analytics from the back end, integrate with a third-party system, or--god forbid--add new functionality. What you're left with is a dysfunctional, slow, mess that's incredibly difficult to work with, a data layer that makes no sense unless you're working with that particular ORM, and no ability to tell exactly where in a quarter-million lines of code the exact logic you want to fix or modify actually is. Yes, I'm quite certain that no one would recommend that anyone use serverless architecture that way. It's the wrong tool for the job. Just like ORMs are the wrong tool when performance is critical and you need to manage complexity for 30 services from the same data layer. But someone is going to do it. In reality, probably lots of people will. Some CTOs will buy into the hype and hire teams of consultants to do it or hire their actual dev team full of serverless experts. I'd echo what someone else said to the effect of abstractions are great so long as you understand what you're abstracting and know when it's a good idea to do so. Viewed as a tool for accomplishing a small thing pretty quickly, it sounds cheap, fun, and exciting. Viewed as a new way of taking shortcuts around quality infrastructure that's needed to support large, complex systems, I feel like it's probably a bad idea. Given my attitudes above, it's probably not a surprise that I find the description a bit sketchy. I think calling it Serverless is a misnomer for all of the many good reasons people have pointed out in this thread. But I also question calling it architecture. What I expect we will see in fairly short order is a collection of libraries or frameworks that resemble PhP not only in function (a service that pops in and out of existence on demand) but also a language-like form that evolves rather than being intentionally built--and evolves towards ease-of-beginner use rather than being guided by a coherent architecture. And, in the grand scheme of things, that's fine with me. I just hope I never inherit a system like that.
• zippy786 10y ago
  I truly hope that people stop misleading the mass with buzz words. We already have too many of them being used for clickbait. I don't get why a simple client-server architecture would not suffice the "serverless". Software engineering and architecture design used to be cool in the past with useful design patterns. Now it's full of tricks/buzz words that promise the users of silver bullets that help them to manage code and servers. In reality, no such silver bullet exist and such tricks/architecture fail every day. I've noticed that martinfowler.com is one such place that seems to provide such empty promise of a silver bullet!
  • collyw 10y ago
    I am reading about this trying to think what it could be useful for. (I am sure there are some, I don't see any use for it with my work). "Serverless" seems to be the pricing model. It still runs on a server.
• darkboltyoutube 10y ago
  Dangers of Pokemon Go https://www.youtube.com/watch?v=B2KXVfnw4rg https://www.youtube.com/watch?v=B2KXVfnw4rg
• hackdroid 10y ago
  There is google's appscript(based on javascript), which could also be termed as serverless. So ingenious for individual purposes, I have used it as a database(with google spreadsheet), scraping and saving 1000's of html/xml, deploying and demoing bootstrap websites. It also has a time limit of 5mins 30 seconds which could be overcome by controlling triggers or by using patt0's CBL http://patt0.blogspot.in/2014/08/continuous-batch-library-update-for.html http://patt0.blogspot.in/2014/08/continuous-batch-library-up....
• spotman 10y ago
  Would have liked to see some real cost analysis, other than it should save you money, because that is only true if scale is small to medium. That's the thing, I guess the demographic that lambada is going for it will save money, but along with the mentioned vendor lock in, when you really need to have something on and processing requests non stop the costs savings really evaporate. It's weird to me that the serverless thing catches on when it seems to be best suited for projects in their infancy without need for 24/7 request processing , or things out of the critical path like image resizing or things of this nature. But entire apps? Feels very much like going back in time to shared hosting. I could see it saving money until about 1m requests a day and then a sharp drop off where you are hemorrhaging cash after that... With modern auto scaling systems that aws and gce provide I bet most shops don't stand to save any more money than with a normal modern day refactor. At the end of the day this leaves you more rope to hang yourself with. It makes it easier to run slow or poorly thought out code. 1000 processes might be cool but is never as cheap as 2 working correctly that accomplish the same thing, as an extreme but actual example of a situation I helped unwind with GAE, which was serverless before the buzzword.
• urza 10y ago
  Also see "Unhosted web apps": https://unhosted.org/ https://unhosted.org/
• rwallace 10y ago
  It's sometimes okay to use inexact or uninformative terminology, but it becomes a problem when words are used to mean their exact opposite. So if you are going to talk about serverful programs - those which depend on servers and can't operate without them – that's fine, but please use some term other than 'serverless'.
• aslom 10y ago
  The main point of serverless is cost - it is not just "Reduced operational cost" but orders of magnitude difference if one were to build cloud solutions that can scale the the same level and pay for cloud infrastructure (even if not used at minimum something must be running ...), monitoring, and people effort involved on ongoing basis (real cost) Compare to working with level of abstraction of "entity" (function, could be bigger) and have it running when needed and scale as needed.
• OldSchoolJohnny 10y ago
  "Serverless" WTF? I thought it would be a cool article on peer to peer mobile apps that don't rely on a backend server, something I think will be very popular in future for a variety of reasons. Please, let's not accept this redefinition of a fundamental and well known term.