Serverless Architecture

As a developer, there is perhaps nothing greater than seeing a project that you developed fully functioning. You fought through all the bugs, spent countless hours on Google and Stackoverflow figuring out how to implement that new feature, and even sprinkled in some nice CSS and jQuery to make it look beautiful. But then the realization of deployment hits. All your great work and now you have to fight servers and databases and whatever PaaS you choose all in hopes that someone else besides you might be able to appreciate your work of art.

On top of that, what happens when you have to push updates? How do you know which of the million different sizes of virtual machines you should choose? Is the specific server you chose going to be able to handle the workload? What will you do when your project becomes so wildly popular that you need to start scaling it up? And what is your server doing when it’s not handling requests?

Unless you have a team that is dedicated to managing all the infrastructure of your application, this can seem an impossible task. Thankfully we are now seeing the emergence of “serverless” architecture. To understand how this is working let’s first take a step back and take a look at a traditional server.

serverless architecture graphic 1

In a traditional web server setup, the server essentially sits and waits for a request to come in. Once it receives a request, it will process the request and send an appropriate response. When the response has been sent, it sits and continues to listen for another request. This is an oversimplified description of the process, but it serves to highlight a major problem with this system. What does the server do between requests? The answer — nothing. Not only is it doing nothing but you’re being charged for the time that it is sitting and doing nothing. All of which leads to why serverless architecture is a game changer.
serverless architecture graphic 2
Despite the name “serverless,” there are still servers involved in this process, but it works a little differently. For this example, we will use AWS infrastructure.  When a user requests a serverless app, instead of going straight to a server it first stops by AWS API Gateway. In this scenario, your domain name would be pointed at the API Gateway instead of at an individual server. Once the API gateway gets the request, it will trigger the Lambda function. This is where the magic begins. As part of the triggering of the Lambda function, a temporary server is created. Once the server is created, it will handle the request, and send a response back to API gateway. As part of the finishing of the Lambda function, the server will then be torn down, and API Gateway will send the response back to the user. Despite the fact there seem to be a few more moving pieces here, there are some big advantages that this setup provides.

  • We don’t have to worry about scaling. Each time a new request comes in a new server is created that will handle that request. In essence  500 requests = 500 microservers. If you have a burst of traffic — you’re fine if there is a lull — you’re fine. No more setting up and tearing down servers or writing complicated scripts to handle the workload.
  • No server maintenance is required. With a serverless set up you don’t have to worry about provisioning servers beforehand. You don’t have to worry about staying up to date with operating system updates or security patches. And you don’t have to worry about what type of server or VM you should use.
  • You can focus on building. Perhaps the most compelling reason to switch to a serverless architecture is that you can spend more of your time developing. The reason you build websites and services is to provide value to your customers. Fewer time focusings on infrastructure mean more time for creating value for your customers.

The number of languages and frameworks that are being used in serverless are continually increasing. As this setup increases in popularity, the number of services available will also increase. Currently, about 82% of these serverless functions are HTTP related. Meaning there are other projects such as scheduled jobs, SNS, S3, etc. that are using serverless architecture, but currently HTTP is the king. What languages are these functions using for their runtime environment? Node is the clear leader with about 75% followed by Python which accounts for roughly 15%.

While there are still some issues with serverless, there is no doubt that this is the way of the future. If you would like to see more statistics or dive deeper into the wonderful world of serverless, I would suggest starting at serverless.com to gain a deeper insight and maybe even try out an example or two. Happy Coding.

dojo guide

Looking for a Career in Web Development?

Read our quick-start guide to becoming a Developer

  • Includes exclusive insight from a seasoned Web Developer
  • Uncovers the top career misconceptions holding you back
  • Highlights the must-have qualities all employers require
  • 89,615 downloads to date

5 thoughts on “Serverless Architecture

  1. An amazing article. It’s nice to read a quality blog post. I think you made some good points in this post. A serverless engineering is an approach to fabricate and run applications and administrations without overseeing framework.

  2. Thanks for the in-depth writing on this topic and I have learned a lot. Really I appreciate the effort you made to share the knowledge.

  3. Serverless technologies open a lot of benefits to most of the DEVs. The scalability, cost-effectiveness, and compatibility with existing cloud applications are all unparalleled.
    Finley || rookout.com

  4. Nice it seems to be good post It will get readers engagement on the article since readers engagement plays a vital role.

Leave a Reply

Your email address will not be published. Required fields are marked *