One of the biggest technological advances in this decade is the usage of machines hosted by server giants like Amazon and Google for our businesses, in the form of AWS and Google Cloud Compute. Not only do these companies offer machines, but they also offer specific services such as databases, service to send SMS, online development tools and backup services. These services are collectively referred to as PaaS or Platform-as-a-Service.
Over the last two years, another new concept has rapidly caught, mainly thanks to Amazon’s Lambda. We call this FaaS or Function-as-a-Service, where instead of running an entire software program or a website throughout the day, we simply run a single function, such as sorting a list of million names or converting the format of 50 videos from MPEG to AVI, etc on a remote machine which stays on for only the duration of the time that our function runs and then shuts down. By not keeping machines running all day, maintenance and operational costs go down significantly. This particular way of running machines for a specific short-term purpose and then shutting them down is now termed as ‘serverless’ architecture.
Why serverless architecture?
A traditional online application has two pieces: a client that is used by the users of the application, such as the web pages on a website, a mobile app, a phone call (call centre application) or software that listens to the microphone. The second piece resides on a server machine. The server is kept on 24/7, so that it can listen for requests all day. Whenever a request arrives, the server processes it and returns a response.
Whether to keep a server machine on all day is a dilemma. A server is required to respond to requests at any time of the day. But for most businesses, there are times during the day when there are no requests at all. But companies cannot take a chance by shutting down the servers unless they are absolutely sure.
To maintain servers all day, they need to have admin staff that is in charge of the upkeep. This staff is knowledgeable at maintaining servers securely and at peak performance. This capability requires skills different from those of software programmers.
Secondly, companies may create server machines for functionality that is too niche, e.g. video conversion or calculation of daily statistics from millions to billions of website visits. These operations are processor intensive, so they cannot reside on the same machines as the company’s regular website, since the website may slow down when the intensive operation takes place. But a new machine running 24/7 for a niche operation that takes place only at certain times of the day looks like an overkill and increases costs.
Serverless architecture and FaaS solve this problem by creating a machine just for the duration of the operation and then taking the machine down when the results are published.
How serverless architecture works
It starts with a software programmer writing a piece of code that runs something very specific, but processor intensive. E.g. Converting 50 to 100 videos from MPEG to AVI at the same time, calculating the daily sales figures from billions of individual sales records.
Instead of uploading this piece of code to a dedicated company server, the programmer uploads the function as a FaaS to a serverless architecture provider, e.g. Amazon Lambda or CloudFlare.
Next, the programmer sets up a trigger on when to execute the FaaS. It can be during a specific time of the day or when a user specifically requests a URL dedicated to the intensive operation. The time of the day or URL triggers the FaaS and assures the user through some communication that the results will be available later. E.g. an email or SMS will be sent when the operation is triggered and also when results are ready along with a hyperlink to the results.
Advantages of serverless architecture
The company owning the software does not have to set up a server running all day to service intermittent requests. Also, if the demand for the service goes up, then the company does not have to worry about creating multiple servers for peak time and then shutting them down during off-peak hours.
Disadvantages of serverless architecture
The concept of serverless architecture is tied to a specific vendor. To go serverless on your end, you need to trust a third party vendor, e.g Amazon Web Services, Google Cloud, CloudFlare, etc., will do it for you. This means that your code or the setup for automation need to be written for a specific vendor. Should you ever decide that you do not like one service and that you want to migrate to another, you will at least need to perform a tedious setup with your new vendor. Sometimes, even your code changes significantly.
Can I set up my own serverless architecture?
Let’s step back and understand why serverless architecture works. By relinquishing the need for a server, you have nothing on your end that detects when the request for an intensive operation arrives. You have handed off that responsibility to the vendor of your serverless architecture. Which means that while you don’t have a server on all day, your vendor does. Let’s call this server X. Server X listens for requests for your intensive operation and creates another server Y that will be on only as long as the intensive operation needs. While server Y shuts down, server X has to run so that it can keep creating machines and shutting them down all day.
To make your own serverless architecture, you need a server that runs all day with the sole purpose of creating and shutting down other servers. That defeats the purpose of a serverless architecture.
Serverless architecture has revolutionised the way companies make software and host them. By having dedicated machines that simply serve one request and then shut down, the cost of operations is reduced too. However the solution is vendor specific and not very easy to migrate. You should evaluate your software’s true need for serverless architecture and your relationship with your vendor carefully before jumping in.