The main problem I see here is the problem we run into with every hot new abstraction of a thing that some people find troublesome as developers. Someone alrea

The main problem I see here is the problem we run into with every hot new abstraction of a thing that some people find troublesome as developers. Someone already mentioned virtual hosting. I'd like to bring up ORMs. There's this idea that you can forget about the datastore--abstract it away, manage it in code, whatever. You don't have to learn about databases, table structures, or SQL if you don't want to. Just think about your models and don't worry about the rest. I'm not against ORMS and find them both amazing and useful in certain ways. What I am against are systems developed entirely by developers who refuse to think about these things. Especially when I have to come into the situation after they have left and do something genuinely unforeseeable, like provide reporting and analytics from the back end, integrate with a third-party system, or--god forbid--add new functionality. What you're left with is a dysfunctional, slow, mess that's incredibly difficult to work with, a data layer that makes no sense unless you're working with that particular ORM, and no ability to tell exactly where in a quarter-million lines of code the exact logic you want to fix or modify actually is. Yes, I'm quite certain that no one would recommend that anyone use serverless architecture that way. It's the wrong tool for the job. Just like ORMs are the wrong tool when performance is critical and you need to manage complexity for 30 services from the same data layer. But someone is going to do it. In reality, probably lots of people will. Some CTOs will buy into the hype and hire teams of consultants to do it or hire their actual dev team full of serverless experts. I'd echo what someone else said to the effect of abstractions are great so long as you understand what you're abstracting and know when it's a good idea to do so. Viewed as a tool for accomplishing a small thing pretty quickly, it sounds cheap, fun, and exciting. Viewed as a new way of taking shortcuts around quality infrastructure that's needed to support large, complex systems, I feel like it's probably a bad idea. Given my attitudes above, it's probably not a surprise that I find the description a bit sketchy. I think calling it Serverless is a misnomer for all of the many good reasons people have pointed out in this thread. But I also question calling it architecture. What I expect we will see in fairly short order is a collection of libraries or frameworks that resemble PhP not only in function (a service that pops in and out of existence on demand) but also a language-like form that evolves rather than being intentionally built--and evolves towards ease-of-beginner use rather than being guided by a coherent architecture. And, in the grand scheme of things, that's fine with me. I just hope I never inherit a system like that.