37 ms·

The Serverless Revolution Has Stalled

• k__ 6y ago
  "Limited Programming Languages" AWS Lambda can run all programming languages via layers. Cloudflare Workers can run all programming languages that compile to WebAssembly. "Vendor Lock" True, but being locked into Kubetnetes isn't a cakewalk either. "Performance" Cold-starts aren't a thing for Cloudflare Workers and can be mitigated for AWS Lambda. AppSync and API Gateway don't even have them if you directly integrate with AWS services. "You Can't Run Entire Applications" You can and it has been done multiple times. Sure, you shouldn't blindly build everything with Lambda and API-Gateway without measuring. But many services, especially Cloudflare Workers are quite cheap.
  • shiftpgdn 6y ago
    K8s can go almost anywhere any time with fairly minimal ramp. With the frequency I am hearing about AWS billing disputes these days it's probably best to not seal the keys to your kingdom in their service.
    • k__ 6y ago
      The problem is getting K8s to the point that it can go almost anywhere.
      • brianwawok 6y ago
        Eh? I was able to go from a docker image to live and 0 downtime deploys in a few hours?
        • Silhouette 6y ago
          But how many hours/days/years did it take you to learn how all the parts move before you became capable of setting something like that up within a few hours? Anecdotally, stories of businesses abandoning entire cloud automation projects because they wasted weeks and never had anything to show from it don't seem unusual, so evidently a considerable amount of knowledge and skill is required to get value out of these tools.
          • k__ 6y ago
            This. I used K8s and serverless tech and while serverless wasn't as simple as some evangelists try to sell it, it was at least a magnitude simpler than K8s. Even managed K8s, which removed most of the admin plane work with nodes, was still significantly more work to get up and running.
          • brianwawok 6y ago
            None really? I don’t consider myself the worsts best Sysadmin, but the hard part was making an app docker. Making a docker k8s was easy.
        • Nextgrid 6y ago
          My worry is less about getting it set up to run a container and more about securing it, monitoring it and being able to respond should things go wrong.
  • synthc 6y ago
    Sure, everything can be done serverless with a bunch of workarounds, that's one of the reasons it stalled IMO. Serverless makes somethings easier and other things harder, so it's advantages over good old fashioned servers are clear cut.
    • mattmanser 6y ago
      Did you mean aren't clear cut? Autocorrect?
      • synthc 6y ago
        Yes, i meant "aren't". Damn you autocorrect!
    • k__ 6y ago
      In my experience there are only a few edge-cases that need workarounds and even those get fewer with every release.
  • EdwardDiego 6y ago
    > AppSync and API Gateway don't even have them if you directly integrate with AWS services. I was quite impressed when I exposed Kinesis via API Gateway, it just worked, although the Kinesis requirement that data be b64 encoded did require some fiddling about with mapping templates.
    • k__ 6y ago
      People always think serverless mean FaaS, while in fact you should use FaaS only to glue together other serverless services when it's not otherwise possible. Sure, a container is better than a serverless function in many ways, but the function isn't what the container is competing with.
  • tuananh 6y ago
    cloudflare workers has been doing very well for me too. the only problem is it's too tight down to CF
• benjaminjosephw 6y ago
  > I'm not against serverless solutions per se. I promise. It's just that developers should realize – especially if they are exploring serverless models for the first time – that this technology is not a straight replacement for servers. Ha. So the name didn't give that away then? In all seriousness though, I think another avenue for serverless to still explore seriously is declarative application definitions rather than just functions/runtime as a service. Hasura[0] are doing this with GraphQL but I think we'll soon seen (are already seeing?) a surge in these kinds of cloud abstractions that do much more for you than a simple on-demand runtime ever could. [0] - https://hasura.io/ https://hasura.io/
• GiorgioG 6y ago
  Serverless is the new microservice. Fortunately, for the most part it’s fallen flat on its face and for good reason - most companies don’t need it: it adds unnecessary complexity for minimal gains.
  • pauldickwin 6y ago
    Except that people actually used microservices and microservices are actually additive and helpful.
    • Nextgrid 6y ago
      They are helpful in probably 10% of cases where they are indeed the right tool for the job and the benefits outweigh the downsides. For the majority of companies out there it's just a tool to overcomplicate your stack and turn it into an engineering playground so you can justify 2-3x the headcount despite no significant productivity increase. But hey, at least your company can now be giving talks about how they solve their (self-inflicted) problems managing all the microservices and throw that buzzword on the careers page.
      • kulig 6y ago
        >justify 2-3x the headcount As a worker, and not a company owner, this sounds awesome.
      • sabellito 6y ago
        Although your overall point seem reasonable, "some companies need it, some don't", throwing "10%" and "majority" around doesn't help with credibility.
    • staticassertion 6y ago
      People on HN seems to believe that outside of Google it is impossible to have problems that are complex and high scale, therefor if you use microservices and/or serverless and/or nosql etc etc it's just that you're following the hype, not that you legitimately benefit from them.
• jasoneckert 6y ago
  From an evolutionary point of view, I find serverless appealing and exciting - a romantic idea. However, the frequent posts along the lines of "my Lambda function was buggy and now I owe Amazon three billion dollars" definitely kills the romanticism.
  • WrtCdEvrydy 6y ago
    Honestly, we've had a lot of fun with OpenFaaS and services that can publish to it. You'd be surprised how great it is to pass a parametized query and have it turned into a function quickly. Doing stupid things on AWS is really easy and sadly billing can be up to 24 hours delayed.
    • jakub_g 6y ago
      Isn't there some sort of security built-in, like "if suddenly the bill becomes 1500% the norm, kill the instance and start serving 404s"? (I know nothing about cloud, honestly curious)
      • PopeDotNinja 6y ago
        > Isn't there some sort of security built-in, like "if suddenly the bill becomes 1500% the norm, kill the instance and start serving 404s"? How about we call it auto-snailing. "I wanted to grow fast, but not THAT fast! Slow it down there buddy."
      • barkingcat 6y ago
        It's in cloud vendor's interests to charge more money regardless of mistakes. They do offer charge limits, but they don't want you to use them. There are lots of posts online that document "talk to amazon and they'll take out the extra charges" but there are even more cases where the people just pay the bill and thus amazon makes money and profit.
      • ben509 6y ago
        Nope. As the GP mentioned, billing is delayed, but you could set alarms on your lambda usage. You could even use something like X-Ray to get more insight into what your usage looks like. The problem is there's not a clear way to tell the difference between recursive calls and heavy traffic. AWS components are fundamentally a network of nodes that are sending traffic to other nodes. But there's no unifying language that can model this, so you can't describe what this graph ought to look like. (e.g. you want to be able to say "lambda Foo should be called twice for each event to Bar".) And that'd be hard to do since most nodes are general purpose computers, like Lambda and EC2, that can send traffic anywhere for arbitrarily complex reasons. Since you can't describe what it ought to look like, trying to alarm on it becomes a problem of detecting anomalies. You can sort of do it, but AWS doesn't want to do it because they'd be making a promise they couldn't generally keep.
• aeturnum 6y ago
  I never quite understood what problem serverless platforms were solving for companies that already deployed their own SAAS solution. As the article says, serverless is one of many (many) ways to wrap a quantum of functionality inside an internet-accessible environment. You could have a chunk of python in a serverless setup, a small flask server in a container in k8s, as an endpoint in a monolith, etc. Each of these environments have difference performance, cost and maintenance characteristics, but I think of the star feature of serverless as the light deploy. For companies that don't have a deploy chain, that makes serverless very attractive, but if you've already invested in one it seems less compelling. I think serverless products have a ton of potential for side projects and hobby projects. It's great that you can just type out python and access it on the internet immediately! That quality just never seemed to be what was holding back SAAS companies.
  • mobilefriendly 6y ago
    Part of the problem is that the hobbyist market is overwhelmingly PHP, which Lambda doesn't support natively.
    • colinbartlett 6y ago
      I’d be curious to see the data behind that claim that the hobbyist market is overwhelmingly PHP. I must not have any exposure to that ecosystem because PHP does not come to mind when I think of hobbyist development.
      • lhorie 6y ago
        Maybe not hobbyists, but wordpress alone powers like a a third of the web.
        • robertlagrant 6y ago
          Sure, but Wordpress is nothing to do with PHP lambdas.
• deleted 6y ago
  [deleted]
• pydry 6y ago
  The things that put me off were hard resource limitations (e.g. runtime/memory), idiosyncratic vendor set up and vendor lock in. The former ends up making the latter so much worse. The wins also didn't seem great enough to overcome these twin beasts.
• satisfaction 6y ago
  Has the noisy neighbor been solved when running serverless?
  • withinboredom 6y ago
    On Azure, I haven't really seen this problem. But you can also pay for dedicated serverless via Premium (but you pay per core/mem allocated vs. number of executions). It seems pretty interesting since multiple function apps can share the same infrastructure (allowing for more dense deployments).
    • jnwatson 6y ago
      "Dedicated serverless". We've come full circle.
    • marktangotango 6y ago
      User/application density is the real potential win for serverless IMO, that no one ever really talked about (to my knowledge) and noisy neighbor was the problem to be solved. The real world indicator would have been hosting costs going to zero and 10-100x apps multiplexed onto the same "real" server substrate. Instead everyone is perfectly happy paying for cloud vm instances. In hindsight I guess "function as a service" wasn't the complete solution I thought it was.
