Serverless: An Emerging Software Architecture

In our journey of being a software developer, while working with traditional 3-tier architecture application, we all have faced issues like creating/setup server, install operating systems and required software, manage and maintain server, design application with high availability and fault tolerance and also manage load balance, etc. which in turn may incite extra cost on infrastructure resources. These monolith applications have some drawbacks – highly dependent, language/ framework dependent, enhancement challenges, scalability.

To overcome these shortcomings of monolith applications, some microservices provide an architectural model to develop applications with language-independent, selective scalability, easy enhancement, and independent deployments feature.

In this article, primarily focus on the understanding of Serverless first, then focus on the Serverless architecture, and then we will discuss the Serverless design principles. But first, let us start with some technical journey from Microservices to Serverless.

What exactly is a microservice architecture model?

According to James Lewis and Martin Fowler, when a single application is developed in the form of a suite of small services where each service seems to be running in its process and communicating with lightweight mechanisms, more like an HTTP resource API, it is known as a microservice architectural style.

One can easily write in different programming languages and use different data storage technologies as there is a bare minimum of centralized management of these services. These services are mainly built around business capabilities and independently deployable by fully automated deployment machinery.

So here is the basic understanding of monolith architecture and microservices architecture.

Microservices also have some shortcomings like managing distributed systems itself has challenges, high infrastructure provisioning to maintain scalability and availability.
However, using microservices and running more servers with multiple environments can be quite a cost-effective venture. In this case, the cost to the developer remains the same whether the servers are busy or sitting idle. But the good news is, the cost concern is not the case with serverless, here you only pay for what you use.
Now let’s start with Serverless architecture.

Serverless architecture as the name suggests, its serverless but that doesn’t mean there is no server involved. Your application still runs on a server but you don’t have to create/setup and manage your server, you have to just focus on code and everything else will be taken care of by serverless providers.

A serverless application has similar characteristics as a microservice, but there are some differences too.

Microservice is larger and can have single or multiple functions to act while the serverless application is based on the event-driven function that is a small bit of code to act.

Let’s dive into serverless architecture.

What is Serverless?

Serverless computing or in simple words Serverless is the most popular architecture in the software industry at this time. This architecture leverages developers from the burden of managing and maintaining servers and backend infrastructure issues like physical capabilities, limits, and complexities. It allows developers to focus their energy on the core functionality of the applications. By adopting a serverless compute service and making use of various single-purpose APIs and web services, developers can build loosely coupled, reliable, scalable, highly available, and fault-tolerant applications with ‘faster time to market’.

As an evolving software architecture, there is no perfect explanation of what ‘Serverless’ is. On a higher level, it encompasses two different but overlapping areas:

Backend as a Service (BaaS): Initially Servers were used to describe applications or manage server-side logic that significantly incorporated third-party or cloud-based applications and services. For example, mobile apps or web applications that are feature-rich and complex UI.
Function as a Service (FaaS): Serverless can also mean applications in which server-side logic is written by developers itself but it runs in stateless compute containers which are event-triggered and ephemeral(may only last for one invocation)/short-lived and fully managed by serverless providers. This architecture allows apps to call a function on demand. It is useful as it provides flexibility for server-side applications.
Benefits of Serverless architecture :

• Stateless
• Event-driven
• 3Distributed
• Easy and efficient scaling
• High availability
• Easy deployment
• Low cost
• More time for development
• Reduced latency time

Serverless Design Principles:

Before starting a custom software development using a serverless architecture, you should know some basic principles of Serverless architecture which will guide you to more efficient, cleaner, and manageable server implementations. Apply these principles (whichever applicable) while developing a system (with both back end and front end) using serverless.

On-demand execution :
A Serverless computing service like AWS Lambda, Azure Functions, Auth0, or Google Cloud Functions must be used to deploy and execute functions. You need not run or manage any servers, or containers of your own. Serverless providers manage functions/code execution on demand.

Stateless single-purpose functions:
While working with serverless architecture, you need to keep in mind that a function should perform a single task by following a single responsibility principle.

It is always easier to write, debug, and test these types of functions as they are small, separate, units of logic. Although functions can be invoked directly, yet usually they are triggered by services built around them.

Push based, event-driven pipeline:
You can use a serverless compute service to orchestrate actions between different services. Also, have you given a thought about building an app in such a way that creates event-driven pipelines and wherever possible avoid polling or manual intervention? It’s worth doing.

Heavy and powerful front end:
In serverless architecture, there can be complex or heavy UI to manage customer requests or interactions. So the front end should be smart enough to directly communicate with the services to reduce the number of serverless functions. There may also be situations where the front end has to directly communicate with serverless functions due to privacy and security reasons.

Use of third party services:
Before the code is written for the requirement, first look for services created by others which may fulfill the requirement along with assessing risk factors with third-party services. If you apply this principle, this will reduce your application development time.

Conclusion

Serverless architecture or serverless computing can be summarized as a model in which:

Serverless providers manage dynamic allocation and provisioning of servers,
Applications run inside stateless containers with high scalability,
The function execution is event-driven,
Applications are composed of smaller deployable units resulting in faster delivery of features in the market,
Reduced cost as pricing is based on the number of executions and not on pre-purchased compute capacity.
Although serverless has so many features that help developers to focus on code and early delivery of the project, yet some pitfalls also need to be taken care of before choosing serverless architecture for your application development.

From a business perspective, as serverless architecture is fully managed by third-party providers, there is less control over server-side and more risks involved.

Also while choosing a serverless provider, we need to take care of vendor lock-in too.

From a developer perspective, you may find serverless architecture a little bit complex. As this architecture focuses on smaller units of code/ single-purpose functions, this may take time to assess and implement the functions for large applications. Also, it might get difficult to manage too many functions, and then ignoring granularity will end up creating mini-monoliths. Along with this, developers are dependent on third-party providers for monitoring and debugging tools, and sometimes they might find a lack of operational tools.

In nutshell, the popularity, validity, and success of architecture depend on the business requirements (and not merely on technology). In the same way, Serverless can gleam when used in the proper place.