In the company I work I see a big trend on trying to move things to AZ Functions or AWS Lambda but I don’t really get why someone would do that. It seems to me like a waste of money.
First part is billing model. You pay per request instead of per server. Say you have a server that can do 100 request/s. But you’re actually only doing 2. You’re overpaying by 50x if you pay for a server. At a small scale this difference is huge, as you grow it converges though.
But really, most application developers don’t care, and don’t want to care, about the underlying servers. Figuring out how autoscaling works, or keeping the kernel up to date. Individually none of these things are that hard, but there’s a bunch of time that adds up. Time that could be spent adding features that make money.
There is still a lot of marketing hype around it. Things like infinitely scalable fall apart when you have connection limits on a db and lambda doesn’t support pooling. Aws pushes it because it gives them extra flexibility - doubling the density of functions is probably easier than instances.
I don’t think the current form of api gateway + lambda is the final state, but something more like fargate, where you get a whole container and no time limit, is really interesting. Or we can all just go back to heroku.
I haven't used heroku for a year, my impression then was that Salesforce wasn't putting much energy into it.
Or is it more spritely now?
Also is there a new no-configuration server option now? Specifically where you can have a postgres database, background tasks, and a decent sized community?
There are a big class of web apps that this was a perfect fit for. (And where managing a Kubernetes cluster is too much work)
yea, heroku was kinda a joke as i haven't really heard anything about it since salesforce. it just seems like heroku was a bit ahead of its time - people were really wary about not owning their servers when it came out
There's a few reasons. For one, it's the new shiny thing and developers are always chasing that dragon. More importantly though, it's a good fit for some workloads so it actually makes sense sometimes which fuels the hype train. Finally, it fits in with the service architecture trends.
Just write your business logic in a function, they do the rest. Who has time to build a boring backend these days? First of all it’s boring, you already know how your app looks like and what data you want to display on your screen, but still, you need to install a server, configure your environment, blablabla, hire backend folks, hire more expensive backend leads to scale. At the end of the day all you need is something that returns a simple response in a string format (for example). It is scale-as-a-service / build-a-better-user-experience. That’s the main concept of Serverless.
At the company I work for we push it a lot for scheduled jobs that maybe run once a week since it saves money on teams just standing up an EC2 instance to run that cronjob once. It also is helpful for a lot of APIs and other use cases where I may not use it everyday and only need to hit the API once or twice in a certain period of time.
I'm not sure about obsessed but at the very least Lambda can be much cheaper than a full host for occasional, but heavy tasks, and it takes care of the associated administration for you.
Basically, in some situations, serverless can be more efficient with everyone's hardware and money, which seems like a win.
Doing "Operations" can be hard for some people to understand, and harder still to actually get right. Going "serverless" gives you the opportunity to outsource a lot of that work to someone else.
However, "serverless" also comes with a heavy price to pay in terms of debugging your code. It works perfectly (more or less), assuming you can actually write perfect code. But can anyone in this world actually write perfect code?
The bigger and more complex your code base, the more difficult it will be to debug it, and the more difficult it will be to get it to work correctly in a "serverless" environment.
For some people, going "serverless" will make a lot of sense for them. Just like some people do fine with WordPress so that all they have to do is type out their content and outsource all the hard work for publishing a web site based on that content.
But you will also pay a higher and higher monetary cost for going "serverless", as you scale up. At some point, it will no longer make sense to outsource that to someone else, and you will want to bring that in-house.
Do you understand how locks work? Or plumbing? If you need to replace or rekey the lock on your front door, can you do that yourself? Or do you outsource that to a Locksmith? If you need to replace your toilet, can you do that yourself or do you outsource that to a plumber? What if your A/C unit goes out? What if your car breaks down?
There are going to be some things that some people are good at doing, and they're good enough at doing it themselves that they don't want or need to outsource that work to someone else.
And then there are going to be some things that those same people probably are not good at doing, and those should be done by someone else -- either outsourced, or someone else in-house who works in partnership with you.
Imagine you have some kind of SaaS that customers pay for with microtransactions.
You do some kind of work on uploaded data (let's say it's 1GB) and return data to the customer.
The classic model forces you to make all kinds of upfront costs and predictions about usage. If you decide to support 10000 concurrent users you would need to provision a 10 terabytes of storage with high speed disks and maybe 10 beefy machines. Without actually having any revenue you need to invest at least $20k.
In the serverless model, you can calculate how much it would cost.
> 1GB upload + 120 seconds of 2G serverless time + 1 GB download = $0.15
Now you charge the customer $0.25 for your work and you make a neat $0.10 profit per task. If you have a lot of customers you make more profit, if you have no customers it costs you nothing. (except your development time, but that is not unique to serverless)
Because ops is overhead in terms of dollars, time, and mental capacity. It’s a pain the get good people, especially after the hype cycle of “devops” this decade making every junior IT admin aspiring to it in terms of labels but not skillset due to comp differentials.
To do it right you need people on call, round the clock team, etc. in the end serverless is one of those things that if you can get away with it and chase product market fit while spending a little more on opex while keeping headcount costs down its a no brainer.
It’s not without risk because of course not every problem lends itself to the architecture, it’s very hyped at the moment, many engineers hate it because it’s inelegant/leads to lock in/is different/etc so culturally that’s going to be a minefield if you’re not starting from nothing.
15 comments
[ 2.9 ms ] story [ 49.4 ms ] threadMany of my coworkers got extremely excited about it right after re:invent...
But really, most application developers don’t care, and don’t want to care, about the underlying servers. Figuring out how autoscaling works, or keeping the kernel up to date. Individually none of these things are that hard, but there’s a bunch of time that adds up. Time that could be spent adding features that make money.
There is still a lot of marketing hype around it. Things like infinitely scalable fall apart when you have connection limits on a db and lambda doesn’t support pooling. Aws pushes it because it gives them extra flexibility - doubling the density of functions is probably easier than instances.
I don’t think the current form of api gateway + lambda is the final state, but something more like fargate, where you get a whole container and no time limit, is really interesting. Or we can all just go back to heroku.
Or is it more spritely now?
Also is there a new no-configuration server option now? Specifically where you can have a postgres database, background tasks, and a decent sized community?
There are a big class of web apps that this was a perfect fit for. (And where managing a Kubernetes cluster is too much work)
Basically, in some situations, serverless can be more efficient with everyone's hardware and money, which seems like a win.
Cost reduction in parallel is a type of tactic; lending exists. I don't know your job.
However, "serverless" also comes with a heavy price to pay in terms of debugging your code. It works perfectly (more or less), assuming you can actually write perfect code. But can anyone in this world actually write perfect code?
The bigger and more complex your code base, the more difficult it will be to debug it, and the more difficult it will be to get it to work correctly in a "serverless" environment.
For some people, going "serverless" will make a lot of sense for them. Just like some people do fine with WordPress so that all they have to do is type out their content and outsource all the hard work for publishing a web site based on that content.
But you will also pay a higher and higher monetary cost for going "serverless", as you scale up. At some point, it will no longer make sense to outsource that to someone else, and you will want to bring that in-house.
Do you understand how locks work? Or plumbing? If you need to replace or rekey the lock on your front door, can you do that yourself? Or do you outsource that to a Locksmith? If you need to replace your toilet, can you do that yourself or do you outsource that to a plumber? What if your A/C unit goes out? What if your car breaks down?
There are going to be some things that some people are good at doing, and they're good enough at doing it themselves that they don't want or need to outsource that work to someone else.
And then there are going to be some things that those same people probably are not good at doing, and those should be done by someone else -- either outsourced, or someone else in-house who works in partnership with you.
You do some kind of work on uploaded data (let's say it's 1GB) and return data to the customer.
The classic model forces you to make all kinds of upfront costs and predictions about usage. If you decide to support 10000 concurrent users you would need to provision a 10 terabytes of storage with high speed disks and maybe 10 beefy machines. Without actually having any revenue you need to invest at least $20k.
In the serverless model, you can calculate how much it would cost.
> 1GB upload + 120 seconds of 2G serverless time + 1 GB download = $0.15
Now you charge the customer $0.25 for your work and you make a neat $0.10 profit per task. If you have a lot of customers you make more profit, if you have no customers it costs you nothing. (except your development time, but that is not unique to serverless)
To do it right you need people on call, round the clock team, etc. in the end serverless is one of those things that if you can get away with it and chase product market fit while spending a little more on opex while keeping headcount costs down its a no brainer.
It’s not without risk because of course not every problem lends itself to the architecture, it’s very hyped at the moment, many engineers hate it because it’s inelegant/leads to lock in/is different/etc so culturally that’s going to be a minefield if you’re not starting from nothing.