• sdan 6y ago
  To implement serverless, you'll need to re-architecture your entire infra. For that itself, I don't think it's worth it; because serverless is pretty much all event driven (which many things might be, but might not be able to fit on serverless; even it does, it might just be easier to plop it on a simple instance). I do see a big potential for small and simple projects though. No need to setup instances and worry about networking: just deploy it and go.
• Havoc 6y ago
  I think it's more a case of it coming full circle. People realising that it's just another tool in the toolbox rather than 1 tool that can replace their entire toolbox. Much of the cynicism seems to come from that. I do agree with jason though - open ended serverless things charged per use are no fun. Now you can bankrupt yourself at scale with that bug & the 1000 instances.
  • JMTQp8lwXL 6y ago
    People place such high expectations for new innovations solving all of their problems. No, it isn't a panacea: apply it only when it makes sense to do so.
    • quickthrower2 6y ago
      I'm yet to meet such people in real life. At places I work people always treated serverless as a tool. Usually solutions would have a little lambda icing on a large monolith cake, so to speak.
  • seg_lol 6y ago
    Pay per request needs to be within 2x magnitude of an always on server. Really one should be paying for latency, scale, cpu time and bandwidth.
    • Havoc 6y ago
      >Pay per request needs to be within 2x magnitude of an always on server. Are any of them? Stuff like cloud run is very competitively priced when assuming base case...but by its very nature it can scale up near infinitely. And with it bugs & bills. The ability to cap things by 2 order of magnitudes would make me sleep much better. (1 would be better).
      • seg_lol 6y ago
        They don't, they are all crazy priced which means the cloud providers don't really know what they are doing, forcing people to deploy their own FaaS layers inside their cloud infra, which is a totally valid solution. Currently, FaaS platforms should be viewed like a cron. The majority of the benefit is if the fn is called in the low thousands per day.
• dcolkitt 6y ago
  A lot of this just seems to be that Kubernetes works really well. Serverless seemed more compelling to me 5+ years ago. But nowadays, I just setup my K8 templates with auto-scaling groups on GKE, and it pretty much works just as well as serverless was promised. Compute demand gets seamlessly transformed into compute supply. I almost never have to think about managing individual hosts. And the cost is cheaper and performance is more predictable than serverless. Plus it's mostly all platform agnostic.
• acd 6y ago
  Developers found out - There was servers involved after all.
• barkingcat 6y ago
  Because serverless is not serverless. Fundamentally this doesn't work because if you've gotta have a server in the end, why not either admin yourself or use one of the cloud vendor's other products for more control?
  • genidoi 6y ago
    Serverless just means that your infrastructure is programmatically defined through configuration files rather than manually stiched together, so (in theory) the underlying silicon is abstracted away in a similar fashion to the x86 ASM that your code gets compiled to. In practice that isn't always the case (horror stories of rogue $xx,xxx/day lambda functions) but from my understanding that's the serverless end game.
  • jacques_chester 6y ago
    Serverless is an economic description, not a technical one. A "serverless" service puts ownership and the immediate costs of ownership on the other side of an economic boundary. It's a silly term, but successful. If anything, arguing against it made it more successful through mere repetition of the word.
  • Sohcahtoa82 6y ago
    Do we really have to have this conversation every time the term "serverless" is used?
• jariel 6y ago
  The issue is that they represent in some manner an 'alternative architecture' that's less mature and hard to piecemeal break out of. You need to move a few pieces around. I don't agree that 'once you've gone K8 why bother, just use that' - I don't think K8 is as elegant as the promise of serverless, and it has it's own 'lock in'. Just so happens you may need to have K8s anyhow ... so the pragmatic question then is 'We already have K8s because we have to have it ... so in that context, we can just use it' If we had a 'severless' version of Docker, i.e. some de-facto standard for it, I think it would obliterate a lot of architectures, just because the promise is powerful. Developers don't actually want K8s or even true DevOps complexity, we just want a giant computer we can run stuff on and not have to worry.
  • robertlagrant 6y ago
    K8s lockin isn't the same. You can run it on any cloud, or run it locally. None of that is true for serverless functions (unless you go for knative, which is, yep, built on K8s).
• nickjj 6y ago
  Kind of surprised the article didn't mention lack of reasonable development environment. At least on AWS, the "SAM" experience has been probably the worst development experience I've ever had in ~20 years of web development. It's so slow (iteration speed) and you need to jump through a billion hoops of complexity all over the place. Even dealing with something as simple as loading environment variables for both local and "real" function invokes required way too much effort. Note: I'm not working with this tech by choice. It's for a bit of client work. I think their use case for Serverless makes sense (calling something very infrequently that glues together a few AWS resources). Is the experience better on other platforms?
  • Latty 6y ago
    Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. I tried AWS, and then IBM's offering which is based on an open source (Apache OpenWhisk) project, thinking that it might be easier to work with, but that was also a pain. I just lost interest as I was only checking it out. For something constantly marketed on the ease of not having to manage servers, it fell a long way short of "easy".
    • com2kid 6y ago
      > Yeah, I took a look at using a serverless framework for a hobby project, and it was just a real pain to get started at all, let alone develop a whole application in. Look into Firebase functions. Drop some JS in a folder, export them from an index.js file and you have yourself some endpoints. > exports.helloWorld = functions.https.onRequest((request, response) => { response.send("Hello from Firebase!"); }); The amount of work AWS has put in front of Lambdas confuses me. Firebase does it right. You can go from "never having written a REST endpoint" to "real code" in less than 20 minutes. New endpoints can be created as fast as you can export functions from an index.js file.
      • iudqnolq 6y ago
        And if you need a dependency that has a sub dependency with a subdependency that uses a native module prepare for poorly defined -fun- hell getting it to work. A surprising amount of standard is libs do.
• larrik 6y ago
  Has it? We've been simply throwing huge Django projects into Zappa and seeing huge benefits. The biggest issue we run into is the more servers you have, the harder it is on the database.
• ChicagoDave 6y ago
  I take issue with all of the complaints here... - performance: first rule of architecture is that you don't build the entire thing on the needs of high performance...you only address performance as-needed - vendor lock in: this is the worst reason. Most companies choose cloud vendors and stick with them over many years. I'd love any survey that showed some massive migration between vendors on a regular basis, but it does not exist. - the monolith: granted, serverless is really best when building something from scratch. Trying to "migrate" to serverless is just a bad idea. Trying to "upgrade" portions is okay, but do it well using the autonomous bubble pattern, making sure you have a solid translation layer I believe serverless is our best modern architecture, but I also understand that not every company is ready to do the work and/or pay the price of the change in development processes. I'd agree that it's stalled, but moreso out of fear and ignorance than anything else.
  • mrkeen 6y ago
    > vendor lock in: this is the worst reason. Most companies choose cloud vendors and stick with them over many years. I'd love any survey that showed some massive migration between vendors on a regular basis, but it does not exist. Why do you think companies stick with vendors for so long instead of switching?
    • ChicagoDave 6y ago
      Because it’s a part of long-term planning and the lock-in variable a lower priority than all of the other factors.
  • mrloba 6y ago
    > I'd love any survey that showed some massive migration between vendors on a regular basis, but it does not exist. Isn't this a sign of existing lock-in? Also, I think lock-in comes in degrees. Some are worse than others. Even if we're slightly locked in right now, we can easily make it worse if we try.
  • FpUser 6y ago
    >"I'd agree that it's stalled, but moreso out of fear and ignorance than anything else." How about simple common sense instead of "fear and ignorance". I have a C++ monolith that serves me just fine already for years. The performance is great and I am able to rent dedicated servers that can serve at least 10 times more requests that I have at a price that is a tiny fraction of AWS for the same work. Why would I switch and incure more expenses? What's the ROI?
• shivam-dev 6y ago
  I see serverless working really well for a few niche tasks. Finite, stateless interactions that don't happen often. A good example will be a site say example.org that has a donate page. On form submit, a lambda can take the payload and create a subscription at a payment service like Stripe or Razorpay. The donate page at https://internetfreedom.in https://internetfreedom.in works the exact same way. The broader idea is a service (or static site even) sending messages to a different service. Given how popular no-code platforms are getting, tiny serverless pieces can help automate operations between these platforms.
• daxfohl 6y ago
  Caching is another big one. Beyond the simplest of services you typically need to cache some info in memory, create connection pools, etc at startup to improve latencies. With serverless that is not possible without killing your cold start time. So it's hard to go serverless except for the simplest of applications.
• politelemon 6y ago
  I'd point out two other aspect not mentioned here - first is that the complexity doesn't go away. Application architectures running on a 'serverless stack' have a lot more moving parts than a traditional server based equivalent. Try showing the you from 10 years ago a modern serverless architecture and they'll think you're mad. More moving parts is more maintenance/problems, but on the plus side, does allow you to throw more resources at a specific part of the whole. Second - with each cloud provider's serverless service, I've noticed that the underlying complexity is shifted into your application and provisioning. They're a great example of leaky abstractions. The name 'serverless' may lure you into thinking that you don't need to think about servers any more, but actually you do have to adjust to the way they've implemented a service that you're using. Think of Lambda cold starts, or have a look at the DynamoDB pricing page. There's still a server running somewhere. Personal experience: I've found that ECS (Fargate) is a decent step into the serverless realm, if you've been running normal containers on normal EC2s. It does take away the EC2 management aspects, and it's especially useful if you have some applications that are resource hungry, and some are not. It's a cheap way to run ETLs (we use the ECS Operator from Apache Airflow, which itself is on EC2). It doesn't take long to learn, and it's a good place to start. It does come with its own baggage... the 'stack' that you had on a single EC2 is now scattered about; you may need AWS Cloud Map for service discovery, ALBs for networking, SSM/KMS for secrets, Cloudwatch for logging. That's when you realize, those sticker infested laptops at Devops conferences are actually modern architecture diagrams.
  • ahallan 6y ago
    I agree. I only generally use Fargate with containers, and control with cron or with always on APIs, with Cloudwatch for monitoring, and it’s seems like a good midpoint between ec2 and serverless. The APIs cost a bit more a month (they’re on quite low cpu/memory) because they’re always on, but it minimises complexity and it’s nice to know that you can move those containers over to another platform if needed.
    • yellow_mixer 6y ago
      The increase in price is well worth it for our team to not have to manage any servers.
