Thinking Serverless

The cloud technologies and cloud related terminology became favorite topics in our life. Lots of companies and platforms are migrating to cloud systems or thinking to migrate. Humble developers are trying to learn cloud and even shameless ones are also getting cloud related certificates. In this post, I am going to try to explain a new concept named Serverless as much as possible in my words.

Serverless is one of the newest terms in software world and I think It will be one of the most popular one in short term. As a new topic in our life, It is a very common mistake to think Serverless word means that there will be no server in the solution. It is a perspective change on involvement of server management in the application implementation and a new abstractions above servers. Beside this, We have already PaaS (Platform as a Service) and IaaS (Infrastructure as a Service) and this is not a new idea either.

Let me use the definition made by Sam Kroonenburg to describe what the Serverless is in a historical way;

1. When we started using data centers, the hardware was the unit of scale and the physical hosting environment was abstracted away.
2. With IaaS the operating system was the unit of scale, and the physical hardware was abstracted away.
3. With PaaS the application was the unit of scale, and the OS was abstracted away.
4. With Serverless technologies the function is the unit of scale and the language run-time is abstracted away.

So we can say that the majority of the stack (scalability, load balancing etc) is out of the responsibility of the team (cloud vendors are on charge) and we need to focus on our code base and implementations. Serverless architectures retain all of the traditional benefits of PaaS and add more benefits;

• No servers to manage, no OS to configure or no security patches
• Scalability is solved by vendors
• Fault tolerance is solved by vendors
• All of the infrastructure is code-defined so it becomes another component of the applications

Additional to the benefits directly touches to the life of development teams, Serverless has also soft benefits;

• Lower costs as costs are scaled per request in Serverless products of clouds
• Configuration and deployment are simplified so the DevOps teams can focus on automated pipelines and other software quality processes

AWS is the first vendor created functions and services for Serverless architecture. The Lambda is the key product for Serverless in AWS domain.It is cloud function that lets you run code without provisioning or managing servers.

A Serverless architecture needs more products than just a cloud function. In AWS, a Serverless architecture may consists of the following AWS products:

• Lambda: It is a function that you upload your code and it runs when requested as an isolated container, with as much concurrency as you need.
• API Gateway: It is an HTTP endpoint to make your functions into Restful services. You can implement authorization and authentication on API Gateway.
• S3: It is an object storage with a service and web interface. Additionally It can be used to serve static web content.
• RDS/Auro/DynomaDB: Database solutions to persist application data

We can also add many products to the list on AWS including mobile services, messaging queues and analytic tools. Similarly, Google Cloud and Microsoft Azure have also services and products that can be used to set up Serverless architecture.

A Sample Application

Lets think on an application and design it on both traditional and Serverless architecture to understand the concept and benefits. Imagine you are asked to build an application that;

• fetches the product data from various sources
• lists the products
• has a custom search functionality
• directs user to the cheapest store to buy the product

In traditional way, we would probably make a design as follows;

• Load balanced EC2 instances serving front-end application and API
• Front-end application and API can be programmed with PHP, Java or whatever
• Front-end is for users and API is for data sources to update the data on the application
• Static file serving (images, css, js) behind CDN
• RDS instance for database
• A separate EC2 instance for search database (maybe running Solr)

In Serverless way, our design might be;

• Front-end application can be built with a single page application technology such as AngularJS and served by using S3 service
• API can be built with API Gateway as proxy and Lambda as function
• S3 can be also used for bulk data import from data sources by triggering Lambda function
• Cloudsearch can be used for search service and data import can be done with Lambda functions triggered by API or S3

To sum up, the fundamental idea behind the Serverless is that the services you used and your code run in isolated containers managed by vendors. So you don’t need to worry about container orchestration, OS configs, or the underlying servers. Performance and scalability concerns are also resolved by the vendors.

I tried to share my personal ideas about Serverless architecture and I hope I can give you a starting point that you can start to architect your next solution with Serverless.