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) 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.

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

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.

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.

I appreciate the conendrum but I don't think people running the sort of static blog you host on S3/github pages care about overbearing corporate policies.

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.

Hosting your blog using AWS Lambda is over engineering and still not the cheapest solution. Host your static files on S3 or your CMS on Heroku and put Cloudflare in front of it. This solution comes with auto scaling, SSL, and HTTPS and is completely free

That link looks it's S3 doing the hosting and a lambda function only for contact forms, not hosting the blog on Lambda.

You're still paying only a few cents.

If you could host via s3, why not use GitHub.io and do it for free?

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.

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.

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.

I had the same experience as a django novice until I started understanding how django works. Its actually a lot easier once you know some of the pieces eg. dj-database-url. I realized I had issues because I didn't understand how all the pieces fit together. ALso.. they have a template that you can download which essentially solves all the issues. Nowadays I always start with their template. or even if I have the app written, I will download django template from heroku, and plug in my apps to it.

Then Heroku aren't the solution either. But they're a step towards it. It's all attempts to get it right, wild swings in the darkness. Someone's going to smack it hard in the head and we're all going to ask why we didn't think of that before.

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.

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.

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.

There are tradeoffs. You don't have to keep Heroku patched, but you also can't tune it if you need something specific.

Sounds like you're looking for something closer to Otto (https://www.ottoproject.io/)

We're headed this direction with our service: https://www.lite-engine.com .

So, like Elastic Beanstalk or Heroku ?

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.

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

Most sites never hit a scale big enough that they would need to leave

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.