• cbono1 6y ago
  Most of these seem like fairly weak reasons at this point. Some degree of vendor lock-in is pretty much inevitable no matter what solution you go with. Limited programming languages may have been an issue a few years ago, but with the support of Java, Go, Python, Javascript to name a few - most of the core user bases are covered. Additionally, after the introduction of API gateway, most CRUD applications, including those that require async tasks, can be served by the lambda and serverless. After having used serverless for a while, the biggest turn off for using it (still) seems to be the performance issues. Provisioned concurrency, i.e leaving function containers running, is really just a bandaid and runs counter-intuitive to the original motivation of serverless to begin with.
• vr46 6y ago
  Serverless just moves complexity around and makes some things a bit more awkward, like debugging and logging. You have to be all in on the platform. I’ve just taken over a serverless app after the lead left and there are so many moving parts to make it all work. Not yet a fan.
• lovehashbrowns 6y ago
  I am still on the serverless high, and I don't see it going away any time soon. For the large corporation that I work for, things like soc2, patching, server maintenance, etc. are a giant pain every single month. The quicker we switch as many things as possible to serverless the better. One of the services I converted over went a year and a half with absolutely no attention from our engineers. It was great seeing how old the latest deploy was. Coupling serverless with terraform and git makes everything even easier. It means doing things like adding another lambda to an API as simple as copy and paste terraform, replace phrases in terraform, write code. terraform apply and done.
  • luhn 6y ago
    How do you use Terraform with Lambda? That's been one of the huge painpoints in my limited Lambda experience. All the CI tools (SAM, Serverless Framework, e.g.) seems to want to handle the IaaS part themselves and step on Terraform's toes. I just want to set everything up with Terraform and then have a nice simple tool to build and deploy the application.
    • lovehashbrowns 6y ago
      We use terraform and terragrunt by themselves to deploy lambdas. No frameworks. It's slightly more work, I guess. But deploying and understanding how deployments happen is easier this way. Plus, getting any kind of framework approved in a corporation is annoying as heck, whereas we already use terraform and terragrunt. https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/lambda_function https://registry.terraform.io/providers/hashicorp/aws/latest... The biggest annoyance is unit testing, although it forces certain good habits on us. So for example, since we don't use SAM, we have to do unit testing separately (our code is in Python). But because we can't exactly run a lambda via Python, we have to put most of our code in the layers that our lambdas import. So we run unit tests on the layers, and the positive is that we can essentially copy and paste the code that our lambdas would run into the unit tests. And then we can keep it DRY because almost all the code is in layers, and that incentivizes us to create generic functions that can be used across all of our lambdas. For things like unit testing DynamoDB, we use Moto which works exceptionally well. https://pypi.org/project/moto/ https://pypi.org/project/moto/ More detail: Our terraform has infrastructure code for: API Gateways Hard-coded API keys we use for testing DynamoDB tables IAM roles used by the Lambdas and Step Functions Lambdas themselves s3 buckets used for the Lambda zip files and state Step functions
• paxys 6y ago
  It's a valid opinion piece, but I don't see any numbers or facts in it that point to the stall of serverless. From what I can see in the industry services like Lambda are still very highly used and growing exponentially.
• ThinkBeat 6y ago
  Issues we had in our adopting it: I like the term "nano services" is it probably the wrong term. But I like it. We went monolith -> micro services -> micro services + nano services Everything that adds complexity in a micro service system, adds far more complexity with nano services. Debugging and tracing is a nightmare. And yes, logging, a lot of logging and instrumentation helps. But if you add too much of it then the whole point of the nano services is lost. Versioning can get complex, depending on your deploy model. Presumably if you push 100% of your nano services with every deploy you can get around it. We have about 600 nanoservices running on AWS now across 4 different systems. My advice, that nobody would ever ask for, keep AWS Lambda for certain special tasks where they are a very good fit. As always run the numbers, performance, cost to run, cost to maintain. Will the immense ability to scale really help your use case? In most of our cases, no, they will not. For some companies it will be a great solution and solve pain-points, save money
  • jacques_chester 6y ago
    I have no idea why this comment was downvoted, it seems perfectly reasonable to me.
• eecc 6y ago
  I guess serveless isn't any faster to debug than restarting a Tomcat locally once you factor in the cloud deployment dance and network latency. In fact, it's Websphere all over again...
