9 ms·

The hidden costs of serverless

176 points by dfirment 9y ago

alexnewman 9y ago
Just don't use SQL databases. Lambda will knock over your DB
- misframer 9y ago
  Probably not the case with Serverless Aurora! https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-serverless/ https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-...
- rwol 9y ago
  Could you expand on this? I’m trying to learn more about using Lambda as a serverless REST API recently and one of my projects has a SQL DB.
  - drb91 9y ago
    I am not sure to what the op was referring, but I’d make sure to plex your connections through a configured connection pool to ensure the highly liquid lambda compute doesn’t suffocate the database.
    - alexnewman 9y ago
      Yea can i do 10k requests/second . The example was 80 connections per second. What happens when lambda has tens of thousands of workers?
  - alexnewman 9y ago
    What happens if you get 1M requests. How many dB connections is this?
    - bdcravens 9y ago
      What would you do in a traditional architecture?
      - alexnewman 9y ago
        pgpool
  - rmrfrmrf 9y ago
    Traditionally, a web application creates a group of always-on reusable connections (a pool) to a database server since setting up the connection takes time and each connection uses up resources on the database server that could otherwise be used for computation. If there are more connections to your API that require the database than there are connections in the pool, those requests are queued and handled when the next connection is freed. These connections are then closed when the app shuts down. The problem on Lambda is that you can’t persist any application state beyond the function call itself, so you can’t take advantage of connection pooling the way you normally would in a self-contained webapp. Without some kind of middleman, each database call will require you to open a new connection to the database and close it when the function ends. This becomes catastrophic for the database server as the number of requests scales up.
    - mrep 9y ago
      Yes you can. You are supposed to instantiate those connections outside the function call as per the docs. Example: https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deployment-pkg.html https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deploym...
      - alexnewman 9y ago
        Tried and failed
    - jdchernofsky 9y ago
      http://blog.spotinst.com/2017/11/19/best-practices-serverless-connection-pooling-database/ http://blog.spotinst.com/2017/11/19/best-practices-serverles...
- teej 9y ago
  It’s easy to knock over anything with bursty Lambda loads. I have successfully maxed out AWS Redis, kinesis, kinesis streams, and S3 with massively parallel Lambda work. One of the things that I haven’t figured out is if there’s a sane and simple way to implement backpressure on Lambdas.
duncan_bayne 9y ago
> Like the jump from on-premises to the cloud, the move to Serverless is more or less inevitable. Speaking as a fan of AWS: neither of those is in any way inevitable.
dfirment 9y ago
There are more costs to Serverless than just CPU and RAM — and for many users, the additional cost categories of API Requests, Storage and Networking will be the major cost drivers.
pbreit 9y ago
Is server less really as inevitable as the move to cloud? The extra moving parts don’t seem worth it for garden variety crud app so far imo.
- convolvatron 9y ago
  the extra moving parts aren't...but I think the point was to remove the existing moving parts (installing and maintaining a server instance). they just got it wrong. it would save everyone a lot of time and energy to not have to deal with server instances, so its likely a better model will come along. persistent storage in the presence of scaling and concurrency is a bit of thorn though.
  - bamboozled 9y ago
    That's the thing though, how hard is it to manage a VM in 2018? If you're using Terraform + modern config management tools I find it a breeze. I feel like this is a weak argument. If developers are unable to understand how something like Salt, Chef or Ansible works then I'd be surprised.
    - convolvatron 9y ago
      its not that people cant understand [salt, chef, ansible, terraform], its just a non-trivial amount of human effort, error, and upkeep just to say 'run my program'. kind of a shame that every shop has to have one or a few devops people on hand to do that. I guess it mostly stings when there is a critical openssl update, or something analogous. Despite the ideal of continuous integration and lightweight deployment - none of the shops I've worked at lately can make than happen in the 10 minutes its supposed to take.
      - bamboozled 9y ago
        With all due respect, I think it’s laziness. Most of the good soft ens I know spend the one - two hours or so it takes to get familiar with these systems.
    - 9y ago
