7 ms·

Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some

by mabbo 10y ago

Some people don't like the word much, but "serverless" is going to become a bigger deal. You'll write your code, complex or simple; you'll hand it off to some cloud system; you'll write a bit of configuration; you're done. Likely the configuration part will become less and less required. You won't think about hardware, scaling, load balancing, etc, it will just happen for you. The data store being used will be abstracted away so that you don't know/care much about who provides it. Configuration problem. Containers, AWS Lambda, these are just the first course of this meal. Why? Because developers are expensive. Time spent doing anything other than the critical piece of writing business logic code is time wasted, and longer time to market. That's how I see the future of the server side.

blowski 10y ago
I agree in part. However, it reminds me of the prediction that front end development would be replaced by point and click build environments. While that suffices for a section of the market, it has very far from killed it off.
scrollaway 10y ago
This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that doesn't fit their app. I say this as a heavy Lambda user (https://hearthsim.info/blog/how-we-process-replays/ https://hearthsim.info/blog/how-we-process-replays/). Lambda is super useful if you have to scale CPU-heavy tasks. I do think that model will play a big role in the future, but I definitely do not think it'll be the go-to model for backend. It's a complete paradigm change.
- paulftw 10y ago
  People host their blogs on AWS lambda for less than dollar per month [1] compared to "standard" $5 or so for VPS. How's that a waste of money? Docker and containers are also a paradigm change, but the world seem to have adopted it just fine. [1] https://news.ycombinator.com/item?id=11644042 https://news.ycombinator.com/item?id=11644042
  - Keats 10y ago
    That link looks it's S3 doing the hosting and a lambda function only for contact forms, not hosting the blog on Lambda.
    - fermuch 10y ago
      You're still paying only a few cents.
      - chii 10y ago
        If you could host via s3, why not use GitHub.io and do it for free?
        brianwawok 10y ago
        Everyone has their reasons, but if it is something I actually cared about I would prefer to pay money for it. Generally things that cost money, even 5 cents, have better uptime than "free" stuff.
  - scrollaway 10y ago
    That's not website hosting, it's comment processing. Lambda is doing input processing, not serving a site. It's clever, although if I just wanted comments I'd just use disqus and spare myself the trouble. S3 is hosting the site. S3 is awesome for static site hosting, in fact. I also use it.
    - dsq 10y ago
      Whenever I'm behind a corporate firewall, which is often, I find that a lot of third-party services like Disqus are blocked. At those times I would have preferred the site to host it's own comments. Generally speaking corporate firewalls block a lot of stuff by default and the sysadmins don't bother to try and differentiate.
      - 10y ago
