Serverless came for the sake of dealing with unusual spikes especially for functions that you know they will kill your server if they exceed a certain threshold.
That being said, that lovely nginx server (which has great caching) and adding CDN in the middle between your server and the user will give you a website serving hundreds of thousands of users (if not millions).
So, what's the point of going serverless for the frontend techs?
Aside from that, developing and debugging serverless isn't that pleasant, so why?
I'm not saying serverless is bad, it's really doing great dealing with specific functions that have problems with scalability... but, for the frontend techs, just why?
A done-right setup on a digital ocean $5 server would take up to 50K users daily, and you do the math... so yeah it's cheap.
But before all that, do you expect to serve million users without paying at least $50 per month for servers? If you have a daily million users, you better make loads of money then 😉
Do you also consider the cost of teaching/finding developers to do serverless?
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.
Serverless came for the sake of dealing with unusual spikes especially for functions that you know they will kill your server if they exceed a certain threshold.
That being said, that lovely nginx server (which has great caching) and adding CDN in the middle between your server and the user will give you a website serving hundreds of thousands of users (if not millions).
So, what's the point of going serverless for the frontend techs?
Aside from that, developing and debugging serverless isn't that pleasant, so why?
I'm not saying serverless is bad, it's really doing great dealing with specific functions that have problems with scalability... but, for the frontend techs, just why?
Where do you install and run your Nginx ?
You mean, if i run my Nginx on a server with 2GB RAM, it could serve million of users ?
A done-right setup on a digital ocean $5 server would take up to 50K users daily, and you do the math... so yeah it's cheap.
But before all that, do you expect to serve million users without paying at least $50 per month for servers? If you have a daily million users, you better make loads of money then 😉
Do you also consider the cost of teaching/finding developers to do serverless?
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" 😄