I think the issue is some people see "serverless" as an all or nothing scenario which it really isn't. Some problems are solved well with serverless and some are not. It's like the container vs virtual machine argument. One isn't designed to replace another - they're just different tools for solving different problems; each have their own strengths and weaknesses.

Just like people have been calling their controller actions from test harnesses for ages to test their APIs. You can call call your handler the same way.

At the end of the day, AWS is just passing you a JSON message. You can call your lambda function manually with the same JSON payload locally.

I tend to opt for the SSH tunnel route for personal projects but use OpenVPN with a secrets management (eg Vault or AWS's new key store) for professional projects (ie when you have several people on your team).

AWS is versatile enough that you do actually have several options available to you.

But then... any architecture benefits from localhost-first.

These are problems that will be solved eventually, I have no doubt. But they haven't been solved yet and that is what makes Serverless Architecture not ready for prime time in my opinion.

Even back in the days of self hosting, I've lost track of the number of times a Dev script has gone wild and caused excessive load on the RDBMS or tried to spam the SMTP relay. On a Dev environment you can catch that without affecting live services.

As for the other issues you meantioned, this is nothing new. There have always been appliances in IT. Whether it is physical rack mountable appliances like hardware video encoders, or SaaS solutions on a public cloud like AWS media transcoders, you interact with then the same. The only difference with public cloud solutions is you you first have to bridge your office network with your AWS (or whatever) virtual private network. Thankfully you have a variety of tools at your disposal to do that. (Over the years I've used no less than 4 different methods to bridge a local network with an AWS VPC - each taking advantage of their own specific business requirements).

Indeed, and, as a general rule, they were astonishingly expensive, especially in up-front purchase cost.

> The only difference with public cloud solutions

I posit that another difference is that the up-front cost is approximately zero. That makes the adoption decision much easier (even possible in the first place) for much smaller companies, especially startups.

That also means what would otherwise have been an up-front cost is hidden in the pay-as-you-go cost.

That cost-hiding does create a new problem, albeit a sublte on. A startup faced with having to buy a $300k appliance might think nothing of it if there were a smaller/dev version available for $30k for that environment. However, if that appliance actually needed to be duplicated in the full $300k form [1] in both (or maybe more, if they have stage/qa/integration, research, and/or multiple dev envs), that startup would take a serious look at alternatives. Those relative costs aren't as stark with the cloud version of applicances, until well after the choice has been made.

[1] Or, worse, an even more expensive version, if dev, testing and/or research use of the appliance is heavier than production. I expect that's a rare, outside of storage.

Ideal because it's faster development time. And free since I'm not paying Amazon compute time to run my code while I write it.

Not always possible because I don't have AWS's services locally. As mentioned elsewhere, there are emulators but, by virtue of their emulation, may not always perform like the real thing. That's a debugging ball of wax that I personally hate having to untangle.

You can access most (all?) of AWS services without running on AWS EC2/Lambda.

Especially for CRUD apps and otherwise simple apps, testing should start after git push.

Don’t want to wait each time? Automatic build and teardown of test envs on a schedule, to avoid always up.

I still local test low-level code. But anything running in a cloud should really just be tested there.

And sometimes the data is too large to have fully on localhost. You can work with a subset, but if you have a 2tb database, it's not feasible to have the whole thing local for testing.

https://www.markheath.net/post/remote-debugging-azure-functi...

As I've said before; these are all problems that all of the cloud providers will solve eventually. But until they do I'm not sold on building a production application on a Serverless Architecture.

So what if I gave you a command-line tool to simply make the current code in your development environment live?

Want a debugger? Nope.

And I also gave you live step debugging, plus replays of recent server state?

Want log files? Gotta get them from a different service that frequently has a lag of 30 seconds or more.

And the logs from the instance you're debugging are available instantly?