Professor Prolog Explains Serverless Hosting 2022
Julia strikes the like button and bookmarks the web application tutorial she completed. She quickly scan the classroom and feels quite proud of being the only one who has finished yet. Eager to learn more she speaks up.
👩🦰 Professor Prolog, could you tell me more about how to host a web application?
Professor Prolog shines up and gets up from his chair.
🧑🏫 Of course, Julia, I will tell you all about it.
Prolog starts drawing boxes on the whiteboard, he knows every engineer loves lines and boxes.
🧑🏫 First of all, remember that there's both a client and a server you need to host...
One of the elder students, Ada, interrupts the professor.
👱♀ But there are serverless applications today, aren't there?
Prolog nods to Ada and starts over.
🧑🏫 That's true, Ada. There are a lot of serverless applications today, but they aren't technically serverless. There are still people setting up the servers and hosting them on physical server halls around the world. They are only called serverless because you don't have to manage the physical machines on your own, you only need to provide the code you want them to run and take care of configurations.
👩🦰 Isn't that the same as hosting then, Julia asks. In our tutorial we uploaded our code to Firebase, is our application serverless then?
Prolog hesitates and puts down the pen he held in his hand.
🧑🏫 No Julia. Or yes... Kind of. But not exactly. What you did in the tutorial was to upload the javascript client application you built to Firebase's servers, so they can make it accessible on the internet. We usually refer to that process of serving it from a computer to the internet as hosting. Since you never uploaded it to a server of your own, you have technically hosted it serverless. But even if you uploaded it to your own server, we would still call it hosting, but we would instead say you have hosted it on-premises.
👩🦰 Oh, I see. I think I get it. And the server we hosted on AWS is serverless?
Professor Prolog nods in agreement, grabs the pen again and starts writing on the whiteboard.
A student far back in the classroom, Jade, adjusts his glasses and squints because he can't see sharp.
🧐 What does it say?
🧑🏫 Load balancing, it says load balancing.
Prolog draws multiple boxes on the whiteboard, each one of them representing a server. He draws a user as well and some lines in between them, all connected with another box labeled load balancer.
🧑🏫 Does anyone know what a load balancer is, he asks.
A student explains that load balancers are used to balance the workload between multiple servers when the server code runs on multiple servers.
Prolog nods quietly.
🧑🏫 You see, there are different ways to host a serverless application. Two of the most common options are IaaS (Infrastructure as a Service) and PaaS (Platform as a Service). The latter one is what you used in the tutorial when you hosted the server on Elastic Beanstalk. The process was very much like hosting your React client on Firebase. There were a few extra things to consider, but in essence you simply uploaded code and it ran successfully. What happened under the hood was that Elastic Beanstalk automagically spun up a load balancer and a bunch of servers.
🧑🏫 One remark there, Prolog continues. When you configured Elastic Beanstalk, you also enabled something called sticky session. Sticky session, or session affinity as it is called as well, ensures that when a user uses your client, all requests sent from that specific client to your server always will go to the same machine if the server are hosted on multiple machines. That is not always necessary, but in your case it was. You will need that kind of behavior if your server stores data in memory or on a local disk and you need to access that data on a subsequent network request. Forgetting to enable sticky session would result in inconsistent behavior for the server, since only requests sent to the machine that stored the data would be able to find it.
A student suddenly sneezes loudly and wakes another one that has almost fallen asleep. Professor Prolog makes a pun about the student needing a cup of Java and sends away the students on a break.
Break is over. Students are back at their seats. Professor Prolog moves on to talk about load balancers and IaaS.
🧑🏫 We were saying a PaaS automatically spins up a load balancer and some servers. When dealing with an IaaS, you have to do that work yourself. With an IaaS, you get machines you can use as servers. By putting an Nginx server or an AWS Load Balancer on one of the machines, and running the server code on the other servers, you have loosely spoken built what a PaaS does. What probably is missing is a system to automatically scale the number of servers you run. Although, exactly what a PaaS offers varies between different providers.
Professor Prolog glimpses at the clock on the wall and erases his drawings on the whiteboard.
🧑🏫 You have learned a lot about hosting web applications this hour. It's far from everything there is to know, but it's an accurate overview of some of the most common and fastest ways to host applications. If you are interested to read more about the differences between IaaS, PaaS, and SaaS, I have included a link in the lecture material. You can also read about what it means to split a backend into microservices.
Professor Prolog animates his opacity and fades away...
