Hi! I am a longtime developer with a passion to empower other developers to be their best. I focus on cloud development and everything related to data access from .NET and .NET Core.
If you're just dealing with the web, it's a valid question. Serverless is so much more than the web.
Serverless doesn't just abstract away infrastructure and provide scale, it also facilitates a streamlined development workflow. Although triggering code with an HTTP call (i.e. APIs) is the common use case, you can also trigger code based on other events.
I can trigger based on a timer and eliminate Cron jobs or Windows services
I can trigger based on a file upload and automate ETL processes without polling
I can trigger based on a queue and facilitate inter-process communication
I can facilitate inter-app messaging using a publisher/subscriber model without having to worry about the infrastructure and complexity of implementing a distributed transactional system
I'm not as familiar with other platform offerings, but Azure serverless provides bindings that make it easier to code. For example, if I want to populate a NoSQL database, I can specify the binding. Then, my code just constructs the document and returns it from the function. It is automatically inserted and I don't have to initialize a database class, parse a connection string, open a connection, execute an insert command, etc. - all of that is taken care of for me.
I recently created a serverless integration to Twitter using Logic Apps. Instead of dozens of lines of code to implement authentication, get a token, query the API, etc. I simply dropped a component for "Twitter search" onto my designer, filled out credentials, and everything else was handled for me.
By and far the biggest advantage of serverless in many cases is the cost. Most serverless (I believe this should be a requirement to call your platform serverless) bills on a consumption plan, i.e. you only pay when using. This can create enormous cost savings. I run a link shortener that processes thousands of requests daily. I store the short links and URLs in table storage, and use serverless code to create the short links and process them when users navigate. When a user hits a short link, I put a token on a queue and redirect the user. A separate process picks up the token and stores metadata for reporting. Finally, my integrations run and map referrers back to tweets so I can see how well the tweets perform. The entire cost to me monthly for this is just dollars, and that's with redundant storage that is replicated and prepared to fail over in the case of an outage.
So, I would say if you only view serverless as a way to stand up web endpoints, there may be better solutions. But serverless is so much more than that and absolutely a way for companies to implement solutions faster at a far lower cost without fewer resources.
If you're just dealing with the web, it's a valid question. Serverless is so much more than the web.
Serverless doesn't just abstract away infrastructure and provide scale, it also facilitates a streamlined development workflow. Although triggering code with an HTTP call (i.e. APIs) is the common use case, you can also trigger code based on other events.
I'm not as familiar with other platform offerings, but Azure serverless provides bindings that make it easier to code. For example, if I want to populate a NoSQL database, I can specify the binding. Then, my code just constructs the document and returns it from the function. It is automatically inserted and I don't have to initialize a database class, parse a connection string, open a connection, execute an insert command, etc. - all of that is taken care of for me.
I recently created a serverless integration to Twitter using Logic Apps. Instead of dozens of lines of code to implement authentication, get a token, query the API, etc. I simply dropped a component for "Twitter search" onto my designer, filled out credentials, and everything else was handled for me.
By and far the biggest advantage of serverless in many cases is the cost. Most serverless (I believe this should be a requirement to call your platform serverless) bills on a consumption plan, i.e. you only pay when using. This can create enormous cost savings. I run a link shortener that processes thousands of requests daily. I store the short links and URLs in table storage, and use serverless code to create the short links and process them when users navigate. When a user hits a short link, I put a token on a queue and redirect the user. A separate process picks up the token and stores metadata for reporting. Finally, my integrations run and map referrers back to tweets so I can see how well the tweets perform. The entire cost to me monthly for this is just dollars, and that's with redundant storage that is replicated and prepared to fail over in the case of an outage.
So, I would say if you only view serverless as a way to stand up web endpoints, there may be better solutions. But serverless is so much more than that and absolutely a way for companies to implement solutions faster at a far lower cost without fewer resources.
Yeah I totally agree with what you say... serverless is also meant for event driven programming.
That's what I'm actually saying: " why would you want to serve webpages using serverless while using servers is just simple and perfect for the job" 😄