- mabbo 10y ago
  Consider the problems that both Lambda and Containers/PaaS solve for you: ignoring infrastructure. It's there, sure, but I don't care much about it. Now take that idea to the absolute extreme. I write code, I push it into the cloudy-cloud machine, and it's serving clients immediately.
  - collyw 10y ago
    As someone that knows how to set up a server, I found Heroku a lot more difficult to get a Django app running than on a "normal" server. And a lot more of a PITA to debug.
    - aptwebapps 10y ago
      What about the second time you ran a Django app on Heroku? But Heroku is not even in `mabbo's first course (maybe the appetizer?) so that's slightly a straw man.
      - StavrosK 10y ago
        I don't know how valid that argument is, because the second time I set up a server was just tweaking two Ansible variable files and running the "provision" command.
        aptwebapps 10y ago
        Sure, but what I was getting at was parent was just having learn how to use Heroku. And while it's true that automation is something you can do yourself, what about keeping the server up-to-date and patched and so forth? Also, repeating myself here, Lambda et. al. are a step further than Heroku.
        StavrosK 10y ago
        There are tradeoffs. You don't have to keep Heroku patched, but you also can't tune it if you need something specific.
- southpolesteve 10y ago
  I'm not sure why this myth persists. We've found Lambda + API Gateway to be an awesome solution for serving front end applications with server side rendering.
- whack 10y ago
  "Heroku is useful for prototyping, not scale" Can you clarify more on this.
  - scrollaway 10y ago
    You can't easily scale with Heroku. Scaling, almost by its very nature, requires tight control over your infrastructure. When you scale, you need to make your infrastructure fit your app. Not the other way around.
  - MattRogish 10y ago
    My quote is "everyone leaves Heroku eventually". Either you hit something that Heroku won't let you do (because of their tightly bound model) or you are burning tens of thousands a month on what would cost 20% on AWS/GKE, and you do it for cost savings (people are nontrivially expensive, of course)/ownership. Everyone leaves Heroku eventually. :D
    - elsurudo 10y ago
      Most sites never hit a scale big enough that they would need to leave
- bjinwright 10y ago
  It depends on what framework if any you choose to serve websites with. If you something like Chalice or Serverless then yes you are stuck with Lambda. But you use something like Zappa (https://github.com/miserlou/Zappa https://github.com/miserlou/Zappa) that is basically converts API Gateway's request object to one that is WSGI compatible then you can take your app and skip down the road if you get ticked off with Lambda. The Heroku comparison one isn't a fair one either. The waya you pay for Heroku dynos is very similar how you pay for EC2 or any other VM. You are billed by the microsecond that part is very important and while technically you have a 100 req/s limit to start with it is a soft limit if you ask to have it removed. It is probably more useful to compare it to Google App Engine but even that isn't fair.
obihill 10y ago
I agree in principle with most of what you've said here. The server-side is going to be a lot more intelligent in the near future though. My prediction is that every cloud provider is going to have some sort of AWS Lambda service that will eventually become like a server-less toolkit in the cloud. And these platforms could eventually have some augmented intelligence built-in. Essentially, we can't keep teaching each and every developer database connections, SQL, et al. The cognitive load associated with these sort of programs actually slows down advancement, and the quicker you can setup cloud-powered services that get the job done, the better it will be. Although, I can't say what that will do the livelihood of developers. We'll have to wait and see.
- collyw 10y ago
  Come one, people still stick with PHP because anything else is too difficult to set up on a server. Its been like that for years already.
  - obihill 10y ago
    Not necessarily. Going forward, if we want to get more stuff done, these things have to be abstracted further. We can't continue with this constant learning mountain just to figure out how to do things that can be expressed with a few lines of well thought-out syntax.
caleblloyd 10y ago
"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited lamda functions any day.
- deleted 10y ago
  [deleted]
- paulftw 10y ago
  This is based on the assumption that server without those optimizations is not fast enough. That used to be definitely true in the nineties, but hardware is getting faster while human reaction time stays relatively flat. Hardware is also getting cheaper, so throwing a beefier server is a much easier and better solution than investing months of error prone and non-scalable human labor. Everyone is ditching those beautiful and smart CS principles on FE by switching to hybrid apps, walking entire DOM on every update, etc. There's no reason same wouldn't happen on backend. In fact it already has - interpreted languages, GC, micro services. For better or worse progress in software always meant worse efficiency, because hardware was always forgiving that.
  - GrumpyYoungMan 10y ago
    >hardware is getting faster Considering that the end of Moore's Law is more or less here already, as pointed out in many HN articles, that's really no longer something we can take for granted.
    - paulftw 10y ago
      Moore law != progress
  - caleblloyd 10y ago
    It matters a lot! 1. Response time. A dedicated machine that stores state in-memory from request to request can respond orders of magnitude quicker than one that does not. 2. Resource Efficiency. 1-2 machines running optimized code will cost less than the 10-20 machines (or 100-200 machines) the cloud provider will have to allocate behind the scenes to run less efficient code.
tachion 10y ago
What does the fact that developers are expensive has in common with infrastructure/ops? You mean that developers shouldn't be working on it? I couldn't agree more, just like I wouldn't like my dentist being my heart surgeon! Developers should write the code, but they should not be doing infrastructure nor operations, and they should not enforce some 'serverless' utopia on projects/situations where pure infrastructure competence would do its job.
- mabbo 10y ago
  Depends on where you work. If you're a three-nan start up, you don't have an infrastructure or ops team. You do everything. As well, companies who have dedicated infrastructure teams are wasting money when we reach a world where that problem is purely automated. And that's where I think we're going.
  - tachion 10y ago
    Sure, sometimes you cant have it all, but in my experience (and hey, I am aware that I'm biased here!) I've seen ops engineers being better at programming than developers at doing ops. Another reason why I'd prefer to have 2 devels and 1 ops person is that that single ops person can bring to the table entirely different experience and point of view and that's a pure added value here. If you think that infra teams is wasting money, then I'd say its the same case of 'serverless utopia' - when you're using 'purely automated serverless' platform you're paying way more money, because, hey, someone has to build that infrastructure and it isnt magic, its people, ops people. So what you're doing here is simply changing money buckets labels in your head and you have to now deal with a product that's tailored for everyone, instead of you specifically.
    - brianwawok 10y ago
      If you make a few competing 3-man startups. One team has 2 devs and an op guy One team has 3 devs, one of which knows enough ops to ship code One team has 1 dev, 1 MBA, and 1 QA One team has 1 MBA, 1 QA, 1 Marketing guy I pick the 3 dev team, and hope each of them can fill in some of the other roles on the side (ops, marketing, qa). Not everyone would pick the dev team, but I would.
mrweasel 10y ago
Aren't you mixing infrastructure and backend-development? Hardware scaling and load balancing is infrastructure. Abstracting the data for the client, that's backend development, that's where your business logic lives.
_RPM 10y ago
Yes. You won't even have to know to code. You'll just press a button that generates the code for you. In the future, all programming jobs will turn into data entry jobs where the programmer will be entering commands into a GUI to generate a button here and there.
- mabbo 10y ago
  I sense sarcasm.

by mabbo 10y ago

blowski 10y ago

I agree in part. However, it reminds me of the prediction that front end development would be replaced by point and click build environments. While that suffices for a section of the market, it has very far from killed it off.

scrollaway 10y ago

This model isn't "serverless", it's PAAS. It's not much of a future. Heroku is useful for prototyping, not scale. (Edit: Doesn't mean it can't be more popular though - the web is full of prototypes) "Serverless" as in AWS Lambda has very specific use cases. The people who are serving websites on Lambda or something are not only doing it wrong, they are wasting money while locking themselves in to an architecture that doesn't fit their app. I say this as a heavy Lambda user (https://hearthsim.info/blog/how-we-process-replays/ https://hearthsim.info/blog/how-we-process-replays/). Lambda is super useful if you have to scale CPU-heavy tasks. I do think that model will play a big role in the future, but I definitely do not think it'll be the go-to model for backend. It's a complete paradigm change.

paulftw 10y ago
People host their blogs on AWS lambda for less than dollar per month [1] compared to "standard" $5 or so for VPS. How's that a waste of money? Docker and containers are also a paradigm change, but the world seem to have adopted it just fine. [1] https://news.ycombinator.com/item?id=11644042 https://news.ycombinator.com/item?id=11644042
- Keats 10y ago
  That link looks it's S3 doing the hosting and a lambda function only for contact forms, not hosting the blog on Lambda.
  - fermuch 10y ago
    You're still paying only a few cents.
    - chii 10y ago
      If you could host via s3, why not use GitHub.io and do it for free?
      - brianwawok 10y ago
        Everyone has their reasons, but if it is something I actually cared about I would prefer to pay money for it. Generally things that cost money, even 5 cents, have better uptime than "free" stuff.
- scrollaway 10y ago
  That's not website hosting, it's comment processing. Lambda is doing input processing, not serving a site. It's clever, although if I just wanted comments I'd just use disqus and spare myself the trouble. S3 is hosting the site. S3 is awesome for static site hosting, in fact. I also use it.
  - dsq 10y ago
    Whenever I'm behind a corporate firewall, which is often, I find that a lot of third-party services like Disqus are blocked. At those times I would have preferred the site to host it's own comments. Generally speaking corporate firewalls block a lot of stuff by default and the sysadmins don't bother to try and differentiate.
    - 10y ago
mabbo 10y ago
Consider the problems that both Lambda and Containers/PaaS solve for you: ignoring infrastructure. It's there, sure, but I don't care much about it. Now take that idea to the absolute extreme. I write code, I push it into the cloudy-cloud machine, and it's serving clients immediately.
- collyw 10y ago
  As someone that knows how to set up a server, I found Heroku a lot more difficult to get a Django app running than on a "normal" server. And a lot more of a PITA to debug.
  - aptwebapps 10y ago
    What about the second time you ran a Django app on Heroku? But Heroku is not even in `mabbo's first course (maybe the appetizer?) so that's slightly a straw man.
    - StavrosK 10y ago
      I don't know how valid that argument is, because the second time I set up a server was just tweaking two Ansible variable files and running the "provision" command.
      - aptwebapps 10y ago
        Sure, but what I was getting at was parent was just having learn how to use Heroku. And while it's true that automation is something you can do yourself, what about keeping the server up-to-date and patched and so forth? Also, repeating myself here, Lambda et. al. are a step further than Heroku.
        StavrosK 10y ago
        There are tradeoffs. You don't have to keep Heroku patched, but you also can't tune it if you need something specific.