na85 9y ago
"Serverless" is a silly name because there are of course still servers. Peer-to-peer architectures could perhaps charitably be called "serverless", but I digress. To me it sounds like this whole "serverless revolution" is just the product of Amazon's PR team who found a nice term to befuddle and bedazzle know-nothing CEOs.
- ceejayoz 9y ago
  Look, at some point, my "wireless" internet involves wires, but I don't really have to worry about managing them, so it's wireless in the ways that matter to me.
  - na85 9y ago
    That's a fair point, but wireless internet is a different mode of delivery to your house, whereas "serverless" is just adding a layer of abstraction, and I don't really think that these things are analogous.
- drb91 9y ago
  Well, you’re also completely ignoring many tradeoffs. For instance, it is cheaper to use 10k concurrent lambda invocations than it is to spin up the equivalent ec2 instances. There’s also the dev time allocated to maintainint the server infrastructure itself. Serverless may be a disingenuous term, but it does refer to a useful thing.
- taneq 9y ago
  Yep. The great marvelous internet fad reinvention machine has just managed to find a new name for "web hosting".
- rmrfrmrf 9y ago
  “And in other news, the ops team is deferring Debian 8 upgrades until Q3”
- ams6110 9y ago
  I agree. "Cloud Functions" or "FaaS" (Functions as a Service) or something along those lines would be a better and more descriptive name.
anfilt 9y ago
What is old is new again! Whoo-hoo. Regardless it's still not server-less... The entire system is still running off a server...
- balls187 9y ago
  Which you do not manage in any way shape or form, nor do you have the ability to.
  - anfilt 9y ago
    I am not saying any thing is wrong with that. I am saying it still runs on a server... So server-less is a misnomer.
    - rmrfrmrf 9y ago
      Are you familiar with the term “abstraction”?
    - cwyers 9y ago
      Do you think that there are actual daemons in your computer? If you have to kill a process, do you only do so in self-defense?
      - anfilt 9y ago
        Very funny. No, but what if I called a virtual machine CPU-less. Bad name? I would say that is. Also treating long running task as a little demon performing a task is more allegorical same with killing a process. I am not sure I would call it being server-less allegorical.
- eridius 9y ago
  You're confusing abstraction with implementation. The architecture is serverless. The implementation is running on a server. But the whole point is the users don't have to worry about the implementation, just the architecture.
bluepeter 9y ago
> Cold starts. This isn’t the time to dive in deep, but it’s a main reason why some companies decided against going Serverless. Cold starts as an issue? I mean, all you have to do is create a CloudWatch event (or cron if you want an explicit server involved) to fire the Lambda function every few minutes and you're all good. Sure, if you get heavy traffic, I suppose you could have multiple containers running simultaneously? But that's also easy enough to handle w/ CW events.
- jrs95 9y ago
  At that point, if you’re running it all the time anyways, why not just have something like an auto scaling Kubernetes cluster?
  - CharlesW 9y ago
    Because the cost and level-of-effort difference between those two options isn't comparable. Firing a function in a way that keeps it awake but uses no perceptible resources is simple and basically free.
    - jrs95 9y ago
      I wasn’t super familiar with the pricing, this makes sense.
- mslate 9y ago
  Wow, sounds easy--almost as if it should be that way out of the box...
  - dasil003 9y ago
    The economics don't work out if they keep them all hot all the time.
    - hliyan 9y ago
      Woot can't they give a simple Boolean seeing for a slightly higher price: "always up"?
nwmcsween 9y ago
Serverless sort of got taken over by people trying to push PaaS subscriptions. A real serverless architecture would be something like IPFS and CRDTs
- kitotik 9y ago
  When you think of it that way, in practice it really is the exact opposite of the “Serverless” buzzword - it’s 100% definitely absolutely requiring a persistent centralized remote server. Decentralized solutions 100% definitely absolutely do not.