• dublin 6y ago
  What the article author doesn't get: Serverless cloud platforms and APIs are the 21st century equivalent of OS APIs and libraries. They're still maturing, but the abstraction has moved up a level. Most people don't care (and fewer want to) what OS or other low-level stuff is running their code. Today, we're still too focused on what's going on inside the boxes - in the future, more people will realize that the important part that brings value is how the boxes are "plumbed" together. We're already seeing the beginnings of this with serious no-code/low-code platforms, which are ideally suited for these kinds of services environments. (Soon, they won't all be cloud-based, either...)
• mrkeen 6y ago
  I don't release software to the cloud without running it on my computer first. I'm attracted to 'serverless' about as much as I'm attracted to 'version-control-less' or 'testless'
• api 6y ago
  You mean the permanent AWS lock-in revolution?
  • holler 6y ago
    yes and no, the web app I'm working on at sqwok.im uses a proxy to point to a backend api that's built to be portable should the need ever arise (which I doubt would until it's in the status of "good problems to have"). it's true I would need to port the other bits outside the api that use native aws services. how often do people change their infrastructure once things are working and they move onto building out a platform? I definitely have gone back and forth on the lock-in thing, but I feel like we're always locked into _something_ at the end of the day and it's more important to get something that works and prove it out on the business end.
• tus88 6y ago
  LOL infoq. Srsly. > One of the advantages of serverless models is supposed to be that obscure, infrequently used programs can be utilized more cheaply, No-one: Literally no-one: Infoq: thinks serverless is all about obscure programs. > Vendor Lock Well try migrating a massive Java codebase to .NET or a deep Oracle application to Postrges. That's life. > Functions that have not been run on a particular platform before, or have not been run in while, take some time to initialize. Boo-hoo mah warm up time. Get over it already. > you (generally) can't run entire applications on severless systems. You aren't supposed to - serverless is for developing systems based around microservices, claiming they are intended to replace servers for running COTS products is a disgusting strawman. > Despite all these complaints, I'm not against serverless solutions per se. I promise. Promise away. I promise not to care.
  • einpoklum 6y ago
    Mostly agree, but: > Well try migrating a massive Java codebase to .NET Java is a language, and an ecosystem of associated technologies. That's not equivalent from switching from one cloud provider to another, or even to your own machines. The equivalent might be, say, maybe switching between JVM implementations.
• qaq 6y ago
  The serverless marketing revolution has stalled
• knodi 6y ago
  Serverless has an edge usage case and its not in the middle of your web requests. Due to the load on AWS regional lambda compute pool, now your have a 500-2000ms cold start to your lambdas or you can't use it for tools and services with long-lived TCP connections (hi redis). Good luck. Not for me
• Animats 6y ago
  Serverless computing refers to an architecture in which applications (or parts of applications) run on-demand within execution environments that are typically hosted remotely. Like CGI or FCGI programs! But with YAML! FCGI really is a "serverless" environment. Launches an application when called for. Starts more copies of the application if there are enough requests. Shuts down idle copies when not needed. Starts a fresh copy if one crashes. You can even scale with load balancers. Really, that's most of what you need to get work done.
  • qayxc 6y ago
    But you forgot that always-on server it lives on. The idea behind serverless includes the fact that you don't pay for what you don't use. So if no requests are served, you owe nothing. Your FCGI solution shuts down idle copies, but keeps the server running...
    • recursive 6y ago
      I don't really understand serverless, but if it's running a process in response to a request, then of course there's still a server, because something received that request. FCGI has a server running. And serverless has a server running, as long as its listening for requests.
      • jacobsenscott 6y ago
        The running server is a server you don't pay for.
        • recursive 6y ago
          So the truth is revealed. The real technology of serverless is an innovation in billing models.
      • codyb 6y ago
        Serverless architectures rely on some sort of gateway run by their cloud provider as their always on listener which spins up a process for your function when needed. Essentially it’s a collective pooling which is cheap enough that it can be offered for “free” to the entity creating a serverless workflow.
• croh 6y ago
  Many apps don't need scaling. For B2B, getting first 100 customers is a big deed per say. But app owners buy the cool aid of cloud vendors and make things complicated. Don't trade simplicity for scaling unless you REALLY need it.
• jasonhansel 6y ago
  Serverless computing has been around for a while; it used to be called "shared hosting with CGI." What's new is that it's become proprietary, instead of being based on open standards. This has made it hard to test serverless apps offline, and made it nearly impossible to move a serverless app from one cloud platform to another.
• OCISLY 6y ago
  major public cloud providers offer rather suboptimal pricing for serverless services
  • einpoklum 6y ago
    There are "public cloud" providers? I thought all major providers were private for-profit entities.
• Aeolun 6y ago
  Because it sucks. We’ve been working with serverless for 2 years now and we’re still dealing with issues for which the only solution appears to be to move back to ECS.
  • sabellito 6y ago
    Care to expand? You seem to be one of the few people on this comment section that has used it in production for a long time.
  • abraxas 6y ago
    Can you be more specific? I'm not being facetious, my company is embarking on this very path and I would like to hear what lies ahead.
  • Sohcahtoa82 6y ago
    It sounds to me like maybe serverless just wasn't the right solution to your problem.
• ChuckMcM 6y ago
  An interesting rant to be sure, but what the author misses (in my opinion of course) that serverless isn't new, it just isn't recognized by a lot of programmers for what it is. Serverless computing is exactly mainframe computing. And by exactly I mean exactly. You see when I was taking CS classes for my degree students bought something called "kilocoreseconds" (kCs) and they are exactly what they sound like, they are a unit measured in the combination of amount of RAM + the amount of compute per unit time your project consumed of the shared computing resource, the mainframe. You also got a quota of storage with which to hold your projects before you "launched" them on the mainframe with the all powerful "run" command :-). For those of us who liked to explore, it was a very real possibility that you would have to buy more kCs to get through the semester. There was vendor lock in because Doh! you weren't writing operating system code, you were writing application code. And once you make this connection, you can see all the problems that "serverless" has are all the exact same problems mainframes have for all of the same reasons. Basically mainframes are "good" when you want to have a small team do all the compute resource management and you have many teams that will want fractional usage of that resource over time. You can developed a closed form solution to the question "what does this compute resource cost to operate per unit time" and you minimize all of the things that affect that cost. Everyone maintaining it are all in one building, all of the equipment is in one room, all of the maintenance is logged and verifiable, etc. When do mainframes kind of suck? Well when you don't know whether or not you want to use them. Or when you have a different set of OS services you, and only you, need but burden every user of the mainframe. It is hilarious when you think about it, imagine this giant homogeneous blob of compute, the mainframe, that people disliked because it was "far away" and they didn't have any control, so desktop computers became a thing so that everyone could have their "own" computer, but then networks got bigger so people started virtualizing their desktop compters so IT departments started building bigger and bigger computers to hold many VMs and then because people figured out they could scale by using someone else servers, they started putting their VMs in data centers with a bunch of other company VMs and the data center people optimized by making bigger and bigger data centers, until even the lower cost of a VM was really more than someone wanted to pay for just running a single program so the Data Center types built a layer over all of their machines and services to make it seem like one giant machine. Ending up, nearly exactly back where they started except that now one company owns a mainframe and dozens of companies use it to run their bits of code. I literally laughed out loud when a low employee number senior engineer at Google proudly announced to the folks that Google was building this new concept of "Data center sized computers." This was like 12 years ago so I'm sure their vision has evolved but it never occurred to them (I checked) that maybe everything old was new again. But I still remember touring computer rooms that took up an entire floor of the building and were basically one computer. When you get this, you can then go look at where mainframe computers are today. Look at how the IBM Z series can slice and dice itself into logical partitions or LPARs and dynamically become a compute nexus of just the right size for your application, in either bare metal or OS based versions. That is where "serverless" should be looking for inspiration. Modern "web 2" architectures still partition various services into clusters. So you have the EC2 cluster, the S3 cluster, the Elastic Search cluster, Etc. Make the atoms in your world the pivot point and dynamically allocate resource based on your exact needs. Then bill it out in the gigacorepackethours or some other unit of measurement that captures what fraction of the overall datacenter your application consumed and for how long. Just don't bring back punched cards. They didn't really add value as far as I could tell.
• zmmmmm 6y ago
  Interestingly what ultimately sold me on a serverless deployment for one of our apps was security. When I compare the attack surface area of us deploying our own OS in the cloud vs just a handful of lambdas, it seems like a great way to let Amazon do the security work for us. If we were doing more in the cloud it may make sense for us to own that, but otherwise it would require us to spin up a whole set of dedicated devops just to maintain it and monitor it that we can avoid with serverless.
• mharroun 6y ago
  I guess this article completely ignores something like fargate which has none of the problems listed.
• pier25 6y ago
  There is a great misunderstanding as to what serverless actually is. So many people, including this article, equate serverless to cloud functions. There are plenty of services like Google Cloud Run or FaunaDB that are also serverless. IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed.
  • cwhiz 6y ago
    With that definition, wouldn’t something like beanstalk qualify? I think that definition is overly broad. However, you’re right in that it does make me wonder where the definition should start or end.
    • pier25 6y ago
      I've never used AWS Beanstalk but if it's like Heroku I don't think it qualifies as you are still provisioning infrastructure (much like with EC2).
      • cwhiz 6y ago
        It provisions EC2 for you, and scaled up or down. To really simply, it’s the basic equivalent to having an infrastructure admin turning EC2 instances on and off as load goes up or down.
    • different_sort 6y ago
      You're responsible for managing the server in beanstalk, but it's not far off. I suppose it's just an earlier generation of the same idea. WHat I mean is, beanstalk runs on EC2 instances that you are responsible to make sure are patched, configured correctly and have everything you need for your application to run. Fargate/Cloud Run are probably better serverless examples - you bring a container and config and the cloud provider will handle the rest.
  • dolni 6y ago
    > IMO what makes something serverless is that you don't need to provision or manage infrastructure, and also no need to worry about scaling as it will go up and down as needed. This is why serverless is such a stupid term to begin with, IMO. It's not even an accurate descriptor (the stuff is running on a server _somewhere_), so it really could mean anything. Something like "cloud functions" to describe Lambda and "managed Kubernetes" for Fargate. Of course, these terms are less sexy, so they'd never catch on.
• ashtonkem 6y ago
  Serverless has been a clear case of a solution looking for a problem, IMO. The vast majority of the software I’ve deployed in my career gets called a lot; deploying them onto a serverless platform would’ve increased our cost and maintenance burden significantly above simply dockerizing some web app. There are certainly use cases for the occasional script run, but that feels like more of job for some cron-like software, and also feels like a far cry from what serverless promised.
• kolanos 6y ago
  So many comments saying "Serverless just added complexity", then you read what they did and it's, "so I tried to move our entire infrastructure to Serverless and..." Umm, yeah? And did we mention there's still a server? Serverless is really not that complicated. But trying to plug a toaster into a super collider just might be.
• parsley27 6y ago
  The Serverless Revolution is still happening all around us, with products like Netlify and the new DO App platform, not to mention all the enterprises moving into the cloud and moving more of their systems into managed products, using serverless components to tie it all together. Serverless is part of many different mini-revolutions that have been going on for around the same amount of time, with micro services, rebalancing to have more processing on the client side, managed cloud services within private clouds, and the no-code/low-code movement. Some applications aren't meant for serverless; they need containers or even on-prem on occasion. But most applications are clients with some basic APIs, and many of those are being thrown up on Netlify and AWS and no one outside of the developers are really noticing.
  • eddiegroves 6y ago
    > DO App platform Can you expand this reference please, Google/Github search didn't give me any obvious results.
    • beoberha 6y ago
      DO == Digital Ocean
• jdmoreira 6y ago
  Only tangentially related but why haven’t Unikernels become a thing? why does every container need a unix userland? Sure, I understand people need their libc but all the other bloat? Why?
  • jacques_chester 6y ago
    I think unikernels were mostly crowded out by containers, because the latter was far more able to take advantage of path dependency. But as lightweight VMs become a more common form of "container", unikernels may into the limelight.
  • qayxc 6y ago
    Drivers are major pain with Unikernels - you basically need to rewrite all the drivers for your Unikernel; this gets especially painful with application accelerators and GPUs, since those cannot easily be replaced by virtual devices (like storage or networking). More importantly, app development is way harder since you don't have all OS libraries available to you and cannot easily benefit from previous R&D and workflows. You basically need to start from scratch or rewrite your app, which simply isn't always an option. There's currently no mature tooling that I'm aware of that would allow you to simply recompile existing apps to turn them into Unikernels (I just discovered Unikraft [1], but I cannot comment on whether it's any good). Edit: [1] http://www.unikraft.org http://www.unikraft.org Debugging is a pain as well compared to more standard development.
• orthecreedence 6y ago
  I love how we're going back to PHP's original model (effectively stateless "functions") and giving it a hot new name. People have tried to convince me (unsuccessfully) that this is entirely different. Somehow. If you really want serverless, install apache with mod_php and call it a day.
  • 8note 6y ago
    Ok, but do I have to update this host? Do I have to pay for it when it's not being used? How quickly can I quadruple my capacity?
    • bigphishy 6y ago
      No, no you don't, but you do have to study and learn many competing standards and syntax. These are liable to completely rewritten in 3 years from now, or else defunct and forgotten. If you already have a server somewhere you could consider spinning up a container instance or kubernetes ( assuming you have at least linux 1 server with excess ram available ) If you deploy your service on kubernetes than you should be able to scale effectively.
• grumple 6y ago
  My workplace uses a lot of serverless features on AWS - Lambdas, SWF, SQS, API gateway, as well as auto scaling instances on ec2/eb. Some of it’s nice. Most of it isn’t. Here are the pros: it’s great for quickly scaling up or down, and we don’t have to worry about physical infrastructure. Here are the cons: Documentation is inadequate. The docs are often verbose, but outdated or incomplete in critical ways. There also seem to be very few resources/blog posts about how to use big aws features. I suspect there is a secret cabal of infrastructure engineers that hoard this information. Replication of work is difficult. So much is done through the GUI. This seems really amateurish. How do you quickly capture the state of your entire aws configuration? How do you record and track changes? We have very little insights into our system. Every microservice is a snowflake. Why do I have to use this apache templating language for api gateway? Weird. Who designed these libraries? Why can’t I rip as much as I want out of a queue? Weird.
  • pugz 6y ago
    If you're doing anything through the GUI, that is absolutely problematic - for all the reasons you mention. You should be using CloudFormation or Terraform exclusively and configure nothing through the GUI. The Apache templating language is awful, no question.
• fizixer 6y ago
  There should be platform-independent abstraction that is not backed by the big three (AWS, GCP, Azure), and preferably neither by the less big N. That abstraction should allow you to develop serverful, and allow you to go serverless with minimal effort.
• blakeburch 6y ago
  As a data guy, I've have an entirely different perspective on serverless. While it may not work well for running entire parts of an application, it works great for building out and managing internal data pipelines. You don't want your pipelines crashing because your jobs overlapped and you ran out of memory/cpu on the servers you set up. You want each stage of the pipeline to run independently and scale as needed. In my eyes, the bigger problem with many FaaS products (which most equate with serverless) is the barrier to entry. The setup isn't very user friendly. The code doesn't "just work" like it does locally. Limitations on data size, runtime, etc. cause you to building workarounds in your scripts just to get them running. Not to mention that once you have it all set up, visibility into everything running is a nightmare and only available to the most technical users. Based on my experience, I'm currently building a [platform](https://www.shipyardapp.com https://www.shipyardapp.com) to try and make serverless data pipelines easier for teams to setup and manage. Would love to hear someone else's perspectives on serverless setups for data management. I know I'm not alone on these existing frustrations.
  • alexpetralia 6y ago
    Interesting, I have found AWS Lambda quite poor for data pipelines. Batch jobs can't exceed 15 minutes. Memory limit is 3GB. Payload sizes are 256kb max. If you are used to batch processing large amounts of data, Lambda seems to be the exact opposite of this. I think it is good for "small data, highly concurrent event processing" but this is a very different use case from batch processing data pipelines.
• CoffeeDregs 6y ago
  I'm not sure about the hater-ade in this article (old, dead languages?). I've built infrastructure for multiple companies on top of AWS Lambda. Usually bog-standard REST endpoints in Node or Python. There are a few weird bits and a few "huhs" (DB connection timeouts after a Lambda wakes up from sleep) but that's true of most systems. True, we were only doing a few req/s but Lambda was easy to setup/use and was mostly maintenance free. As is said so often on this site: it's a tool; use it for its intended purpose. Our development environment was very reasonable: Express or Django locally; aws-lambda->Express/Django on the lambda.
• imroot 6y ago
  The Serverless revolution has stalled...because it takes a long time for that service to start up, as it's so infrequently used. I'll see myself out.
• deleted 6y ago
  [deleted]
• alpb 6y ago
  Kind of also surprised I think this author has not heard of Google Cloud Run (https://cloud.run/ https://cloud.run/). Cloud Run employs a vendor-neutral container runtime and API (from Knative open source project). It simply accepts any OCI container that can listen on $PORT number. Similarly, the author talks about serverless not being able to run "entire applications", which again, doesn't apply to Cloud Run. Many people run fully-fledged .NET Core or Java apps on it with a single command to deploy. Ditto for the author's "Limited Programming Languages" point, Cloud Run is container-based serverless runtime and it runs any language. Furthermore, you don't even have to write Dockerfiles anymore to build containers for plenty of languages thanks to Buildpacks https://github.com/GoogleCloudPlatform/buildpacks https://github.com/GoogleCloudPlatform/buildpacks. Furthermore, in my opinion, the serverless revolution is still going on with more services adding edge lambdas support or storage support for edge workers like Cloudflare did with Durable Objects Beta or Workers KV and there's definitely more to come. Overall I'm not sure what the author was thinking while writing this. It seems they are aware of the intersection of containers & serverless and note that serverless is not just FaaS, but I note an intentional omission of many products that directly respond to his points in the article. Disclaimer: I work on Cloud Run.
  • emilsedgh 6y ago
    To me, Google Cloud Run is the sweet spot between Heroku and Serverless. I pay as much as serverless but there's no vendor lock in or specialized programming environments. Fantastic job. By the way are websockets ever going to be supported on managed cloud run?
    • jay_kyburz 6y ago
      When you say there is no vendor lock in, are there other companies that will host the container for you? Can I just deploy my container to three different places and choose where to point my URL? I'm right now faced with re-wiring a Python 2.7 App Engine App and feeling the pain of the lock in.
      • emilsedgh 6y ago
• peterwwillis 6y ago
  Serverless is the most overhyped cron job runner in history.
• manigandham 6y ago
  Serverless is really just a specialized niche of PaaS. Smaller lighter functionality akin more to scripts rather than full applications, with more billing and scaling flexibility, and typically leveraging other cloud services to get things done. Another big reason it's stalled is because PaaS has rapidly improved and now deploying a Docker container running whatever you want is just as fast and easy. No need for all the vendor lock-in, frameworks, complex environments and everything else when you can just package up a typical webapp and run it anywhere, even with the same billing (like GCP Cloud Run). In return you get a much better dev environment with all the existing tooling and best practices.
  • dijit 6y ago
    I tend to agree. This is not helped by the fact that cloud providers are approaching (and even in some cases surpassing) the complexity and price of running standard compute instances again. It can be a lot trickier to navigate the nuances of ECS+Lambda than it is to run standard EC2 instances. Even GCP is not immune, though I find it better in these areas, a common problem I have with cloud run for instance; is container instances which don't have permissions to talk to their linked/associated database, instead you have to instantiate a credentials file programatically inside the container.. which seems superfluous when you're the platform provider and you control both resources.
    • spankalee 6y ago
      Are you sure you don't have something misconfigured? By default Cloud Run services their project's GCE service account, which has permissions to everything in the project: https://cloud.google.com/run/docs/securing/service-identity https://cloud.google.com/run/docs/securing/service-identity I've never had to do anything special to access Firestore for instance.
  • jillesvangurp 6y ago
    Exactly, your software is still running on servers but you no longer worry about managing those. The problem with PAAS and serverless until recently is that they still required a lot of devops activity. Most of that is pure drudgery: setting up networking, dealing with vendor specific weird shit (e.g. amazon's IAM makes everything harder than necessary), micromanaging instance types and trading off overpriced vcpus vs small chunks of memory, etc. Lots of things that you can do wrong, lots of subtlety, lots of poorly documented gotchas, lots of potential bugs, etc. And all of that is needed so you can say "go run this over there" where this is your packaged up docker application and there is months of work by some poor devops person to turn a large amount of poorly integrated tools into a vaguely coherent deployment experience. It's never simple. It's never cheap I had a decent experience with Cloud Run recently. I was not in a mood or position to reserve 3 months out of my schedule to terraform myself a new server environment (which I actually know how to do). I already had the software and I wanted it running ASAP. So, I felt slightly dirty when I did this but got the job done in a few mouse clicks in their UI. This was shockingly easy after basically spending months piecing together arcane crap in AWS in my previous project. This got me a cloud run deployment, a build pipeline against my github repository for continuous deployment, and a running service. I tuned the build file afterwards to do more than just docker build & deploy but that was relatively easy (similar to how most CI systems work these days). They charge for cpu/memory used by requests. The whole thing has been running for a few months now. Less than 4 hours of work to figure it all out from me knowing absolutely nothing about Cloud Run to me having a service up and running. I reconfigured the deployment via the UI a couple of times to fiddle with memory and CPU settings. I suppose I could sit down and terraform this at some point but I don't feel the need to do that right now. I have more interesting things to do. And technically me spending a day to do that would cost more than running the whole thing has cost so far. That's the point: the cost of devops is out of wack with the running cost for a lot of this stuff.
• different_sort 6y ago
  "You Can't Run Entire Applications". I mean, what are we really calling serverless. Many serverless platforms, like fargate allow you to bring a container image, and whatever happens in that container image is non of fargate's business. I agree with many of the points made though, and admit I am writing this reply mostly because the ckick baity headline got me.
• rubyfan 6y ago
  Serverless is the new mainframe. In 10 years everyone will be complaining about their AWS being a mess or their lambdas costing too much. There will be consultants selling modernization to get onto whatever the newest thing is. What is old is new again.
• somurzakov 6y ago
  is there an alternative to Serverless using kubernetes? like a service that spins up a pod, checks out code from repo, runs the job and then shuts down the pod.
• wiremine 6y ago
  I've seen a few serverless projects that are really, really jacked up. 1000s of functions glued together with little intentional design... basically one big pile of spaghetti code. Things like the Serverless framework[1] help, but ultimately today's serverless architectures feel like they forgot Dijkstra's warning: that the "Go To Statement Considered Harmful." [2] I'm still big on the approach for the right use cases: variable work loads are a good example. But ultimately, to be truly useful, we need to see either a) better coupling with non-serverless approaches, or b) a "serverless 2.0" approach that builds in the good parts and fixes the bad parts. (But please don't call it serverless 2.0... those of us who lived through "Web 2.0" will thank you) [1] https://www.serverless.com/ https://www.serverless.com/ [2] https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.pdf https://homepages.cwi.nl/~storm/teaching/reader/Dijkstra68.p...
• deleted 6y ago
  [deleted]
• deleted 6y ago
  [deleted]
• sushshshsh 6y ago
  Can someone show me an application (other than a real time one) that can't be solved with simple javac my_script.java, tomcat, and a database of ones choosing? Dare I say that it might even be possible to run twitter at scale with just a simple NoSQL database and some scripts?
• xrd 6y ago
  I've read through a bunch of comments but don't see anything to answer this question. Is there a way to use one "serverless" framework in one place and then use another in another place? For example, I love dokku. It is so easy to have the heroku like experience on the cheap. But I wonder: what happens if I need to scale my application bigger than the dokku server it's on right now? I really like the immediate prototyping possibilities of dokku but the long term plan seems less exact when I read their documentation. So, is anyone else using dokku locally and Google Cloud Run globally? Or another combination? This is why I dislike firebase (maybe this has changed). It's incredibly powerful, magic. But, you have to go all in both locally and globally, and there were gaps that caused me a lot of pain. The tendency would be to use a framework that gives you the best of both worlds, local/dev plus production. But, why couldn't we use the best solution in one place and the other best solution in another. Is that a naive question?
  • csours 6y ago
    I think the answer is yes, but you have to figure it all out yourself.
    • xrd 6y ago
      That seems like an opportunity for a smart PM to build on an awesome development environment. I wish, for example, that the Google Cloud Run people would talk about that. They probably need to plan for world domination and have a roadmap that includes their own way of doing it, sadly.
• justinram11 6y ago
  As someone on a two-man-team who runs a lot of little "utility" functions in AWS Lambda with the Serverless Framework[1] to support our DevOps / Build processes, it's been one of the most productive tools in my toolkit (after the initial learning curve, of course). It allows me to stand up a practically maintenance-free endpoint in a matter of hours (usually to glue separate services together): * Want to run a quick ETL process to refresh some tables or pull some data down from a third-party endpoint? * Want to expose a quick usage report for the project manager? * Want to send a slack message when a build finishes from TeamCity so QA can jump on it? * Want to monitor the rate of Crashlytics logs and send a warning to slack if it breeches a threshold? There are tons of "one-off" little processes that now just automatically run and don't require server upkeep. Most of them are functionally independent, so having them as separate functions makes sense (when we do need to coordinate, that's done through Step Functions). Note: I still don't think that they are a great fit for production services (and more fits one-off and cron usage patterns) [1] https://www.serverless.com/ https://www.serverless.com/
  • Demiurge 6y ago
    How is owning an AWS account easier than a cheap dedicates server? You should have a code repo and backups in either case. At least some people mention "but I can scale this lambda x1000" and that's one advantage... But you can do all those tasks on a hetzner server in same amount of type, just python scripts.
    • justinram11 6y ago
      Mostly it's about the maintenance costs of owning and managing a server -- on Lambda most of these tools are "set and forget". I don't want to have to manage security updates, disk usage, or any of the other multiple things that come with owning a server. I also could probably debate on the friendly-ness of just dumping all of these one-off services onto a single server (seems like it could get messy pretty quick), but I think you could probably go either way on that. We are also an AWS shop for our "production" stack already, so there is no added overhead for owning an AWS account.
• mark242 6y ago
  Here's why I love serverless. I cannot tell you the number of times I have implemented "upload your photo and it'll get resized to (profile avatar size from design specs)". It's ridiculous, and it's one of those things that everyone burns time implementing their fun hook into Imagemagick. Now I have one lambda that gets pointed at a new record stream from an S3 bucket, and I'm done. I cannot tell you the number of times I have implemented "when this user signs up, send them a welcome email." It's one of those things where you construct your email, point it at your MTA, do a ton of configuration, then it may work. Now I have one lambda that gets pointed at a new record stream from Dynamo, which calls SES, and I'm done. I cannot tell you the number of times I have implemented "clear the Redis cache if a user changes their preferences". You write a clearUserCache hook into your DAO, or you paste it manually into your crud functions, and you always forget something, and six months down the line you start getting bug reports of people's zip code not updating, or something. Now I have one lambda that takes record streams from Dynamo, removes a key from Elasticache, and I'm done. It's not that you couldn't do this before serverless, of course you could and you still can. It's that it makes that level of code reuse that much simpler. You have all of these helper infrastructure functions that you implement for every single project you work on, and reusing that glue code is so, so much easier in Lambda/GCF/AF/etc.
  • anamexis 6y ago
    I don't know, it sounds like you've just implemented all of those things n+1 times.
    • ssutch3 6y ago
      And practically every web framework out there provides exactly this type of reusable functionality, not tied to a specific vendor.
    • jlokier 6y ago
      I think a lot is hidden inside "which calls SES" versus "point it at your MTA, do a ton of configuration, then it may work." Email is unfortunately a moving target. What worked before, gradually stops working as the big providers put up increasing obstacles to your own MTA doing a successful delivery. I've heard Amazon SES also has delivery problems so take with a pinch of salt. But I would hope they generally try to maintain it.
• tybit 6y ago
  I don’t believe that the FaaS revolution has stalled, though I fear it will follow the tech adoption curve because people are over hyping it. I do wonder if AWS’s leadership in the area has stalled though. GCP has innovated with their hybrid Cloud Run to allow running more traditional apps in a serverless way. Azure and CloudFlare have paved the way to what I believe is the future with stateful functions with Durable Functions and Durable Objects respectively. Meanwhile Lambda just seems to be gold plating it’s (admittedly great) but stale offering.
  • pbalau 6y ago
    > GCP has innovated with their hybrid Cloud Run to allow running more traditional apps in a serverless way. AWS has Fargate, run your containers without caring where they run.
    • tybit 6y ago
      This doesn’t automatically scale down to zero though which to me is a key differentiator of true serverless.
    • Simon321 6y ago
      it doesn't scale down to zero and the startup time is too long
• the__alchemist 6y ago
  "For those new to the term, a quick definition. Serverless computing refers to an architecture in which applications (or parts of applications) run on-demand within execution environments that are typically hosted remotely." That sounds like the opposite of serverless.
• bambam24 6y ago
  And of coyrse, The article is written by a guy who have all his github repos language in Java
• quickthrower2 6y ago
  > The Serverless Revolution Has Stalled Netlify, cloudflare, vercel, hasura, heroku, firebase and indeed aws and azure may have something to say about that!
• joana035 6y ago
  Can't wait for the codeless revolution! :)
• morcutt 6y ago
  We've been using full Serverless for the past year with Serverless framework little to no issues. Sure, a single server would be a little bit quicker but that is my only major complaint.
• tomc1985 6y ago
  Call me old school but I wouldn't trust a web programmer that doesn't know server stuff.
• cdnsteve 6y ago
  I don't agree to the authors points. Serverless is another tool in your belt, do you still need to make decisions with tradeoffs? Yes. Do the big 3 support most languages you need? Yes. Is vendor lock in real? Maybe but how many companies actually move cloud providers often, or ever? Most companies I know are still trying to get into the cloud. You can't run full applications in serverless? That's not the use case, again with decisions you need to make.
• keithwhor 6y ago
  Ah. I've been on the road all day and caught this thread too late. The reason that the "Serverless Revolution" appears to have stalled is that the customers who have the most to gain from serverless technologies have the least ability to recognize that the technologies they're using are actually serverless. Nor do they care. In its most reductive form, "serverless" just means "SaaS." And Shopify store owners, for example, don't care about how many servers they run -- they care about how many snowboards they can sell. They could maintain one, twenty, or twenty thousand, or zero -- if the cost to run these things and provide value on top is abstracted away by a few tools it doesn't really matter. So you can use i.e. AWS Lambda to solve their problems, or you could sell ShopifyStoreManagerPlus but they don't care what it's called. They just care that they sold more snowboards. So "serverless" stalled because the target audience doesn't actually care about the implementation, so the smart companies selling "serverless" solutions all dropped the lingo. AWS Lambda is just another tool in the toolchain; an engine and crankshaft instead of a horseless carriage.
• nojvek 6y ago
  When you run a k8s cluster on an auto scaling nodepool on a cloud provider, is that considered serverless? At the end of the day it’s either your hard metal server or someone else’s servers (cloud) It’s then just layers of abstraction to see what is a good fit.
  • aikah 6y ago
    > When you run a k8s cluster on an auto scaling nodepool on a cloud provider, is that considered serverless? 'Serverless' is about billing model therefore purely a marketing concern. It's the very definition of a buzzword, like 'cloud'.
• pabs3 6y ago
  Is it possible to run Serverless on-prem with open source tools?
  • daxfohl 6y ago
    Azure Functions has an open-source runtime including autoscaling: https://docs.microsoft.com/en-us/azure/azure-functions/functions-kubernetes-keda https://docs.microsoft.com/en-us/azure/azure-functions/funct... IDK about the others.
• maxcbc 6y ago
  A fifth reason it has stalled, cost. For constantly running applications it can be cheaper just to run a server. This fact has been used to avoid migrating to serverless by a lot of orgs i’ve worked with, even when it doesn’t apply to their use case.
  • deleted 6y ago
    [deleted]
• doggydogs94 6y ago
  I trace serverless computing back 10 more years, back to the mid-1990s. One example of this would be Citrix published applications.
• m12k 6y ago
  Overall isn't serverless just a cost optimization for intermittent compute workloads? That's handy, sure, but I also figure that costly workloads like that are rare enough that it's obvious why the "revolution" would stop well before conquering the whole cloud market.
• 0x008 6y ago
  I find that this is such a bold claim, when the original study cited only states that 63% of respondents did not plan to deploy any microserve-based architectures in the upcoming years. However, 37% do. That is a LOT. And there is not a single data point relating to the years prior, so a claim that the "revolution has stalled" is actually impossible to make, because we do not know if there ever was one.
  • ashtonkem 6y ago
    Micro services are one of the most thorny naming issues in CS. What exactly do you mean by “micro services”? The breadth of definitions for that specific term means that by some counts, there is basically no company in the world that doesn’t deploy some micro services, or there are basically no companies that do. Depends on who you ask.
• pjmlp 6y ago
  Naturally, eventually everyone just realized how they were doing rebranded CGI.
• Kiro 6y ago
  I've been wanting to try Laravel Vapor for a while: https://vapor.laravel.com/ https://vapor.laravel.com/ It feels like serverless done right. You just deploy your regular Laravel app and don't need any special tooling while developing. Has anyone tried it?
• randomsearch 6y ago
  This advantage: “Serverless models don’t require users to maintain their own operating systems, or even to build applications that are compatible with particular OSs. Instead, developers can produce generic code, and then upload it to the serverless framework, and watch it run.” ... is utterly compelling and is why serverless will not just win, but leave renting a server a tiny niche market that few developers will have an experience of post 2030. Maintaining your own server is completely nuts. If that isn’t obvious now, it will be in another decade. It’s massively inefficient. Like running your own power plant to serve your factory, except you also have to worry about security and constant maintenance, along with all the moving parts that surround a server. Almost all the objections in the article can be rephrased as “serverless is not mature enough yet”, and that’s accurate, but I suspect there’s also a bias against giving up control to the cloud companies, and some wishful thinking as a result. The future of software development is going to be defined by cloud providers. They’re going to define the language ecosystem, the canonical architectures for apps etc... it’s just early days and cloud is really very primitive. Just clicking around Azure or GC or AWS illustrates how piecemeal everything is. But they have a lot to do, and just keeping pace with growth is probably hard enough. I’m not sure I’m super happy with this outcome, but I’m pretty certain the trend line is unmissable.
  • nathias 6y ago
    How about someone else is controlling your infrastructure and your project completely depends on their good will. We need self-hosted serverless...
    • davedx 6y ago
      Self hosted serverless has also been around for years. Lookup openshift, openwhisk, etc. TFA is clickbait
      • nathias 6y ago
        I mean as the main paradigm of hosting, now its beyond niche and everyone is happy to go to google, amazon and microsoft. What does TFA mean?
• madsbuch 6y ago
  What serverless does is to force the developer to have a sharp separation of code and persistence. For all cases. Even saving a small inter-request variable that lives for 5 seconds or less. What serverless does is to force scalable architectures. The price is slim to no control over build and execution environment as a consequence of not taking the underlying architecture into account. For many people this is not an issue. These people will be very content with serverless and should definitely use these types of solutions.
• asim 6y ago
  Serverless conceptually was too tightly bound to the function as a service model. As we peel that back what we're finding is serverless really means "not my server". Someone else manages that piece of infrastructure, it can be anything, a VM, a database, etc. But in this case it feels like serverless is falling squarely into the PaaS category, building a better Heroku. Google Cloud Run is one prime example. DigitalOcean App Platform is another. I think this is likely the primary way software gets run in the cloud in the future BUT with one huge caveat, its not clear its going to be the way forward for large scale development itself. Cloud lacks what mobile lacked before the iPhone, a development model. When we finally figure that out, it'll become obvious that table stakes here is an actual full end to end experience with one language and a set of primitives to help scale development for the cloud. That's not FaaS. Its something entirely new. The language will be popular, maybe Go, the focus will be on cloud APIs. Everything else will be become a client. The web era is over, thats not what the cloud is about. Cloud is all about APIs.
• OriPekelman 6y ago
  I'd agree with the part of maintaining your own server. like personal one. I promised myself like 5 years ago I'll never be my own (and family and friends..) sysadmin ever again. ... but serverless needless mean tiny programs in nodejs. serverless is basically a super category for what we used to call PaaS simply saying the granularity of what you deploy can be smaller. it doesn't mean it has to be smaller. as far as I am concerned it can also be way bigger than what heroku represents. This is what composability on infrastructure means. It means you have the same interface to deploy a single line of JS... and a service that is itself composed of a couple of monoliths each with its own data backend. The "form of the program" should be dominated by the problem it solves not its deployment target. That is the thing we are trying to achieve at platform.sh where I run product. A uniform interface to a composable infrastructure. We are not quite yet there... this is not a trivial problem. And I don't think that "just ship your machine" Docker style solves this. To be really composable you need both finer grain and higher abstractions. What I mean is that at every level you compose you need to be able to define dependencies (my function requires this version of nodejs and this system lib) my already composed monolith that includes a dependency on MySql and Redis) is a dependency of this static site builder.. at each layer the semantics are very close. But not the same. Just shipping a container eludes these issues and basically reproduces the model of "good old servers" in a way this is contrary to what true serverless has to offer. Which is absolutely not caring at all about the runtime. And caring only about the design of your system such as that it espouses best the form of your problem.
• louiskottmann 6y ago
  Serverless is not so shiny when compared to a cloud-managed Kubernetes cluster. I get to deploy stuff "the regular way", that is with a constantly running application, I don't have to re-train my developers, I have extra power in the cluster should I need it, I don't depend on a cloud provider in particular, and my costs are bounded. Cherry on top: I don't maintain the infrastructure either, there isn't even a SSH daemon running.
• that_guy_iain 6y ago
  I recently ran into a scenario where using serverless caused a cascading failure. We have database searches that are executed directly via AWS lambdas. When we sent too many queries in too short of a time that took down the database and which then took down other things. (The fact multiple things are connected to this database is another thing to solve.) While the database was down the lambdas were still sending more and more requests. If this was a standard service the standard service would have became overloaded very quickly, allowing the database to remain up but at a degraded performance and the only service that would have been down would have been the one that was getting too many queries. Instead, everything was effected. I've came to the realisation that if your lambda requires something else to operate, lambda is probably not a good solution.
• pimeys 6y ago
  The problem what I see with serverless, is if you need to store your state into a database, the classic relational systems will not scale well to the problem. pbBouncer[0] in transaction mode tries to solve the problem of limited connections by giving a connection from the pool to a transaction. This has a limitation of not being able to reuse statements; e.g. they have to be deleted before the transaction is released, adding an extra roundtrip for the queries. It also means you must wrap every request into a transaction, if planning to use statements. Otherwise the solution is to sanitize all your values and concatenate a single SQL query. It has the big risks of SQL injections and is against all best practices, but this is what Active Record is doing to solve the issue, and I guess it works for them quite well. pgBouncer has also the statement mode. Here you can't use transactions and with that, no prepared statements either. So you must then just use the text protocol of the database and concatenate the parameters to your query. Amazon has the RDS, and I haven't looked into it that much yet. What I kind of think I know about it, is it pins the connections when using statements. Meaning, when pinned, the connection is for one client and cannot be reused until disconnected. MySQL has the serverless-mysql package[1], which is a client side library killing of stale connections and disconnecting as fast as possible when done. So, basically during the request, it reads the system tables and tries to drop the connections from other sessions. I haven't tried this either, but more I think about it, it really doesn't feel like a good strategy at all. For one, you need a root access to the database for every client, and then you need to modify the state of other connections from the clients. There could be a bug in the client library, that is quite nasty to find and can cause really hard-to-fix issues. Then the last thing is of course the locking of traditional relational databases. They don't scale to massive concurrency that well; the MVCC chokes when running with many parallel queries[2]. So you need a distributed system, something that can have locking mechanisms that can scale to tens of thousands of sudden connections when the serverless system gets a request peak. Hopefully something with a stateless connection. If somebody knows a system that can do this, I'd like to hear about it. [0]: https://www.pgbouncer.org/ https://www.pgbouncer.org/ [1]: https://www.npmjs.com/package/serverless-mysql https://www.npmjs.com/package/serverless-mysql [2]: https://15721.courses.cs.cmu.edu/spring2019/papers/02-transactions/p209-yu.pdf https://15721.courses.cs.cmu.edu/spring2019/papers/02-transa...
• lootsauce 6y ago
  I have taken to using AWS Lambda via serverless framework for much of my api needs and for more expensive ongoing work I like AWS lightsail and expose services only within the vpc that get accessed by apis and step functions.
• nicbou 6y ago
  I don't buy into serverless. I went to a webdev convention, and it ended up being a serverless hype train. Industry experts with a financial incentive to promote serverless went on stage and told me they can't debug their code, or run it on their machine. They showed me comically large system diagrams for very simple use cases, then spent an hour explaining how to do not-quite-ACID transactions. Oh yeah and you can only use 3-5 languages, and each import statement has a dollar amount tied to it. More importantly, all those skills you develop are tied to Amazon, or some other giant. All the code you write is at their mercy. Any problem you have depends on their support. Am I supposed to bet hundreds or thousands of man hours on that?
  • sippingjippers 6y ago
    AWS in particular seem to have a carefully refined technical sales/certification/advocacy channel whose main product is those fucking stupid architecture diagrams. Hello world service with $4000/mo. worth of geo-replicated backing databases, CloudWatch alarms, API Gateway instances, WAF etc. But don't let it encourage you to think serverless has no value, or it can't be done portably or cheaply. It has its sweet spots just like everything else.
    • diggan 6y ago
      Reminds of something that was on the HN frontpage some month ago, where readers are not sure if it's a parody or not, because of the architecture you're required to deploy yourself to use this new "Perspective" product. Direct link to the architecture, that in the end serves the use case of generating a diagram of your AWS resources: https://d1.awsstatic.com/Solutions/Solutions%20Category%20Template%20Draft/Solution%20Architecture%20Diagrams/aws-perspective-architecture-diagram.f67026185e4f02d2d623289fa714d69d2c1f7af6.png https://d1.awsstatic.com/Solutions/Solutions%20Category%20Te... https://aws.amazon.com/solutions/implementations/aws-perspective/ https://aws.amazon.com/solutions/implementations/aws-perspec... https://news.ycombinator.com/item?id=24552779 https://news.ycombinator.com/item?id=24552779 (regarding costs, this setup ends up being +$500/month, again, to draw graphs of your architecture https://twitter.com/der_rehan/status/1308242717307174912 https://twitter.com/der_rehan/status/1308242717307174912)
• baq 6y ago
  we've done serverless in the dark ages of web programming back when perl was the fashionable hacker language and a buzzword. it was called 'cgi scripts'. it's amazing how a simple rebranding can do to a technology.
• nicexe 6y ago
  I'm working with a different type of serverless approach. For a few hackathons now my team tries to push a client-side frontend + smart-contracts on a blockchain as a backend solution. This has a UX hit (some downsides of it could be mitigated though) but it made our business logic easier to implement. Depending on the project it has additional benefits to go with this stack. This cannot be applied to every project though and usually the UX hit or the lack of private transactions is enough to favor more traditional stacks.
• Spearchucker 6y ago
  I've lived through the genesis of the modern internet, the move from command-line to GUI, dot-matrix, Java's birth, smartphones, .Net's birth, AMPS and GSM, the iPod, NTSC, all the web tech from JavaScript, CSS, MongoDb, Bitcoin, JQuery, Node, to agile, modern JS libraries and of course serverless, and countless others. The result of it all is cynicism. Serverless takes a lot of work to learn and get good at. The benefit is negligible - no more than deploying a "serverless" thing to an existing web server we use for cross-cuting concerns like exception handling, logging and communication. 10 seconds of automated configuration management, another 10 to deploy. The Change Approval Board meeting to rubber stamp the deployment takes longer. The breathless hype machine has and always will be just that - hype. Someone's "new, improved, OMG I found this you must use it now" perspective is a pattern that's older than Gartner's hype cycle (which in itself has no basis in fact). It works well in the startup world, but has virtually no place in a business-critical environment, let alone healthcare, defence, telcos or similar. Little wonder it's adoption has stalled.
• miohtama 6y ago
  There is a reasons why cgi-bin was not successful and app frameworks took over. For the same reasons serverless works well only in a limited scope of applications. For most use cases it is more headache than benefits.
• davewritescode 6y ago
  My company tried really hard to make serverless work on a new part of the platform we rolled out. Our cloud team and management drank the AWS koolaide on serverless and went 100% all in for all new use cases implemented in this particular platform. It was probably one of the biggest mistakes in the history of the company because doing serverless right is at least as much work and running workloads on well-managed servers (which we have). Management won't resource it appropriately because the whole point of higher costs in serverless is to eliminate Ops budget in the first place. As for running actual code, many types of workloads currently do not map to serverless at all and you won't find out until you hit the limits. Anything that needs to read in a lot of data from a file or do a lot of in memory computations are a lot less efficient or impossible in Lambda given the memory constraints. If any single invocation of your lambda needs more than the alloted memory, it'll just fail and you'll either need to implement some heuristics based routing to the different lambdas (same code with the appropriate amount of memory) or you'll just eat cost on every lambda invocation. You'll find you end up doing things like re-writing lambdas from Python into Go to make it easier to fit more in memory. How is that not insane? Although it's not 100% true anymore, at the time serverless development was often easiest using SAM which ties you directly to AWS CloudFormation which is the biggest mistake any company can make. CloudFormation is easily the worst thing that AWS has ever created. It's fine for infrastructure with lower rates of change but for applications it's an absolute nightmare to the point where it comes up in every sprint retro on some of our teams. I /won't even go into how crappy testing is. It's a complete afterthought and it shows. That team has started moving towards ECS/Kubernetes and even running Docker containers directly on EC2 instances in some cases because it's actually saving them time over futzing with Lambda and it's enabling them to do more faster.
• bregma 6y ago
  So, "serverless" is a marketing concept in which you pay for a server? I can't wait for my manager to be sold on the idea of "functionless" computing. Maybe the revolution has stalled because the emperor in charge has no clothes?
• jimwalsh 6y ago
  This whole article reads like the person that wrote it owns a datacenter and/or develops monolithic apps still.
• goosyloosy 6y ago
  In my view, the serverless revolution is stalled because of lack of interoperability with other more complex application architectures. Serverless is IMO best suited as something available in-addition-to other more complex application architectures for a limited but growing set of use-cases. The current architectures I've seen make the "we <3 serverless" folks go all-in on it and then regret their decision and walk back to using services / docker / Kubernetes, or even a Heroku style PaaS for more power and flexibility.
• pierrebai 6y ago
  One of the fundamental problem of serverless is intimately tied to its very selling point: that your code is run on interchangeable servers. What that leads to is that everyone's code runs on any server. The requires strict inter-server security, authorization and roles. On a normal server, you can run multiple processes (DB, front-end, back-end, etc) and rely on the fact they're running on the same server to not having to design roles and auth. In serverless, you need to manage roles and auths for everything. You see the same issues for data pipes, triggers and queues.
• miguelmota 6y ago
  The biggest drawback for me which the article didn’t really touch on was cost. For high volumes of traffic AWS Lambda is way more expensive than an EC2 server.
• Tehchops 6y ago
  It feels like, to me, that most of the comments in this thread that don't "get" serverless have never had to deal with things like maintaining the spaghetti mess of CM(Chef/Puppet/Ansible) that invariably results from trying to manage a traditional infrastructure deployment of any size. Patching, dependencies, configuration drift, security audits/compliance... these are all non-trivial issues requiring non-trivial operations and engineering hours to solve. It's fine if Lambda is too complex an abstraction for hobby code or a node.js todo-list app, but that doesn't mean it doesn't solve the right problems in the right problem spaces.
• tutfbhuf 6y ago
  I think we need bare-metal serverless, same like we have bare-metal clouds. For that we need something like kubernetes but for serverless environments instead of containers.
• smoyer 6y ago
  > Is This a New Idea? I haven't seen it noted in the discussion below but there's an earlier incarnation of the so-called serverless architecture. Early mainframes could be leased outright or you could buy time on them, in some cases on an ad-hoc basis for one-time batch workloads.
• Attained 6y ago
  I like serverless because it scales to zero easily by default which keeps costs down for super low use personal apps.
• luord 6y ago
  While I believe that the serverless hype is mostly, well, hype, this article makes some odd points against it. > One is to optimize your functions for whichever cloud-native language your serverless platform runs on, but this somewhat undermines the claim that these platforms are "agile." Like this one, don't see how optimizing for a specific language makes something less agile. Then again, "agile" means so many things in the field that I might just be misinterpreting.
• tonfreed 6y ago
  Personally I love serverless, but this article definitely mirrors my own experience. In two jobs now I've been told to do things "serverless first" and both times I've ended up with an ECS solution. My reason always boils down to the other tooling, particularly in regards to HTTP endpoints. AWS API gateway is an absolutely infuriating product. My current thoughts are if you're working in the AWS ecosystem, with AWS tools, Lambda works fantastically. Using Lambdas to set off alarms and run playbooks has never let me down, and I've done a lot of data processing hanging lambdas off streams and it just works. Really well in fact. Where it falls over is interacting with the outside world in a sane fashion. HTTP endpoints are a nightmare to set up and deploy in a semi-automated fashion, I've had things that matched what was in the docs that just don't work because of some random gotcha, the undocumented silliness around a "HTTP API Gateway" vs a "REST API Gateway" is another mind bogglingly frustrating thing. Not to mention all the latency issues I've had, which are far too many to blame on a cold boot of the lambda. Serverless has its niche and it works really well, and real cheaply to boot. But it's not a generalised tool like the loudest evangelists like to pretend it is.
• bribri 6y ago
  You don't need to patch container vulnerabilities with serverless
• anthony_barker 6y ago
  Mainframes were often maintained by IBM on site and clients charged for MIPS. Not so different and this is from the 70s/80s
• neop1x 6y ago
  Why is it even called serverless? Of course it will end up running on a Linux-powered server...
• vizually 6y ago
  Serverless is great or it sucks are extreme viewpoints. Reality is somewhere in the middle. For some specific use cases, (image manipulation, Alexa skills, etc.) serverless is fantastic. Dealing with persistent storage and DBs is challenging. But continues to evolve. Managing server fleets and keeping them patched is no small feat. How much of the productivity can we gain if we didn't have to do all that with serverless? It's not possible for all use cases today. But can we move from say less than 5% of the use cases today to say, 40-50% of the use cases in another 5 years?