We found that the further we got into using different services the more difficult local development became. I just assumed that, as in the old days of web development, we would be forced into not being able to do local development at all. So then we'd have to have duplication of services. One for development and one for production. Or multiples for development so that each developer didn't step on the toes of the other. There goes the cost savings touted by Serverless Architecture.
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.
It's good practice to have separation of dev and prod service anyway. I don't see that as duplication, I see that as different operating environments.
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.
Proprietary software or hidden configurations. I have my site on localhost docker container. But I can't spin up an Aurora instance. So I use a similar mysql container. But it's not exactly the same.
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.
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.