Pros and Cons of Serverless Architecture

Technology waits for no one.

 

When you finally get used to using a certain tool or architecture, and then a new one comes out, do you have to start all over again? This can lead to a difficult situation where you may become apathetic, as it can result in large-scale restructuring or code refactoring.

 

If you were to finish the current migration and start over with a new product in a few years, how would you do it? It's not an easy task and would require investigation and consideration.

 

Ultimately, if we are able to provide our customers with excellent service, it may not make much sense to consider such significant changes. On the other hand, if we reject innovation, we may remain stuck in the past. However, it is in these moments that technology can make dramatic leaps towards a better and brighter future.

 

And when we see words like "serverless architecture" popping up everywhere, it comes to mind.

 

If thinking about change gives you a headache, we recommend considering the following words: "Composability is the most important aspect of web architecture."

 

Personally, I believe so. When considering how my front-end application is structured and how many organizations have successfully transitioned from traditional monolithic architecture patterns to decoupled microservice architecture patterns, it is clear that there is a direct roadmap to serverless architecture. By the end of this article, I think you will understand it too. Let's analyze what serverless architecture is, its pros and cons.

1. What is Serverless Architecture?

First, let me explain what serverless architecture is.

 

Serverless architecture is not a replacement for microservices, nor does it mean there are no servers. In fact, cloud service providers handle server infrastructure and both microservices architecture and serverless computing can work together or separately within the same application.

 

There are various types of cloud services, and it can be difficult to determine what constitutes a serverless architecture and where the boundaries lie.

 

Many people consider serverless to be Function-as-a-Service (FaaS), and in its simplest form, I think that is certainly true.

 

FaaS is a subset of serverless, also known as serverless functions. These functions are triggered by events such as when a user clicks a button. Cloud service providers manage the infrastructure for these functions, so literally all you have to do is write and deploy the code. Communication between the front-end and serverless functions is just as simple as making API calls.

 

Cloud services for serverless computing were first introduced by Amazon Web Services with AWS Lambda in 2014. Other popular FaaS offerings from cloud vendors include the following:

 

• Netlify Functions
• Vercel Serverless Functions
• Cloudflare Workers
• Google Cloud Functions
• Microsoft Azure Functions
• IBM Cloud Functions

 

Cloud vendors offer many other services that are often confused with serverless.

 

• IaaS（Infrastructure-as-a-Service）
• Platform-as-a-Service（PaaS）
• SaaS（Software-as-a-Service）
• BaaS（Backend-as-a-Service）

 

These technologies are each independent topics, and this time we will explain a high-level overview of serverless, so we will not go into detail. However, what can be said in common is that the cloud service provider takes care of all the infrastructure of the service, so the customer does not need to worry about it.

 

In other words, by reducing time, resources, complexity, and cost, we can focus solely on applications and customer experience.

 

This is originally what "A" means in Jam (stack), and it is also a fundamental advantage of the MACH (Microservices, API-first, Cloud-native, Headless) ecosystem, where serverless architecture often plays a crucial role.

2. Why do we need to adopt serverless architecture?

Serverless and related cloud services are still relatively new, but every year new technologies are released to the market and they are making remarkable progress.

 

However, serverless computing, while offering many advantages compared to traditional architecture, is not a panacea.

 

As with anything, there are also reasons why serverless architecture may not meet the requirements.

 

2-1 Advantages of Serverless Architecture

Serverless computing, which does not require server management, runs on servers, but those servers are managed by cloud service providers. Server management is completely unnecessary, and options such as scaling, optimal availability, and elimination of idle capacity are possible.

 

There are many ways that serverless services can help reduce costs. In traditional server architecture, applications typically need to predict and purchase more server capacity than necessary in order to avoid performance bottlenecks and downtime. With serverless, the backend services are triggered by events and the code is only executed once, so cloud service providers only charge for the amount used. Additionally, server overhead and maintenance are handled by the provider, eliminating the need for IT experts such as developers to spend time on them. Just as cloud computing can greatly reduce hardware costs, serverless can also greatly reduce human costs.

 

Applications built with serverless architecture can infinitely and automatically scale. There is no need to worry about website downtime or performance issues due to high traffic, like with fixed servers. Of course, costs will increase as the number of users and usage increases.

 

In many articles about security serverless architecture, I have seen security being mentioned as a disadvantage. However, top cloud vendors are dedicated to providing the most secure, high-performance, and available services. As this is a crucial element of their business model, it is only natural that they hire the best talent in the industry to create and maintain their services, and of course, they also provide absolute best practices. While developers must consider the security of the application itself, a large part of this is taken care of by industry experts, which I believe is a significant advantage.

 

Building a development environment is easy and does not require server management, leading to shortened delivery times and rapid deployment. This is especially important for Minimum Viable Products (MVPs). Additionally, everything is decoupled, allowing for the freedom to add or remove services without having to make extensive changes to code like in monolithic applications.

 

Thanks to Content Delivery Networks (CDN) and edge networks, serverless functions can now be executed on servers closer to end users around the world, reducing waiting times. Some examples of Jamstack edge computing providers include:

 

• Cloudflare Workers
• AWS Lambda@Edge
• Netlify Edge
• Recently, Vercel Edge Functions have been used.

 

2-2 Shortcomings of Serverless Architecture

It is possible to choose and use various vendor services, but since the methods differ for each vendor, the easiest way would be to use a single cloud service provider such as AWS. Therefore, if you migrate to a different provider, you will always be completely dependent on the vendor that provides the best service. If there is any infrastructure issue, you will have to wait for it to be resolved.

 

In many cases, multiple clients' code is constantly running on the same server. This is achieved through a technology called multi-tenancy, which means that each client is only able to access their own share of the server. Therefore, there is a possibility of data leakage due to server configuration errors.

 

Serverless computing is not always running. When calling a function for the first time, a "cold start" is required, which means that the container needs to be spun up before executing the function. This may cause a decrease in performance, but the container will continue to run for a certain period of time after the API call is completed, allowing for a "warm start" without adding latency. Additionally, thanks to edge computing, the issue of cold starts is becoming less common and should continue to improve over time.

 

As cloud service providers manage backend processes, visibility decreases, making debugging more complex. Additionally, in serverless environments, it may be difficult to replicate for integration testing. However, it's not all bad news. As the serverless ecosystem continues to grow, new platforms and services are being released to address these challenges. One possible solution is Datadog's End-to-end Serverless Monitoring.

3. Final Thoughts

There are various use cases for serverless architecture. Many are used in conjunction with microservices through REST or GraphQL APIs, focusing on low-computing operations with unpredictable traffic.

 

Migrating from legacy infrastructure to serverless is undoubtedly challenging, especially when it requires a complete restructuring of the application. However, the beauty of switching to serverless is that it can be done one step at a time.

 

This relatively new architecture may not meet all needs right away, but investing time in serverless should ultimately bring many benefits.

 

Finally, Jamstack sites and applications prioritize the front-end, making serverless the ideal way to integrate back-end functionality.

 

Without experience in these two architectures, companies may hesitate, but Bejamas is here to answer your questions and ensure a smooth transition.