"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/). 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.
S3 is hosting the site. S3 is awesome for static site hosting, in fact. I also use it.
If I bothered setting up my own blog, I certainly wouldn't spend a bunch of time setting up comments on Lambda just for my two corporate-firewalled readers when I can just use a hosted solution. That is, if I even cared about comments in the first place. There's just much more interesting things to work on, with and without Lambda.
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.
Can you clarify more on this.
Everyone leaves Heroku eventually. :D
When you scale, you need to make your infrastructure fit your app. Not the other way around.
I guess following your analogy. If you only had a dentist and a salesperson available to do your heart surgery, who would you choose?
I'd go and look for actual surgeon. Or bite the bullet and try to live my life as it goes, without risking complete failure of both these guys messing with my heart. ;)
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.
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.
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.
Ops is not hard. A good dev can do it. I am a developer, not an ops person. I have written 100s of ansible scripts. I have dealt with deployments of single servers up to 100 servers across all kinds of hosts.
Your argument is "OPS PERSON CAN CODE TOO"
My argument is "DEV PERSON CAN OPS TOO"
Really labels are stupid.
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.
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.
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.
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.
Why is that a problem? You can design a system and implement it with AWS Lambda (or similar) and a few other things like their (or another) database, message queue, and data storage. Then, when you find that you've got processes that are bottlenecked by this, move them into dedicated servers or containers with faster routines. Just like we already do when pairing (possibly) slower but higher-level languages with C libraries.
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.
Hardware scaling and load balancing is infrastructure. Abstracting the data for the client, that's backend development, that's where your business logic lives.
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.