Serverless Architectures
martinfowler.com
martinfowler.com
I don't see how this would be much fun to work on in a team. We have enough trouble her squabbling over who gets to use the staging server next.
That said, the problem with debugging stands (for AWS lambda, at least).
There's a plenty of good reasons to avoid SPAs.
I've set them up a few times for contact forms and other light pieces of functionality for static websites, and it fits that niche really well. Obviously, I think the serverless movement has some grander notions of the size and scale of applications that could be constructed, so we'll see.
If anything, it is easier with serverless, because you can branch pretty cleanly down to the single function level.
All you need is a level of indirection, usually at the domain and pathing level.
Now, short-term projects that can disappear in a few years or less have less risk for lock-in. We still see those disrupted on occasion when the vendor abruptly disappears. Users had to redo their work, which wouldn't have been necessary in lock-in free approach.
We're "locked in" to AWS - in that it would take a massive effort to move to Google/bare metal, despite not using any AWS-written servers (that is, we're FreeBSD, MySQL, Redis, etc.). But the benefits of AWS have been huge for us, and anyone saying they're outweighed by the potential downside has no idea what they're on about.
The right tool for the job is sometimes a vendor with specific services that, yes, sometimes have a lock-in component, even for long-term use.
In this specific case this particular BaaS implementation may not be full-cooked enough to entice you onto it, but saying vendor lock-in is bad as a blanket statement or incontrovertible truth is just silly.
For that matter, any number of proprietary languages have been successful over the years. If it solves a problem, and solves it better and faster than reinventing the wheel, most businesses will use it. Time-to-market is a much bigger deal than abstract concerns about future platform change. I've been in this industry for 20-odd years, and the only things I've seen last are Unix and SQL. Everything else is new since I started. I sometimes work with bleeding edge, and I'm not afraid.
If infrastructure is really 90% of your code work and you can't salvage business logic in a platform change that doesn't require a new language, the problem isn't the serverless architecture.
I've been using lambda lately and perhaps 5% of the code in my Lambdas is AWS-specific; the vast majority was rapidly extracted from existing projects, wrapped in a simple Lambda interface, and done.
While I don't advocate Lambda for everything, there's almost nothing there to lock you in - its a simple function that accepts two parameters. Even coupled with API Gateway, its just moving my routes definition to a slightly different layer. I could easily port any of this work back to any common Web framework with almost zero effort. I won't, because Lambda solves actual problems for me now.
Not theoretical: Microsoft, Borland, IBM, HP, Oracle/Sun... all did it at least once with Microsoft doing it many times. They're not open, which drives up the cost of exiting dramatically.
If you feel locked in, you lift-and-shift your serverless logic to a new platform. Write some shims and wrappers. It ain't that goddamn hard.
Any kind of practice without such setup means you've decided to let the vendor control your situation ftom that point onward. Historically, from mainframes to servers yo desktop to mobile, this always led to less brnefits overtime where new, better stuff emerged that locked-in customers couldnt use at all or benefit as much as they liked. Those that avoided lockin could. Worse, some locked-in got hit with price hikes or even EOL'd products.
So, I think the default should be justifying a lock-in product rather than the other way around. Ive seen situations where it made sense. My comment mentioned one. It just rarely does esp today with so many cheap, flexible, and so on alternatives to commercial lock-ins.
So, the question instead is "With these requirements, which products and services meet them with good, cost-benefit analysis? And which is best when benefits and liabilities are considered?"
I have seen people waste precious time and energy on "open" solutions, and lose focus on other, important things. I'd rather be stuck extricating myself from some lousy vendor relationship than not selling my product.
I'm sure Stallman couldn't use the iphone when it came out because of constraints, that doesn't mean the iphone ever was DoA.
For a particular use you certainly can. Some problems have hard constraints. Freedom from lockin is a common one.
Edit: I'm not very familiar with Horizon. It looks promising but I assume it's tightly coupled with RethinkDB?
Technology lock-in without vendor lock-in isn't that huge of a liability. A popular PL under an appropriate license isn't going to disappear tomorrow, and its creator doesn't have the power to hold your business at gunpoint. Conversely, B/FaaS providers upon which you truly depend definitely can extract (or by disappearing simply destroy) much more value than you originally anticipate.
[1] If you use Wolfram Language or Matlab then your choice of PL causes vendor lock-in, but most PLs aren't like this.
The difference is one doesn't have access to Lambda infrastructure itself. IF I write an entire app in XYZ lang, I can still run it on my own server or make it an executable and call the code through RPC. If I base all my work on a third party vendor infrastructure I can't replicate it requires an even more massive effort to migrate to something else, because now I basically have to re-write my app from scratch. FAAS may have killed BAAS but isn't going to kill PAAS.
Serverless architecture isn't a "lockin" problem. You don't develop your app with serverless in mind, thinking that you might some day go back to serverful. Serverless is a core design of (some parts of) your app.
When I hear people say they're trying to "be generic", "abstract away serverless architecture" or some such, I'm replacing "serverless" with "asynchronous", or "functional", and it sounds bloody ridiculous, because it is.
If competitors to AWS lambda arise, I do hope they'll have a similar architecture available because that's where the power of Lambda resides. The "lock in" is only whatever those fake WSGI objects lambda is passing to the function are, as well as internal triggers for the servers (SNS, S3, ...). Those things can be abstracted away if competitors offer similar mechanism.
Trying to abstract serverless+serverful together is ridiculous. If you're successfully doing this, it sounds like your app doesn't belong in a serverless environment in the first place.
PS: There's plenty of drawbacks which are vendor-specific, not tied to the serverless design itself. For example, the Amazon API Gateway is atrociously bad. AWS Lambda doesn't even support Python 3, only Python 2.7 (get your shit together Amazon). Those are things I'd switch to a different vendor for in a heartbeat... if there was actual competition.
You provide an entry point to your application. AWS provides you with an `event` and `context` object, both of which are nonstandard. You extract, out of those objects, the data you care about... and you pass it down to whatever it is you want to run.
The extraction is very simple. Here, take a look at a SNS-triggered lambda:
https://github.com/HearthSim/HSReplay.net/blob/e12a6b8217b3b...
One line of code is vendor-specific. I could move to a different vendor in a heartbeat. Yes, bits and pieces are using SNS/S3; some of which are already abstracted away, the rest which can be easily replaced.
And frankly, when dealing with platforms as large as AWS, the vendor you choose is a big deal. You're not supposed to change every week... so it doesn't matter if it takes a little cleanup to move to another vendor. If it's taking you more than a few hours, your code is making assumptions it shouldn't about the underlying architecture and that's your fault, not amazon's.
If you've designed your client-side javascript (or swift or whatever it is) properly, you've abstracted out the API calls to say, AWS Lambda, and wrapped them such that the implementation is not tightly coupled to the calling code. Eg you write a generic Storage class and call Storage.Save, which wraps whatever API you use to save stuff, be it Lambda or otherwise. Change vendor and you just change your Storage class's implementation without needing to alter client functions..
If you can get the same message-delivery semantics from Google's message bus, then the refactor would end there, but if you happen to be depending on a feature that's not implemented on your new platform, then you might have to refactor your application logic further.
Furthermore, you still have to get your code into production, upgrade it, monitor it, and ensure that the other functions that it, and all of that currently tends to depend on platform-specific tooling.
Much of this is also the case in the VM-based PaaS world. But, there you have projects like libcloud that can abstract some of the differences away. That feature gap is pointed out in the OP article, which makes it clear that the lock-in issue isn't a fundamental defect with the functional paradigm, just a side-effect of the FaaS offerings being young.
> What more could you ask for?
Native support. Was that not obvious?
If you can't use some obscure hipster language, that might be a problem. But my biggest gripe at the moment is lack of Ruby, and I'm sure Amazon will fix that.
For the most part, Lambda code is just normal JavaScript/Python. It would take fairly minimal effort to take that code and package it up to deploy on a normal (non-Lambda) server.
Like any piece of the software stack, there are providers focusing on services that are proprietary, open source, and a mixture of the two. I am personally most excited about the hosted open source providers, because it gives dev teams immediate access to the technology, but the option to bring it in house when and how it makes sense.
To whom? I see many people who need a trivial amount of server logic. Right now, they can do one of 3 things:
- Use a random site who may or may not radically change their business model in the new few years. - Pay $5/month for a VPS, then get forcibly dragged up the learning curve of becoming a full-time sysadmin - Pay pennies for Lambda
Is there a reason to re-write your backend? No. Is there a reason to consider it on your next project? Possibly.
Since any site "may or may not radially change their business model" at any time, you really only list two substantive options:
(1) Use an VPS, or (2) Use Lambda
But, really, there's a more choices:
(1) Use a VPS or IaaS (with full sysadmin overhead), (2) Use a PaaS (like Google AppEngine) and avoid sysadmin overhead (but probably have more code than a "serverless" function host like Lambda), or (3) Use a "serverless" function host like Lambda
You probably don't want to do #1, since for low-volume and trivial logic its (1) comparatively expensive, and (2) high sysadmin and programming overhead compared to the other options.
#2 is lower overhead (particular on the sysadmin side), but still more than #3. But possibly cheaper (e.g., if the requirements fit within the free quotas for AppEngine.)
#3 may be the best solution for some things, but its not as stark as a choice as you present it to be.
As far as lock in, it is trivial to utilize the same code on your own servers. I do that for my Python code for development using a simple Cherrypy setup in less than 100 lines of code.
"Serverless" seems to be the pricing model. It still runs on a server.
For testing it should be possible to run everything in a mock vendor system on your local machine - not that such a system exists today, but theoretically it could.
Overall, my sense is that Serverless architectures will never be useful for everyone. They'll always be better for smaller, simpler systems that don't see tons of traffic. The Serverless community should focus on these use cases. The thing is, there are tons and tons of apps that are over served by all the flexibility EC2 provides. And there is another set of unborn apps that haven't been created only because the barrier to setting up and managing the backend was a _little_ too high. I'm really excited to see serverless bring these apps to life.
And don't even get me started on installing dependencies...
If you were smart you had a system for dealing with migrating between computers. Maybe it was a script, maybe you knew which folders to copy, maybe you were extra careful with where you saved everything. Maybe you didn't care.
Some of the modern shit is nice (I fondly</s> remember setting up a personal Active Directory+Exchange server to get a private LDAP sync, compared to Google now) but as a whole the current model encourages carelessness and mindless profiteering. There's too much of the equation nowadays in control of people who want to charge you for it, whereas before the user was had control. I miss the days when it was considered rude to require a network connection unnecessarily.
Plus, nowadays a product you love can turn to mush and there's nothing you can do about it save stop paying for it (and lose its services in the process), which will never amount to anything unless people do it en mass. Features regularly disappear because some bullshit business reason or another, or some user metric said only 2% of people used it. Well, fuck those 2% guys right?!? Before, if I didn't like your patch I could just revert to the old install discs. Nowadays I have to pray you don't alter your deal further.
edit: and don't get me wrong, as a developer the evergreen model is great. But as a power user, I hate it.
edit2: not to say older software didn't have its crap. Lots of fussy stuff to deal with. But compare the initial release of Windows 3.1 to Windows 10...
FaaS solutions like algolia, getsentry, getstream.io. mapbox, layer, keen.io, twilio, stripe etc only run a small part of your application. They scale well, are more reliable and often more cost-effective than an in-house solution. If you're ever not happy with them it's easy to switch to an alternative. If Algolia no longer works for you, simply switch to Elastic. If you're not happy with Mapbox, use google maps. No longer like, getstream.io, use Stream-Framework. It's relatively easy to change since you're not handing over your entire backend.
Also see my post on HighScalability about this: http://highscalability.com/blog/2014/12/22/scalability-as-a-...
Think of it as the API vs SPI distinction that we used to have back in Windows-land. API-only services like Twilio or Stripe are usually just called SaaS.
That's the thing, I guess the demographic that lambada is going for it will save money, but along with the mentioned vendor lock in, when you really need to have something on and processing requests non stop the costs savings really evaporate.
It's weird to me that the serverless thing catches on when it seems to be best suited for projects in their infancy without need for 24/7 request processing , or things out of the critical path like image resizing or things of this nature. But entire apps? Feels very much like going back in time to shared hosting.
I could see it saving money until about 1m requests a day and then a sharp drop off where you are hemorrhaging cash after that...
With modern auto scaling systems that aws and gce provide I bet most shops don't stand to save any more money than with a normal modern day refactor.
At the end of the day this leaves you more rope to hang yourself with. It makes it easier to run slow or poorly thought out code. 1000 processes might be cool but is never as cheap as 2 working correctly that accomplish the same thing, as an extreme but actual example of a situation I helped unwind with GAE, which was serverless before the buzzword.
https://github.com/jorgebastida/gordon
A few examples can be found here, and it's a good point to start if you're using Aws Lambda
So while each site was a PHP monolith on shared hosting, a FaaS architecture could be many smaller units of code, spun up on demand to handle a specific need of a service, possibly across multiple servers.
It is not at all a client/server model unless you wrap API Gateway around it as an event source.
https://product.reverb.com/2016/07/16/deploying-lambdas-with...
In any case, it seems that "Benefits" has also been added since the last HN discussion (revision history: http://martinfowler.com/articles/serverless.html#Significant...).
I discovered all kinds of weird solutions:
- Push a "please wait" message onto an SQS queue, and set a Cloud watch alarm to fire when the queue length was >= 1 for at least one second. Have a variety of lambdas respond to the alert by checking if the have any work to do, and then racing to pop the queue and do one operation. I think I needed SNS in there too, for some reason. Fanout?
- Build a town clock on an EC2 and have it post "admit one" tokens to SNS. Nice and simple, but I was evaluating serverless, and adding a server felt like defeat. Might as well just run the whole thing on that EC2.
- Have on lambda pop request descriptions from a queue, and sleep for one second after sending each one. The request responses would have been pushed onto another queue. All of the other lambdas could just handle the events they cared about as quickly as data became available. Sleeping in a lambda just felt wrong, but for one second, it probably would have been fine.
In the end, I was still experimenting and exploring when my estimate loomed near, so I just wrapped up all of the application code and piped it all together with delays in loops that made API requests. Deployed it to Heroku in a hurry with minimal fuss.
What I learned:
- There are bad use cases for serverless, and I had started on one (SLS doesn't wait on no one)
- Serverless does encourage a clean architecture, from a code perspective: I was able to quickly transform it into a completely different type of application.
- AWS's services have lots of little surprises in their feature set: SQS doesn't fire any kind of event. SNS can't schedule events in the future (maybe I should have expected that one). Cloud watch events can only trigger a single lambda.
- There is a need for a town clock / scheduler as a service in AWS'. How many people have built that themselves?
* I think API Gateway can throttle requests. Not sure if that was part of your pipeline or if your lambda had a different trigger.
* There is a Town clock SNS event https://alestic.com/2015/05/aws-lambda-recurring-schedule/
Did you want AWS Kinesis? The integration with Lambda polls the queue every few seconds and sends batches of records to a Lambda function when the queue has work to do. http://docs.aws.amazon.com/lambda/latest/dg/with-kinesis.htm...
When you evaluate the AWS serverless platform, I recommend looking at everything that is an event source, sink, or processor: Lambda, SNS, SQS, SWF, SES, Cognito, IAM, Kinesis, IoT, API Gateway, S3, DynamoDB.
It's a pretty rich palette to work with.
In the spirit of treating this like Lego, I suppose that maybe I could have uses SES to email itself an HTTP request description, and counted on the email lag to keep requests spread out over time. But at this point, things are getting so weird that I think it's time to just admit that "work on something at a specific pace, then go to sleep for a few hours" isn't the sort of task that the serverless architecture is well suited for. Serverless is for tasks that you want done on demand, as quickly as possible, imo.
This lack of firewalling continues up and down the stack. As such, it's a lot harder to create rules regarding any API calls you make to third party services, harder to audit how your app interacts with any datastores, and generally an administrative nightmare. It may be useful for some apps, but just feels like a nightmare to maintain for any decently sized setup.
Because the framework infrastructure is supposed to solve all of that behind the curtains, so developers cannot shoot themselves in the foot. (Other than through excessive resource consumption)
http://docs.aws.amazon.com/lambda/latest/dg/with-scheduledev...
Please, let's not accept this redefinition of a fundamental and well known term.
Unfortunately, it's limited to JavaScript, Python, and Java for now. Google Cloud Functions is similarly limited to JavaScript.
I know that these languages were chosen because they can be easily sandboxed, but it would be nice to support something more generic without having to create docker containers for everything.
I remember this movie the first time around, when it was called "virtual hosting". What a revolution -- transitioning from needing a Unix box running Apache to run your PHP e-commerce site to having your host take care of that for you -- and everybody else.
Just because you're doing something old "in the cloud" now doesn't make it a new thing. Just like you can't append "...with a computer" to an existing method and get something patentable.
Take NoSQL which was hyped as something new 5 or 6 years back. Because of that everyone under a certain age decided that they had to use it.
The older more cynical of us realized that this was how people has been writing software before SQL came along, and realized we were throwing out a whole host of features and benefits because this was the "new" way of doing things.
Compare to working with level of abstraction of "entity" (function, could be bigger) and have it running when needed and scale as needed.
I've been going under the assumption that it's just not the right use case for Lambda, though I'm hoping I'm wrong.
Also, small instances are cheap to keep around, and as you pay per request, it's in the providers best interest to make that efficient.
Well, that's the sales pitch, anyway...
Has anyone gone through https://pragprog.com/book/brapps/serverless-single-page-apps?
The example material looks good. Overall it could be a bit short.
Its an architecture that relies on multiple, supposedly distributed services, all of which are hosted on servers...
Why not just call it "Multiserver" instead.
If they mean "containerless servers" or "microservices", then why don't they say so?
If they mean "distributed servers" why not call it that.
If they mean that the client relies on multiple services (each hosted on different servers) why not just call it a thick/fat/stateful client?
Even a database is a remote service (if not embedded), that is run on some sort of server.
Calling anything serverless is just ridiculous as long as it depends on services on the network.
This smells really bad of just another attempt at marketing a pointless definition just to get more business.
Since the servers are completely abstracted away, they could have just as well not be - hence serverless.
An analogy escapes me but I sure there are some.
Or do you mean that the user don't have to care on how to configure the application? Then "Zero-configuration" is a better name.
Or do you mean that the application hides that it use services on the net? Then it is even worse.
The user here is the developer. Here's an explanation from the article:
> "some amount of server-side logic is still written by the application developer but unlike traditional architectures is run in stateless compute containers that are event-triggered, ephemeral (may only last for one invocation), and fully managed by a 3rd party ... One way to think of this is Functions as a Service."
FaaS is probably a better name.
Serverless really is an auto-scalable distributed infrastructure, perfect for small CPU-intensive tasks in an app which doesn't know how many CPUs it'll need at any one time.
That's a weird logical leap.
Let's make the servers not be by unplugging them. How's the abstraction working now?
The whole idea of a server is to abstract away the details of the upstream computer and its software stack, so the user can think of it only as a provider of an abstract service. The irrelevance of their implementation as a host, VM, box, rack of boxes, pool of quantum foam, string and sparkles, is already built into the concept.
We all know that there's no unique process that is http://amazon.com. It's a service, provided by a (vast distributed) server.
There are some discussions of API's. Whether or not a service has an API is orthogonal to something being a hosted service.
Thus "serverless" means software and humans writing and deploying said software that do not need to know anything about /etc/<whatever> and installing packages and disk partitioning and swapping and whether Python 2 or Python 3 gets installed by default this week and ...
IMHO a good thing, mostly.
Perhaps we could adopt 'A1' instead of the confusing term 'serverless'...
(And yes, 2 years ago I was a little more violent with my wording. Time has taught me things.)
This is marketing bullshit for microservice architecture. It just sounds better with some added philosophy.
With AWS Lambda/API Gateway (and arguably with Google App Engine before it) you take away the toil of having to:
* Manage/deploy servers
* Monitor/maintain/upgrade servers
* Figuring out tools to deploy your app to your server
* Scaling an app globally.
* Coping with outages in a data-centre/availability
* Worry about load-balancing & scaling infrastructure
I think this is more than just a marketing gimmick. It is part of a big change in application architectures.
At one end as a small developer of of web/mobile app this can considerably reduce the amount of code/maintenance you need.
At the opposite end of the spectrum the likes of Google (Borg) and Facebook (Tupperware) have developed their own in-house solutions where by servers are largely abstracted out as an entity that developers need to worry about.
Managed docker services (e.g. Google Container Platform, Docker Cloud) are another approach of achieving a largely 'serverless' goal.
(edits for formatting)
This would only be true if the abstraction were not leaky. Frankly, upon a very cursory inspection, my opinion is that AWS Lambda leaks like a sieve.
Docker vs Ansible is a deployment strategy.
Relying on others to make your code run on a server is VERY different than doing it yourself. It's practically the difference between a company with a DevOps team and one without it.
Write server-side code as part of my application, targetting some platform API. Once finished, invoke some deployment routine.
The service provider's job is:
Receive a request from me to deploy my server-side code and keep it running on some server cluster.
That's not a serverless applications architecture because the application contains server-side code.
If you don't want to call it a deployment strategy, fine, I won't insist on that name, even though in my view using a service provider for deployment deserves to be called a deployment strategy.
More generally, it's an approach to make my server-side code run once I'm finished writing it. Call it what you will.
I think to an end-user the definition is meaningless, but to its intended audience it fits.
A lot of web frameworks enforce the shared-not-that-much (not quire "shared nothing", but close) style of programming where every HTTP request is essentially just an "event" that hooks into a controller-handler? And if you want anything to stick around from one request to the next, you keep it in memcache/db/BaaS/third-party service, not your own process?
I don't think this is as radical a shift as many here might think, especially given the move to containers is already well underway.
Unless there is some elegant factor to Serverless that I am missing. I just can't shake the feeling that at the end of the day this is just a sales tactic.
Nevertheless, I opt to use serverless BaaS solutions whenever I can afford to.
Oh yeah and remember spawning CGI processes for every request never scaled well. :-)
Here is a case study: Last year I was working on an SMS app, QKSMS [1]. We offered a premium version for $2. We did a promotion on reddit where we gave away 10k free premium versions. So, take a second and ask yourself: how quickly do you think you could implement a promo code system + a website for distributing codes for one time use?
We did it in about 5 hours. It costed about $100. The website was (and still is) statically hosted on Github. [2] The website source code is ~22 lines of JavaScript. It pulled 12 promo codes from Firebase; and when a promo code was removed, it would (in realtime!) collapse it from the list and display a new promo code at the bottom.
The mobile app code was also very simple. First, check if the promo code is available (one API call); if so, enable premium and remove the code (another API call).
The reason why it costed about $100 is because we had too many concurrent users: the Firebase free plan allows only 50 concurrent users, and at our peak we were seeing ~500. Since the promo was only for a day, we bought an expensive plan that got pro-rated for just that day.
It was an extremely successful promotion. [3] The final result was very interactive. It was amazing to watch the codes disappear in real-time. It was like a game: you had to be fast to enter the code, because the codes were being used so quickly.
All in all, I believe we made more money in people buying it anyways (despite the promotion) than it costed to serve it. And keep in mind we built the entire system in about 5 hours. And I'm not even a web developer. An actual web developer could have implemented this in an hour or two.
For reference here is the entire JavaScript powering the promo code website:
var all_codes = new Firebase("https://qksms-promo.firebaseio.com/public_codes");
all_codes.on('value', function(data){
$('#remaining').text(data.numChildren());
if (data.numChildren() === 0) {
$('#status').text('No more codes!');
}
})
all_codes.orderByValue().limitToFirst(12).on('child_added', function(data){
$('#status').remove();
var str = '<div class="code" id="';
str = str.concat(data.key());
str = str.concat('">');
str = str.concat(data.key());
str = str.concat('</div>');
$('#wrapper').append(str);
$('#'.concat(data.key())).hide().fadeIn(300);
});
all_codes.orderByValue().limitToFirst(12).on('child_removed', function(data){
$('#'.concat(data.key())).slideUp(300, function(){
$(this).remove();
});
});
[2] http://qklabs.com/qksms-promo/
[3] https://www.reddit.com/r/Android/comments/36eix7/dev_a_year_...
How so ? to me it makes development even more complicated, cheaper relative to hosting fees maybe, but simpler ? I don't think so. What if I want to use language XYZ not supported by lambda ?
Currently serverless is more expensive in the average case from what I gather, mainly since it's new and there's little competition.
Such problems can apply to any ready made solution. In general, a vendor product may or may not suffice custom needs and a user is free to build one from scratch. Abstraction of major pain points that fits a wide variety of user needs, if handled properly, can pave the way for a competitive solution.
Could you elaborate on this ?
I agree the size and complexity could increase, but so could the number features in the apps. Since all such apps would be reusing the same code base, wouldn't this increase abstraction and reduce implementation hours ?
Client -> post -> API Gateway -> AWS Lambda -> upload JSON to S3
Client -> get -> S3
Works pretty good!
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.
I honestly think people should learn to build standard apps the standard way - (SQL) database, application layer, html / view layer -then learn to scale the parts as needed. Its well understood. There are good frameworks and tools available and plenty of historical examples of how to do things.
Everyone seems to want to jump on the shiny new way of doing things as soon as they come out. I often ask peoples reason for choosing their architecture - "thats how we do things these days" or "relational databases don't scale" seem to be the standard answers.