soulnothing 9y ago
My current work project is trying to switch to a primary serverless architecture. I'm trying to fight it but know I'm going to lose. I don't have any problem with "serverless". Years ago I wrote a nginx handler that routed to .py files and ran them inside an lxc container, while at a hosting company. Fronted via haproxy, and documented with sphinx automatically. My problem is the hidden costs. Sure lambda requests are low cost. But what about API gateway, dynamo/rds access. Then I'm writing a basic crud app. Low-performance low request rate, noncritical. There is this additional complexity, that just isn't necessary. Every day at my job I'm thinking to myself it doesn't need to be this difficult. My usual route is django, django admin, and django rest. With an haproxy in front for load balancing. Dead simple and easy to work with. It's passe sure, but KISS. The alternative here is an api and a frontend. Several more projects to maintain. Tuning the projects to meet lambda size requirements/standards. The return on investment is minimal to me. If you can't automate managing a fleet of containers or vps instances then why're you here? The vendor lock-in, is insane to me. You're pretty much at the beck and whim of the provider. They raise the prices, what're you going to do. You either go with the price increase or do a rewrite. As I was sitting in these architecture meetings on moving too lambda. I was hearing several new packages/repos. New CI/CD, and configuration to maintain. During the meeting I scratched out a POC using EC2, Load Balancer, RDS and django to do what they were saying with half the code. But nope gotta be lambda.
- ceejayoz 9y ago
  > They raise the prices, what're you going to do. In the 11 year history of AWS, I don't think they've ever increased prices for anything. I'm pretty comfortable with their ability to avoid it in the future.
  - deleted 9y ago
    [deleted]
  - hueving 9y ago
    An 11 year history is hardly worth betting what could be the future of your company on. Especially for something just slightly more convenient than what can be built in-house.
jeswin 9y ago
I wish people are upfront about conflict of interest while writing articles like this. The author is the CEO of spotinst, which is listed in the last table as 2x-10x cheaper than any of the other FaaS options. The article is basically marketing copy devoid of technical details.
- carterehsmith 9y ago
  True. If the article is about someone promoting their business/product/solution, maybe it should be a "Show HN".
- keithwhor 9y ago
  This isn't a conflict of interest. It's developer marketing. A Cloud Guru, the publisher, is a company that sells developer education / training - should they have disclaimers explaining that they make money by selling education before every blog post or comic they put out? Amiram is providing important contextual advice for developers, PMs and executives, and has the added benefit of having a real product in market that will solve these problems for you. Most of HN is thinly veiled marketing supporting special interests. I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? That seems a bit silly to me.
  - TomBombadildoze 9y ago
    > This isn't a conflict of interest. It's developer marketing. > The article is basically marketing copy devoid of technical details. So since you agree with OP that it's marketing, _perhaps_ it's not a stretch to suggest that it's a bit shady for the CEO of Super Cheap Cloud Product to author a marketing piece decrying the hidden costs of OMG So Expensive Cloud Products as though it's just helpful advice? > I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? Apples and oranges. There's a big difference between "check out this thing I made" and "these products all have somewhat opaque problems _by the way I'm CEO of a competitor_".
