A couple reasons to pick serverless over a traditional setup:
Managing servers (well) is hard and expensive.
Scaling is hard and expensive.
Fewer wasted resources (only paying for what you use).
(Theoretically) faster time-to-deploy but this definitely depends on your experience with the services.
Most of your bullet points were addressed by the whole idea of 'cloud servers' in the first place.
On AWS, i can scale in a few clicks ( and 2 minutes of downtime ).. and there are options to make my servers automatically scale without me even noticing. Same goes for other cloud providers.
Managing servers is hard and expensive? maybe. I suppose it depends on your case. There are so many tools to automate that stuff across your fleet.. i manage many linux servers and wish it was harder, because i'd be making a lot more money doing it, ha. But in reality, for general webservers, it's an hour a month of time i spend on them..
The only advantage in your list i see is.. 'fewer wasted resources'. This could be very true in practice, but i think auto scaling infrastructure can get you close enough to this benefit. 'Serverless' can be used to squeeze that last drop of cost savings by making your consumption of CPU time very, very granular.
However, i think this only makes sense when you are running a very large infrastructure, because there is a cost to dealing with potentially rewriting parts of your app into a quasi microservice format or deploying updates might negate some of the cost gains.
'serverless' would make a hell of a lot of sense to a company like Amazon, who would turn on a dime to find another 1% financial efficiency advantage over their competition.
Let me jump in. The idea isn't to choose something over something else. You choose the best tool for the job.
Here's an example. You want to resize an image on the fly, once it's uploaded to your S3 bucket. Configure an async event trigger from S3 to run a Lambda function, resize the image and put it back into the S3 bucket. This is done automagically, without you having to worry about it. It's better to be configured with a serverless architecture than a conventional server.
Another example. You have an API with huge I/O operations with heavy throughput and many database connections. You'd want a fast server running a language like Go to handle the concurrency. Having a traditional setup is superior in this case.
Do you get in what way we should be moving? Don't bring a shovel to a knife fight. :)
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
A couple reasons to pick serverless over a traditional setup:
Managing servers (well) is hard and expensive.
Scaling is hard and expensive.
Fewer wasted resources (only paying for what you use).
(Theoretically) faster time-to-deploy but this definitely depends on your experience with the services.
Most of your bullet points were addressed by the whole idea of 'cloud servers' in the first place.
On AWS, i can scale in a few clicks ( and 2 minutes of downtime ).. and there are options to make my servers automatically scale without me even noticing. Same goes for other cloud providers.
Managing servers is hard and expensive? maybe. I suppose it depends on your case. There are so many tools to automate that stuff across your fleet.. i manage many linux servers and wish it was harder, because i'd be making a lot more money doing it, ha. But in reality, for general webservers, it's an hour a month of time i spend on them..
The only advantage in your list i see is.. 'fewer wasted resources'. This could be very true in practice, but i think auto scaling infrastructure can get you close enough to this benefit. 'Serverless' can be used to squeeze that last drop of cost savings by making your consumption of CPU time very, very granular.
However, i think this only makes sense when you are running a very large infrastructure, because there is a cost to dealing with potentially rewriting parts of your app into a quasi microservice format or deploying updates might negate some of the cost gains.
'serverless' would make a hell of a lot of sense to a company like Amazon, who would turn on a dime to find another 1% financial efficiency advantage over their competition.
Let me jump in. The idea isn't to choose something over something else. You choose the best tool for the job.
Here's an example. You want to resize an image on the fly, once it's uploaded to your S3 bucket. Configure an async event trigger from S3 to run a Lambda function, resize the image and put it back into the S3 bucket. This is done automagically, without you having to worry about it. It's better to be configured with a serverless architecture than a conventional server.
Another example. You have an API with huge I/O operations with heavy throughput and many database connections. You'd want a fast server running a language like Go to handle the concurrency. Having a traditional setup is superior in this case.
Do you get in what way we should be moving? Don't bring a shovel to a knife fight. :)