Serverless Architecture- Why and How It’s a Smart Choice?

According to a recent report from Gartner, more than 20% of global enterprises will have deployed serverless architecture by 2020.

This clearly suggests that serverless is a lot more than a buzzword now. It’s a known cloud computing trend and has already started to revolutionise the world of software architecture. Big vendors, like Amazon, Microsoft and Google are investing heavily in serverless architecture to achieve .

As opposed to its name, a serverless architecture does not actually remove servers from the application. Let’s look at the definition of serverless.

What is Serverless Architecture?

Serverless architecture refers to applications which heavily involve the use of functions and third-party services and do not involve managed servers. There are two main aspects of serverless architecture

• FaaS (Function as a Service): Stateless functions containing server-side business logic. These functions are run in independent containers and are event-triggered. These functions are fully managed by third-party providers, such as AWS lambda or Azure functions.
• BaaS (Backend as a Service): This involves using third-party services to achieve the means, for example, firebase, Auth0. The applications utilising BaaS are typically client-rich applications such as SPAs or mobile apps. The client handles most of the business logic with the help of external services like authentication, database, user management etc.

Although serverless involves both BaaS and FaaS, we’ll focus on FaaS here.

Characteristics

• Eliminates server management altogether
• Stateless
• Scales automatically
• No operational cost
• Cost is driven by events
• Needs a startup time for the first event
• Secure due to it’s small runtime nature

 

Life Cycle

Following diagram depicts the life cycle of a function-

Example Application Architecture

Let’s consider a simple online vehicle auction application. The application allows people to log in and place their bids. When the time ends, the highest bidder is sold the vehicle.

Traditionally, the architecture will contain a monolithic server containing all the application code and hosting the frontend.

Above architecture utilises thin-client approach. All the business logic, like authentication, session management, vehicle management etc, is sitting on one big monolithic server.

Let’s see how this application would look with serverless and microservices based architecture.

Here we have broken up the monolithic application into multiple server components.

• Authentication function: This is a Function (FaaS) for managing user authentication (login).
• Vehicle management service: A microservice for handling the vehicle-related operations like listing vehicles, viewing vehicle details, comparing vehicles etc. This service could be written using any language/framework. This service will interact with the database and will operate independently.
• Vehicle bid function: This is another Function (FaaS) which will be used to place bids from users. This function will also interact with the database to register the bids.
• API gateway: This acts as the entry point and reverses proxy for all the services. Call from client land here and then the gateway decides which service to redirect to based on routing rules.

There are multiple factors which impact the decision of breaking up the service and creating different components like a microservice or FaaS. These include business logic, load, scale factor etc.

The above example demonstrates the thought process behind using serverless and how an application can be designed utilising the microservices architecture with serverless.

Serverless vs. PaaS

Platform as a Service is another offering from cloud providers which does not involve any server management (both hardware and software) from the developers of the application. And due to this fact, there is a notion among developers that serverless and PaaS are not different. Let’s look at the similarities and differences

Similarities

• There is no server management involved in the developers’ end.
• Developers just need to focus on writing application code.

 

Differences

• PaaS offers more control over the way you can deploy your application. But serverless if very opinionated and restrictive for deployment.
• Serverless scales automatically whereas PaaS deployment needs to be configured for scaling.
• Cost of serverless is driven by events as compared to the fixed cost in PaaS.
• Once the code is deployed, the PaaS application is always up and ready to serve the request. In the case of serverless, it might take some time for the first event to start processing, depending on the frequency of events.

 

Use Cases

The use cases for serverless are not limited to a domain, business or architecture. You need to take into account multiple factors while creating the architecture of your application, and the same factors will impact the decision to use serverless. Let’s take a look at some of those factors

• Cost – Serverless can be very cost effective depending on your load. If you have an ad hoc service, like sending emails.
• Server management – Serverless can greatly reduce the operational cost of managing the servers.
• Scaling – Serverless scales automatically
• Response time – It takes some time for FaaS to initialise. If the load a very less (like one event per hours), each request will encounter this cold start, resulting in slower response times overall.
• Faster release cycle – Since these functions are very small units, the release cycle becomes very small.

 

Following are some of the common use cases

• Web applications
• Batch processing and schedulers
• Mobile and IOT backend
• Chatbots

 

Why Serverless?

Let’s take a look at some of the benefits of using serverless and FaaS

• Reduced server management
• Reduced operational costs
• Automatic scale up and scale down
• Security is better compared to always running services
• Cost is driven directly by the number of requests/events served
• Simpler packaging and deployment
• Reduced release cycle
• Out of the box monitoring

 

Limitations

As with any technology or architecture, serverless also has some limitations

• Startup latency
• Vendor lock-in and reduced control over the servers
• Performance optimisations are limited to code
• Capped execution duration (like AWS lambda has 15 minutes of capped execution time)
• The cost can be unpredictable
• The difference in development and production environment
• Complexity in testing and debugging

 

Winding Up

Serverless is an architectural style, which involves using FaaS to move the business logic from long-running server components to ephemeral functions. It can answer many of the architectural and operational questions, simplifying the life of developers as well as operational guys.

And as with other solutions, it’s not the silver bullet. It can not replace all of your existing components. The decision to use serverless should involve a careful analysis of business and technical requirements, taking into account all the pros and cons.

Serverless is surely gaining a lot of traction and is certainly ready for widespread enterprise adoption. We at Systango help businesses that are keen to kick-off their serverless journey. The assistance of our team results in enhanced process agility and reduced operational cost. 

Systango has a proven track record of creating applications in various technologies – python, react, full stack etc. We have an in-depth understanding of serverless architecture and have delivered many applications using it.
Wish to find out more about Serverless Architecture and how your infrastructure can leverage its advantages? Contact us here!

 

Reference starter kit with node.js

Serverless Node Simple CURD
Serverless Node Simple Messaging
Serverless Node Simple Image Resizer

Reference starter kit with Ruby on Rails

Serverless Ruby Simple CURD
Serverless Ruby Simple Email
Serverless Ruby Simple SMS