candiodari 9y ago
The hidden cost of all cloud based software. Even the cheapest cloud (seems to be Google at the moment) is 5x or more of the price of an equivalent dedicated server (2x for "compute", >20x for bandwidth, so 5x is somewhat average. And that's compared to "normal" dedi providers. Ok to use Leaseweb, Hetzner and OVH ? Make it 10x more expensive). Since VPS's exist cloud doesn't even make sense for the smallest websites anymore. Ironically VPS's predate and are even the basis of cloud systems. And there's the intangible technical debt that cloud imparts. Whichever cloud you pick, in the future you'll change. That's how the world works. Switching dedicated service providers is a complicated ops problem. Switching cloud providers is a full rewrite of everything AND a complicated ops problem. Just being on the cloud, by itself, forces you to put in serious technical debt. I don't understand, even after using cloud at work, what those cloud systems provide that can't be done, better, cheaper, and with less relying on a single organisation, on dedicated service providers. I mean Google's hypervisor is good (very good), but it still imparts significant costs compared to bare metal.
- bamboozled 9y ago
  It's fashionable to use cloud services and people don't really have to know how to use configuration management tools, or know almost anything about operating system their software runs on. What more could you want besides paying 5x more for the privilege ? It's just outsourcing. Edit: I wanted to add that from what I've seen recently. "Engineers" who aren't familiar with how the various layers of the OSI model work and know a little about operating systems seem to struggle to build useful, secure solutions at higher levels which function at scale. Ultimately, we're still writing code to run on Von Neuman computers.
  - throwaway2048 9y ago
    except its not outsourcing, not really, you still need a strong understanding of what you are doing at all levels, hardware and software for any kind of serious setup.
    - bamboozled 9y ago
methodin 9y ago
Just as with anything it's evaluated on a case-by-case basis. Serverless is GREAT at starting something, testing it and then evaluating if it's even worth spending time to work on actual server-based stuff. You can get stuff going immediately with little effort without the overhead of setting up a box, managing deps and all the nuances that come up standing up classic servers (even in the cloud). Is it a silver bullet? No, though I'd say it might be for fleshing out ideas.
keithwhor 9y ago
It's interesting, because as the Serverless space evolves there are two emerging sales and marketing tracks for the technology: (A) This will reduce your costs (CIO Track) (B) This will reduce your time to market (PM / Developer Track) Amiram's article here clearly tries to deconstruct the argument in (A) and suggest, well, it's more expensive than you think (and Spotinst is the cheapest option - kudos to Amiram and team) which... is undeniably true, and API Gateway is a large part of that. It seems based on Re:invent 2017 in November that Amazon is moving to target the (B) track more aggressively, which is where we've been residing in a niche with StdLib since we launched [0]. Realistically I think both tracks are actually half-truths (as is all marketing), as Amiram even touches on re: lines of code written to maintain Serverless architecture. At the end of the day, Serverless technology is going to open up a world Simon Wardley [1] has painted a picture of: one of reliable, fault-tolerant, self-healing, predictably priced service composition that can be performed by developers who are increasingly unaware of implementation details, and perhaps not even developers in the traditional sense. It's been a neat exercise at StdLib trying to find the intersection between current development paradigms (old hat monoliths, etc.), the utility / lower cost / lower time to delivery of serverless tech, and the future of emergent, unexplored markets. As the marketing sizzle of "serverless" begins to fade (it hasn't peaked yet, but it will), and we see more challenges to the technology itself, it will be interesting to see what business practices and development paradigms pop up around serverless architectures, and how companies begin maximizing the utility of a new development canvas. One day it won't be "serverless," it will simply be best practice for most companies to ship application logic directly to the runtime layer. What does that world look like, where will costs (/prices) settle, and how do all players in the market continue delivering the most value to developers and companies? It'll be neat to watch it all play out, to say the least. [0] https://stdlib.com/ https://stdlib.com/ [1] http://blog.gardeviance.org/2016/11/why-fuss-about-serverless.html http://blog.gardeviance.org/2016/11/why-fuss-about-serverles...
drdrey 9y ago
I'm curious about the linear lines of code growth -- has anybody acually experienced that? What is causing it?
- shortj 9y ago
  There's an interesting side effect I've seen that a serverless approach enables, which is that it is now much easier to logically separate your various routes and logic to "route handlers" or "services". However, if you naturally extend your system with these logically separated handlers in a vacuum, which is easy to do, and you have not thought through your packaging and dependency management, you can quickly fall into a pattern of producing a lot of duplicate boilerplate and utility functionality that a monolith would have avoided. Basically, take all the pain points and downsides of SOA and make it really easy to make all the mistakes. That said, when approached with foresight, it's a perfectly manageable problem and I wouldn't agree that it is linear.
- clintonb 9y ago
  I don't buy the author's conclusion. I've deployed both Python and Node.js projects to AWS Lambda. I used Zappa (https://www.zappa.io/ https://www.zappa.io/) and Claudia.js (https://claudiajs.com/ https://claudiajs.com/) to deploy them, and only added minimal configuration to my codebase. If LOC is growing in the manner described, something is very wrong with the team's methods of configuration/deployment.
denkmoon 9y ago
"You will save time: No more [...] thinking about how your application will scale up or down" What a dangerous thought.
galaxyLogic 9y ago
I think serverless basically just means sharing more with other customers. You don't juts share the same hardware running your own VM on it, you share the same VM executing a big program one part of which is your lambda-functions. This leads to better utilization of hardware resources. It's not about a cloud vs. inhouse you might have the lambdas of your different departments running in the same VM. "serverless" really means "shared program".
fuball63 9y ago
API gateway costs on AWS seems like a massive "gotcha", especially considering how access via HTTP is super important for those worried about vendor lock in. This article was written by someone with a competing service, but I know there are a bunch of projects right now (including mine) that come out of the box with HTTPS, run generic/vendor-agnostic containers, and can even be self hosted. Self hosted seems to offer the best of both worlds; FAAS with fine grained control over platform costs, at the cost of the devops work to setup and maintain.

176 points by dfirment 9y ago

alexnewman 9y ago

Just don't use SQL databases. Lambda will knock over your DB

