Is Serverless Architecture Really Server Less?

What is Serverless? Before we begin, let's look at a very brief history of the WWW (World Wide Web). We're going to talk a lot about the web here because that's our world, and that's where we do a lot of our work today. 

Let's start with HTTP. At the beginning of every web address, there's this HyperText Transfer Protocol. It's the way our browsers, our computers, talk to servers to request information that they then respond to.

In a very simple form, that's what we're doing all the time, we're sending a request, and we will receive a response. Sometimes that request requires additional information, as if we are signing up for something. Sometimes a request requires our name, email address, etc., in order to receive a response that we are successful in obtaining the request. An example might be when one is requesting the price for a certain product on an e-commerce website and receiving that back. It's basically what the web does. To make that happen, we need a web server that's always ON.  These servers need to be able to cope with the huge number of requests and keep these servers updated with security patches, replace broken hardware, etc.

In the past, we have always spoken about a server in the physical sense. These days, we don't talk about things in those terms because we don't necessarily need to worry about those types of levels (shown below) with the advent of what we now know as cloud computing. So, if we're not using our own computers, what are we using?

It's the cloud. What can "the cloud" can do for us? There are varying levels of the cloud, which we will go through thoroughly in this article. 

What we discussed at the beginning of this article is a typical "On-Premise" solution that's handling everything for us. Then comes "Infrastructure as a Service" (IaaS), where the operator on our behalf takes over some layers, and we kind of run-on top of that, starting at an operating system level. 

Working up, we have "Platform as a Service" (PaaS), where we are just building the applications and data on top of someone else's infrastructure that they've put in for us. Then we have "Software as a Service" (SaaS), which is what most of us are more familiar with as the services we use, like any kind of web-based software, whether it's accounting or Facebook or any of kind of web tools that we're using where someone is looking after every element of that for us.

What Is Serverless? 

Essentially, we use a supported language, runtime, deploy the code, and point to some storage often, but not always hosted by the same cloud provider. That storage can be elsewhere, and then the provider worries about scaling. No traffic? no problem — the code just sits there unused. Heavy traffic? no problem — the code gets replicated quickly and responds to the demands, but the key is we're just giving the instructions, the code, and the rest of the infrastructure we discussed earlier is all dealt with by someone else.

So serverless in its actual sense means we use someone else's computer servers where we host our applications and run our businesses.

What Is Containerization? 

Containerization is serverless with a little bit more control. It’s a bit beefier than what you do with serverless. Serverless consists of very small, simple applications with few files involved in the software, but sometimes that isn’t enough, and we need something a bit beefier. Most of our work needs that, so we run in a containerized environment. We get to specify the base system we’re using in that container; we get to put all our code in there with the runtime and install many components into each container that we need to make whatever application it is running. We can also run many containers alongside each other, and if done right, it provides huge portability to move systems around.

So, one of the key things is portability. We don’t need to worry about what systems we’re running containers on because the container contains everything it needs to run. We can run on Windows or Linux, or Mac OS if they have access to a Unix kernel, which on Mac or Linux or Windows means they can run these containers on top of that. The developers now don’t need to worry about their setup anymore or how they’re going to direct the traffic around that machine. No need to worry about dependencies on each developer’s machine because the container itself has the instructions and all the information it needs. This makes expanding our capacity easy by just adding more nodes. If we’re doing this in a more traditional way of installing everything on our machines, that would be tricky to manage.

Efficiency is a big key as well, so for bringing up nodes and shrinking them back down again, we no longer need to think about dedicated servers and hardware. We are often very concerned about the kind of virtualization and limited resources, so we go down the kind of dedicated route or the co-hosted route to manage our own physical infrastructure. Containers are much lighter weight as they only contain the difference from kernel, which means more services running on fewer machines. This not only saves costs but also uses fewer machines saving power.

What Is a Container? 

Basically, containers run on top of a physical server, on top of an operating system, and on top of an engine. We get to share the physical infrastructure of the system, the baseline operating system, and the engine. The containers sit on top of that as layers within a container, they can use the things that are beneath, so they share kernels across the containers to use them at runtimes but can’t (easily) affect other containers because they run in isolation and only have knowledge of what you tell them.

So, what we’re able to do is create a kind of virtual machine environment where it is a completely isolated system off to one side but in a lightweight, quicker way of doing it where we don’t have to keep reinventing the wheel. We don’t need the full operating system in every single container. We’re not having virtual hard drives that contain entire systems.