Modern Application Architectures Part — 3 (Serverless Architecture)
Serverless Architecture allows the rapid development of software applications that can handle various levels of traffic in production environments. The term serverless refers to the fact that compute services are provided without requiring you to manage or administer servers. Your code is executed on demand, as it is needed.
Similarly, with serverless architecture, you do not need to deal with physical servers, and the complexity of how compute resources are provided is hidden from you. Software applications use as much or as little compute capacity as they need. A number of cloud vendors, including Amazon, Microsoft, Google, and IBM provide compute services.
Serverless Architecture can be used for many types of software applications and tasks. Some of the common types of applications which are suited to a serverless architecture include web applications, event-driven data processing, scheduled tasks (CRON jobs), mobile applications, and Internet of Things (IoT) applications. It is also good for data transformation tasks related to things such as images/video (for example, for the purposes of compression and/or optimization), voice packets, and PDF generation.
Models of Serverless Architecture
There are two models for Serverless architecture. Function as a service (FaaS) and Backend as a service (BaaS) models to provide backend logic for software applications. The two are used together to provide the functionality of the application.
Function as a Service (FaaS)
In a serverless architecture, a small piece of code, like a function, can be executed using an ephemeral compute service to produce a result. This is known as Function as a Service (FaaS). The code executes in a container that is spun up on invocation and then brought back down when it is complete.
Functions are typically invoked due to events or HTTP requests. When a function completes its processing, it can either return a value to the caller or pass the result to another function that will be invoked as part of a workflow. The output can either be structured, such as an HTTP response object, or unstructured, such as a string or an integer.
Each function should follow the single responsibility principle (SRP) and serve a single, well-defined purpose. Development teams can code functions to perform server-side logic and then upload the code to their service provider for on-demand execution. FaaS makes it easy to go from writing code on your laptop to having it execute in the cloud.
Functions should be designed to be idempotent, so that multiple executions of the same request yield the same result, and if the same request is processed more than once, there should not be any adverse effects.
The functions in FaaS can be either synchronous or asynchronous, depending on the needs of the task. One of the ways that asynchronous functions work in FaaS is that the platform will return a unique identifier that can then be used to poll the status of the asynchronous operation.
An important part of a Serverless Architecture is its API gateway. An API gateway is the entry point to a system. It is an HTTP server that takes requests from clients and uses its routing configuration to route them to the relevant function container. The functions run in compute containers and should be stateless. The result of the FaaS function is then sent back to the API gateway and ultimately returned to the client as an HTTP response.
Implementations of FaaS that are available from providers include Amazon Web Services Lambda, Microsoft Azure Functions, Google Cloud Functions, and IBM Cloud Functions.
Backend as a Service (BaaS)
Backend as a Service (BaaS) is a model that allows developers to take advantage of service applications provided by third parties. This reduces development time and costs, as teams do not have to write these services in-house. In contrast with FaaS, where development teams write their own code for the various functions, BaaS offers the use of existing services.
Examples of the functionality provided by service applications include a database, push notifications, file storage, and authentication services. With BaaS, developers can focus on building the frontend of their applications without worrying about setting up or managing the backend infrastructure.
However, it’s important to consider the limitations of BaaS. While it offers convenience, it may not be suitable for all types of applications or certain use cases that require more control over the backend infrastructure. It’s crucial to evaluate the specific needs of your application.
Benefits of Serverless Architectures
Using a serverless architecture provides many important benefits, which explains why it is becoming increasingly popular. With a serverless architecture, developers do not need to worry about purchasing, provisioning, and managing backend servers.
Cost Saving
With a Serverless Architecture, your code is only executed when it is needed. You get utility billing, in that you are only charged for the actual compute resources that are used.
An Organization who moves to a Serverless Architecture will reduce hardware costs, as there are no longer servers and network infrastructure to support. In addition, organization do not have to hire staff to support all of that infrastructure. These cost savings are similar to what organizations might save from using Infrastructure as a Service (IaaS) or Platform as a Service (PaaS), except that there are also reduced development costs (taking advantage of BaaS) and scaling costs (taking advantage of FaaS).
Scalable and Flexible
You can’t underprovision or overprovision your compute capacity with a Serverless Architecture. You avoid being in a situation where you do not have enough servers during periods of peak capacity or have too many servers sitting idly during off-peak periods.
The scalability and flexibility of Serverless Architectures allows for compute capacity to scale up and down as demand changes. You only use as much compute capacity as you need and you are charged for the amount that you use. Wasting compute capacity is kept to a minimum and organizations will experience lowered costs as a result.
Focus on Building Your Core Products
Another one of the main advantages of using a Serverless Architecture is there are no servers to manage. This allows an organization to focus on creating solutions and shipping more features.
Not having to administer an infrastructure increases productivity and reduces the time to market. Even a small development team can start building an application and deploy it to production relatively quickly because they won’t need to provision an infrastructure up front and they won’t have as much to manage after deployment. A development team that wants to build an application quickly while worrying less about operational concerns will find serverless architecture attractive.
Drawbacks of Serverless Architectures
Although there are many benefits to using a Serverless Architecture, you should be aware that there are some drawbacks. Here are a few potential drawbacks to consider
Difficulties With Debugging and Monitoring
There is complexity in debugging distributed systems using serverless architecture. When multiple functions integrate with each other to perform a task and something goes wrong, it can be difficult to understand when and why the problem occurred.
Vendors provide tools for debugging and monitoring, but there is still a level of immaturity with the serverless architecture pattern. Serverless architecture applications will become more prevalent, but it is still relatively new compared to other types of software architecture.
Multitenancy Issues
Multitenancy issues, while not unique to serverless systems only, deserve consideration. Any time software for different customers are executed on the same machine, there is the possibility of one customer affecting a different customer.
Examples of this include security issues, such as one customer being able to see another customer’s data, or performance issues when one customer experiences a heavy load that affects performance for another customer.
Vendor Lock-in
Vendor lock-in can be an issue with Serverless Architectures.
You may think that moving from one serverless environment to another one would be easy, but it can be quite involved. In addition to your code being moved, each provider has specific formats and deployment methods. In addition, you may be taking advantage of technologies and tools specific to your vendor.
Some degree of refactoring will be required if you want to switch vendors. Ideally, your software application will not be reliant on a particular cloud provider. One way to mitigate this disadvantage is to use a framework that packages your application in a way that allows for deployment to any cloud provider like Serverless Framework.
Complexity of Designing Many Functions
Software systems that have a Serverless Architecture tend to consist of numerous functions and there is inherent complexity in designing many functions. It will take time to make decisions on the granularity of functions provided in the serverless architecture.
A good design provides a balance between having too many functions and having functions which too large and difficult to maintain. There is also complexity in chaining multiple functions together in order to execute complex transactions. The design must consider how it needs to handle a situation in which one function in a chain fails.
Not as Many Runtime Optimizations
Serverless Architectures do not allow for much in terms of runtime optimizations. In a traditional environment, optimizations might be made regarding memory, processors, disks, and the network. However, cloud providers can assist with optimizations for you. But there is no opportunity to optimize the server design for client performance.
Using a Serverless Architecture for a software system does not have to be an all or nothing approach. In addition to new applications fully leveraging serverless architecture, you may choose to design a part of your system with a serverless architecture and use a different architecture pattern for the other parts of your system.
As example, an organization may take a hybrid approach and build some new features for an existing application in a serverless architecture and use them with other architecture.