misframer 9y ago
Probably not the case with Serverless Aurora! https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-serverless/ https://aws.amazon.com/blogs/aws/in-the-works-amazon-aurora-...
rwol 9y ago
Could you expand on this? I’m trying to learn more about using Lambda as a serverless REST API recently and one of my projects has a SQL DB.
- drb91 9y ago
  I am not sure to what the op was referring, but I’d make sure to plex your connections through a configured connection pool to ensure the highly liquid lambda compute doesn’t suffocate the database.
  - alexnewman 9y ago
    Yea can i do 10k requests/second . The example was 80 connections per second. What happens when lambda has tens of thousands of workers?
- alexnewman 9y ago
  What happens if you get 1M requests. How many dB connections is this?
  - bdcravens 9y ago
    What would you do in a traditional architecture?
    - alexnewman 9y ago
      pgpool
- rmrfrmrf 9y ago
  Traditionally, a web application creates a group of always-on reusable connections (a pool) to a database server since setting up the connection takes time and each connection uses up resources on the database server that could otherwise be used for computation. If there are more connections to your API that require the database than there are connections in the pool, those requests are queued and handled when the next connection is freed. These connections are then closed when the app shuts down. The problem on Lambda is that you can’t persist any application state beyond the function call itself, so you can’t take advantage of connection pooling the way you normally would in a self-contained webapp. Without some kind of middleman, each database call will require you to open a new connection to the database and close it when the function ends. This becomes catastrophic for the database server as the number of requests scales up.
  - mrep 9y ago
    Yes you can. You are supposed to instantiate those connections outside the function call as per the docs. Example: https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deployment-pkg.html https://docs.aws.amazon.com/lambda/latest/dg/vpc-rds-deploym...
    - alexnewman 9y ago
      Tried and failed
  - jdchernofsky 9y ago
    http://blog.spotinst.com/2017/11/19/best-practices-serverless-connection-pooling-database/ http://blog.spotinst.com/2017/11/19/best-practices-serverles...
teej 9y ago
It’s easy to knock over anything with bursty Lambda loads. I have successfully maxed out AWS Redis, kinesis, kinesis streams, and S3 with massively parallel Lambda work. One of the things that I haven’t figured out is if there’s a sane and simple way to implement backpressure on Lambdas.

duncan_bayne 9y ago

> Like the jump from on-premises to the cloud, the move to Serverless is more or less inevitable. Speaking as a fan of AWS: neither of those is in any way inevitable.

dfirment 9y ago

There are more costs to Serverless than just CPU and RAM — and for many users, the additional cost categories of API Requests, Storage and Networking will be the major cost drivers.

pbreit 9y ago

Is server less really as inevitable as the move to cloud? The extra moving parts don’t seem worth it for garden variety crud app so far imo.

convolvatron 9y ago
the extra moving parts aren't...but I think the point was to remove the existing moving parts (installing and maintaining a server instance). they just got it wrong. it would save everyone a lot of time and energy to not have to deal with server instances, so its likely a better model will come along. persistent storage in the presence of scaling and concurrency is a bit of thorn though.
- bamboozled 9y ago
  That's the thing though, how hard is it to manage a VM in 2018? If you're using Terraform + modern config management tools I find it a breeze. I feel like this is a weak argument. If developers are unable to understand how something like Salt, Chef or Ansible works then I'd be surprised.
  - convolvatron 9y ago
    its not that people cant understand [salt, chef, ansible, terraform], its just a non-trivial amount of human effort, error, and upkeep just to say 'run my program'. kind of a shame that every shop has to have one or a few devops people on hand to do that. I guess it mostly stings when there is a critical openssl update, or something analogous. Despite the ideal of continuous integration and lightweight deployment - none of the shops I've worked at lately can make than happen in the 10 minutes its supposed to take.
    - bamboozled 9y ago
      With all due respect, I think it’s laziness. Most of the good soft ens I know spend the one - two hours or so it takes to get familiar with these systems.
  - 9y ago

na85 9y ago

"Serverless" is a silly name because there are of course still servers. Peer-to-peer architectures could perhaps charitably be called "serverless", but I digress. To me it sounds like this whole "serverless revolution" is just the product of Amazon's PR team who found a nice term to befuddle and bedazzle know-nothing CEOs.