southpolesteve 10y ago
I'm not sure why this myth persists. We've found Lambda + API Gateway to be an awesome solution for serving front end applications with server side rendering.
whack 10y ago
"Heroku is useful for prototyping, not scale" Can you clarify more on this.
- scrollaway 10y ago
  You can't easily scale with Heroku. Scaling, almost by its very nature, requires tight control over your infrastructure. When you scale, you need to make your infrastructure fit your app. Not the other way around.
- MattRogish 10y ago
  My quote is "everyone leaves Heroku eventually". Either you hit something that Heroku won't let you do (because of their tightly bound model) or you are burning tens of thousands a month on what would cost 20% on AWS/GKE, and you do it for cost savings (people are nontrivially expensive, of course)/ownership. Everyone leaves Heroku eventually. :D
  - elsurudo 10y ago
    Most sites never hit a scale big enough that they would need to leave
bjinwright 10y ago
It depends on what framework if any you choose to serve websites with. If you something like Chalice or Serverless then yes you are stuck with Lambda. But you use something like Zappa (https://github.com/miserlou/Zappa https://github.com/miserlou/Zappa) that is basically converts API Gateway's request object to one that is WSGI compatible then you can take your app and skip down the road if you get ticked off with Lambda. The Heroku comparison one isn't a fair one either. The waya you pay for Heroku dynos is very similar how you pay for EC2 or any other VM. You are billed by the microsecond that part is very important and while technically you have a 100 req/s limit to start with it is a soft limit if you ask to have it removed. It is probably more useful to compare it to Google App Engine but even that isn't fair.

obihill 10y ago

I agree in principle with most of what you've said here. The server-side is going to be a lot more intelligent in the near future though. My prediction is that every cloud provider is going to have some sort of AWS Lambda service that will eventually become like a server-less toolkit in the cloud. And these platforms could eventually have some augmented intelligence built-in. Essentially, we can't keep teaching each and every developer database connections, SQL, et al. The cognitive load associated with these sort of programs actually slows down advancement, and the quicker you can setup cloud-powered services that get the job done, the better it will be. Although, I can't say what that will do the livelihood of developers. We'll have to wait and see.

collyw 10y ago
Come one, people still stick with PHP because anything else is too difficult to set up on a server. Its been like that for years already.
- obihill 10y ago
  Not necessarily. Going forward, if we want to get more stuff done, these things have to be abstracted further. We can't continue with this constant learning mountain just to figure out how to do things that can be expressed with a few lines of well thought-out syntax.

caleblloyd 10y ago

"Serverless" such as AWS lambda removes the ability to take advantage of so many Computer Science principles that are integral to writing a fast backend. From one request to the next there is no CPU cache optimization, in-memory caching, and no IPC to other useful programs. Serverless has it's niche for some tasks such as responding to events, but to do any heavy lifting I'd take a handful of beefy VMs over unlimited lamda functions any day.

deleted 10y ago
[deleted]
paulftw 10y ago
This is based on the assumption that server without those optimizations is not fast enough. That used to be definitely true in the nineties, but hardware is getting faster while human reaction time stays relatively flat. Hardware is also getting cheaper, so throwing a beefier server is a much easier and better solution than investing months of error prone and non-scalable human labor. Everyone is ditching those beautiful and smart CS principles on FE by switching to hybrid apps, walking entire DOM on every update, etc. There's no reason same wouldn't happen on backend. In fact it already has - interpreted languages, GC, micro services. For better or worse progress in software always meant worse efficiency, because hardware was always forgiving that.
- GrumpyYoungMan 10y ago
  >hardware is getting faster Considering that the end of Moore's Law is more or less here already, as pointed out in many HN articles, that's really no longer something we can take for granted.
  - paulftw 10y ago
    Moore law != progress
- caleblloyd 10y ago
  It matters a lot! 1. Response time. A dedicated machine that stores state in-memory from request to request can respond orders of magnitude quicker than one that does not. 2. Resource Efficiency. 1-2 machines running optimized code will cost less than the 10-20 machines (or 100-200 machines) the cloud provider will have to allocate behind the scenes to run less efficient code.

tachion 10y ago

What does the fact that developers are expensive has in common with infrastructure/ops? You mean that developers shouldn't be working on it? I couldn't agree more, just like I wouldn't like my dentist being my heart surgeon! Developers should write the code, but they should not be doing infrastructure nor operations, and they should not enforce some 'serverless' utopia on projects/situations where pure infrastructure competence would do its job.

mabbo 10y ago
Depends on where you work. If you're a three-nan start up, you don't have an infrastructure or ops team. You do everything. As well, companies who have dedicated infrastructure teams are wasting money when we reach a world where that problem is purely automated. And that's where I think we're going.
- tachion 10y ago
  Sure, sometimes you cant have it all, but in my experience (and hey, I am aware that I'm biased here!) I've seen ops engineers being better at programming than developers at doing ops. Another reason why I'd prefer to have 2 devels and 1 ops person is that that single ops person can bring to the table entirely different experience and point of view and that's a pure added value here. If you think that infra teams is wasting money, then I'd say its the same case of 'serverless utopia' - when you're using 'purely automated serverless' platform you're paying way more money, because, hey, someone has to build that infrastructure and it isnt magic, its people, ops people. So what you're doing here is simply changing money buckets labels in your head and you have to now deal with a product that's tailored for everyone, instead of you specifically.
  - brianwawok 10y ago
    If you make a few competing 3-man startups. One team has 2 devs and an op guy One team has 3 devs, one of which knows enough ops to ship code One team has 1 dev, 1 MBA, and 1 QA One team has 1 MBA, 1 QA, 1 Marketing guy I pick the 3 dev team, and hope each of them can fill in some of the other roles on the side (ops, marketing, qa). Not everyone would pick the dev team, but I would.

mrweasel 10y ago

Aren't you mixing infrastructure and backend-development? Hardware scaling and load balancing is infrastructure. Abstracting the data for the client, that's backend development, that's where your business logic lives.

_RPM 10y ago

Yes. You won't even have to know to code. You'll just press a button that generates the code for you. In the future, all programming jobs will turn into data entry jobs where the programmer will be entering commands into a GUI to generate a button here and there.

mabbo 10y ago
I sense sarcasm.