ceejayoz 9y ago
Look, at some point, my "wireless" internet involves wires, but I don't really have to worry about managing them, so it's wireless in the ways that matter to me.
- na85 9y ago
  That's a fair point, but wireless internet is a different mode of delivery to your house, whereas "serverless" is just adding a layer of abstraction, and I don't really think that these things are analogous.
drb91 9y ago
Well, you’re also completely ignoring many tradeoffs. For instance, it is cheaper to use 10k concurrent lambda invocations than it is to spin up the equivalent ec2 instances. There’s also the dev time allocated to maintainint the server infrastructure itself. Serverless may be a disingenuous term, but it does refer to a useful thing.
taneq 9y ago
Yep. The great marvelous internet fad reinvention machine has just managed to find a new name for "web hosting".
rmrfrmrf 9y ago
“And in other news, the ops team is deferring Debian 8 upgrades until Q3”
ams6110 9y ago
I agree. "Cloud Functions" or "FaaS" (Functions as a Service) or something along those lines would be a better and more descriptive name.

anfilt 9y ago

What is old is new again! Whoo-hoo. Regardless it's still not server-less... The entire system is still running off a server...

balls187 9y ago
Which you do not manage in any way shape or form, nor do you have the ability to.
- anfilt 9y ago
  I am not saying any thing is wrong with that. I am saying it still runs on a server... So server-less is a misnomer.
  - rmrfrmrf 9y ago
    Are you familiar with the term “abstraction”?
  - cwyers 9y ago
    Do you think that there are actual daemons in your computer? If you have to kill a process, do you only do so in self-defense?
    - anfilt 9y ago
      Very funny. No, but what if I called a virtual machine CPU-less. Bad name? I would say that is. Also treating long running task as a little demon performing a task is more allegorical same with killing a process. I am not sure I would call it being server-less allegorical.
eridius 9y ago
You're confusing abstraction with implementation. The architecture is serverless. The implementation is running on a server. But the whole point is the users don't have to worry about the implementation, just the architecture.

bluepeter 9y ago

> Cold starts. This isn’t the time to dive in deep, but it’s a main reason why some companies decided against going Serverless. Cold starts as an issue? I mean, all you have to do is create a CloudWatch event (or cron if you want an explicit server involved) to fire the Lambda function every few minutes and you're all good. Sure, if you get heavy traffic, I suppose you could have multiple containers running simultaneously? But that's also easy enough to handle w/ CW events.

jrs95 9y ago
At that point, if you’re running it all the time anyways, why not just have something like an auto scaling Kubernetes cluster?
- CharlesW 9y ago
  Because the cost and level-of-effort difference between those two options isn't comparable. Firing a function in a way that keeps it awake but uses no perceptible resources is simple and basically free.
  - jrs95 9y ago
    I wasn’t super familiar with the pricing, this makes sense.
mslate 9y ago
Wow, sounds easy--almost as if it should be that way out of the box...
- dasil003 9y ago
  The economics don't work out if they keep them all hot all the time.
  - hliyan 9y ago
    Woot can't they give a simple Boolean seeing for a slightly higher price: "always up"?

nwmcsween 9y ago

Serverless sort of got taken over by people trying to push PaaS subscriptions. A real serverless architecture would be something like IPFS and CRDTs

kitotik 9y ago
When you think of it that way, in practice it really is the exact opposite of the “Serverless” buzzword - it’s 100% definitely absolutely requiring a persistent centralized remote server. Decentralized solutions 100% definitely absolutely do not.

soulnothing 9y ago

My current work project is trying to switch to a primary serverless architecture. I'm trying to fight it but know I'm going to lose. I don't have any problem with "serverless". Years ago I wrote a nginx handler that routed to .py files and ran them inside an lxc container, while at a hosting company. Fronted via haproxy, and documented with sphinx automatically. My problem is the hidden costs. Sure lambda requests are low cost. But what about API gateway, dynamo/rds access. Then I'm writing a basic crud app. Low-performance low request rate, noncritical. There is this additional complexity, that just isn't necessary. Every day at my job I'm thinking to myself it doesn't need to be this difficult. My usual route is django, django admin, and django rest. With an haproxy in front for load balancing. Dead simple and easy to work with. It's passe sure, but KISS. The alternative here is an api and a frontend. Several more projects to maintain. Tuning the projects to meet lambda size requirements/standards. The return on investment is minimal to me. If you can't automate managing a fleet of containers or vps instances then why're you here? The vendor lock-in, is insane to me. You're pretty much at the beck and whim of the provider. They raise the prices, what're you going to do. You either go with the price increase or do a rewrite. As I was sitting in these architecture meetings on moving too lambda. I was hearing several new packages/repos. New CI/CD, and configuration to maintain. During the meeting I scratched out a POC using EC2, Load Balancer, RDS and django to do what they were saying with half the code. But nope gotta be lambda.

ceejayoz 9y ago
> They raise the prices, what're you going to do. In the 11 year history of AWS, I don't think they've ever increased prices for anything. I'm pretty comfortable with their ability to avoid it in the future.
- deleted 9y ago
  [deleted]
- hueving 9y ago
  An 11 year history is hardly worth betting what could be the future of your company on. Especially for something just slightly more convenient than what can be built in-house.

jeswin 9y ago

I wish people are upfront about conflict of interest while writing articles like this. The author is the CEO of spotinst, which is listed in the last table as 2x-10x cheaper than any of the other FaaS options. The article is basically marketing copy devoid of technical details.

carterehsmith 9y ago
True. If the article is about someone promoting their business/product/solution, maybe it should be a "Show HN".
keithwhor 9y ago
This isn't a conflict of interest. It's developer marketing. A Cloud Guru, the publisher, is a company that sells developer education / training - should they have disclaimers explaining that they make money by selling education before every blog post or comic they put out? Amiram is providing important contextual advice for developers, PMs and executives, and has the added benefit of having a real product in market that will solve these problems for you. Most of HN is thinly veiled marketing supporting special interests. I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? That seems a bit silly to me.
- TomBombadildoze 9y ago
  > This isn't a conflict of interest. It's developer marketing. > The article is basically marketing copy devoid of technical details. So since you agree with OP that it's marketing, _perhaps_ it's not a stretch to suggest that it's a bit shady for the CEO of Super Cheap Cloud Product to author a marketing piece decrying the hidden costs of OMG So Expensive Cloud Products as though it's just helpful advice? > I think a huge part of the value of HN is lowering the barrier to entry to build great companies by providing a platform to announce and promote your product / team / etc. as well as educate people with quality content. We celebrate "Launch HN" and funding events, and are going to criticize a founder for building something awesome and talking about it? Apples and oranges. There's a big difference between "check out this thing I made" and "these products all have somewhat opaque problems _by the way I'm CEO of a competitor_".

candiodari 9y ago

The hidden cost of all cloud based software. Even the cheapest cloud (seems to be Google at the moment) is 5x or more of the price of an equivalent dedicated server (2x for "compute", >20x for bandwidth, so 5x is somewhat average. And that's compared to "normal" dedi providers. Ok to use Leaseweb, Hetzner and OVH ? Make it 10x more expensive). Since VPS's exist cloud doesn't even make sense for the smallest websites anymore. Ironically VPS's predate and are even the basis of cloud systems. And there's the intangible technical debt that cloud imparts. Whichever cloud you pick, in the future you'll change. That's how the world works. Switching dedicated service providers is a complicated ops problem. Switching cloud providers is a full rewrite of everything AND a complicated ops problem. Just being on the cloud, by itself, forces you to put in serious technical debt. I don't understand, even after using cloud at work, what those cloud systems provide that can't be done, better, cheaper, and with less relying on a single organisation, on dedicated service providers. I mean Google's hypervisor is good (very good), but it still imparts significant costs compared to bare metal.

bamboozled 9y ago
It's fashionable to use cloud services and people don't really have to know how to use configuration management tools, or know almost anything about operating system their software runs on. What more could you want besides paying 5x more for the privilege ? It's just outsourcing. Edit: I wanted to add that from what I've seen recently. "Engineers" who aren't familiar with how the various layers of the OSI model work and know a little about operating systems seem to struggle to build useful, secure solutions at higher levels which function at scale. Ultimately, we're still writing code to run on Von Neuman computers.
- throwaway2048 9y ago
  except its not outsourcing, not really, you still need a strong understanding of what you are doing at all levels, hardware and software for any kind of serious setup.
  - bamboozled 9y ago

methodin 9y ago

Just as with anything it's evaluated on a case-by-case basis. Serverless is GREAT at starting something, testing it and then evaluating if it's even worth spending time to work on actual server-based stuff. You can get stuff going immediately with little effort without the overhead of setting up a box, managing deps and all the nuances that come up standing up classic servers (even in the cloud). Is it a silver bullet? No, though I'd say it might be for fleshing out ideas.

keithwhor 9y ago

It's interesting, because as the Serverless space evolves there are two emerging sales and marketing tracks for the technology: (A) This will reduce your costs (CIO Track) (B) This will reduce your time to market (PM / Developer Track) Amiram's article here clearly tries to deconstruct the argument in (A) and suggest, well, it's more expensive than you think (and Spotinst is the cheapest option - kudos to Amiram and team) which... is undeniably true, and API Gateway is a large part of that. It seems based on Re:invent 2017 in November that Amazon is moving to target the (B) track more aggressively, which is where we've been residing in a niche with StdLib since we launched [0]. Realistically I think both tracks are actually half-truths (as is all marketing), as Amiram even touches on re: lines of code written to maintain Serverless architecture. At the end of the day, Serverless technology is going to open up a world Simon Wardley [1] has painted a picture of: one of reliable, fault-tolerant, self-healing, predictably priced service composition that can be performed by developers who are increasingly unaware of implementation details, and perhaps not even developers in the traditional sense. It's been a neat exercise at StdLib trying to find the intersection between current development paradigms (old hat monoliths, etc.), the utility / lower cost / lower time to delivery of serverless tech, and the future of emergent, unexplored markets. As the marketing sizzle of "serverless" begins to fade (it hasn't peaked yet, but it will), and we see more challenges to the technology itself, it will be interesting to see what business practices and development paradigms pop up around serverless architectures, and how companies begin maximizing the utility of a new development canvas. One day it won't be "serverless," it will simply be best practice for most companies to ship application logic directly to the runtime layer. What does that world look like, where will costs (/prices) settle, and how do all players in the market continue delivering the most value to developers and companies? It'll be neat to watch it all play out, to say the least. [0] https://stdlib.com/ https://stdlib.com/ [1] http://blog.gardeviance.org/2016/11/why-fuss-about-serverless.html http://blog.gardeviance.org/2016/11/why-fuss-about-serverles...

drdrey 9y ago

I'm curious about the linear lines of code growth -- has anybody acually experienced that? What is causing it?

shortj 9y ago
There's an interesting side effect I've seen that a serverless approach enables, which is that it is now much easier to logically separate your various routes and logic to "route handlers" or "services". However, if you naturally extend your system with these logically separated handlers in a vacuum, which is easy to do, and you have not thought through your packaging and dependency management, you can quickly fall into a pattern of producing a lot of duplicate boilerplate and utility functionality that a monolith would have avoided. Basically, take all the pain points and downsides of SOA and make it really easy to make all the mistakes. That said, when approached with foresight, it's a perfectly manageable problem and I wouldn't agree that it is linear.
clintonb 9y ago
I don't buy the author's conclusion. I've deployed both Python and Node.js projects to AWS Lambda. I used Zappa (https://www.zappa.io/ https://www.zappa.io/) and Claudia.js (https://claudiajs.com/ https://claudiajs.com/) to deploy them, and only added minimal configuration to my codebase. If LOC is growing in the manner described, something is very wrong with the team's methods of configuration/deployment.

denkmoon 9y ago

"You will save time: No more [...] thinking about how your application will scale up or down" What a dangerous thought.

galaxyLogic 9y ago

I think serverless basically just means sharing more with other customers. You don't juts share the same hardware running your own VM on it, you share the same VM executing a big program one part of which is your lambda-functions. This leads to better utilization of hardware resources. It's not about a cloud vs. inhouse you might have the lambdas of your different departments running in the same VM. "serverless" really means "shared program".

fuball63 9y ago

API gateway costs on AWS seems like a massive "gotcha", especially considering how access via HTTP is super important for those worried about vendor lock in. This article was written by someone with a competing service, but I know there are a bunch of projects right now (including mine) that come out of the box with HTTPS, run generic/vendor-agnostic containers, and can even be self hosted. Self hosted seems to offer the best of both worlds; FAAS with fine grained control over platform costs, at the cost of the devops work to setup and maintain.