Serverless architecture (Faas/Serverless) is a hot topic in the field of software architecture. But what is serverless and why (or not) is it worth considering? Combined with some personal understanding, I hope to have some enlightening discussions on these issues.
1. What is Serverless?
Serverless architecture is a way of designing applications that include third-party "back-end as a service" (BaaS) services, and/or includes custom code running in managed temporary containers on (FaaS) platforms. This type of architecture eliminates most of the need for traditional always-on servers. This can significantly reduce operation and maintenance costs, complexity and reduce the time to prepare the project for launch, at the cost of increased dependence on suppliers and relatively immature support services.
First, no one knows exactly what serverless is. It contains two different but related areas:
Serverless can describe a "rich client + third-party cloud-hosted applications and services" application. These "rich client" applications are generally mobile applications that use huge
cloud databases or SSO services (Auth0, AWS Cognito, etc.). These types of services were previously described as "back-end as a service".
Serverless can also mean that server-side logic is still written by
application developers, but unlike traditional architectures, it runs in stateless computing containers, which are transiently triggered by events (may only last for one call, or Deployment will Reserved, automatically adjust the number of running instances according to the running load), and completely managed by a third party (maybe the source of the name "FaaS") AWS Lambda is currently one of the most popular implementations of the Faas platform, which is cheaper than domestic cloud service providers Many, optimistic about the market value of Amazon first break trillions (Apple may hit the face).
In this article, obviously we will focus on the latter, FaaS/Serverless.
2. Several extended examples
Let us consider a traditional three-tier client-oriented system with server-side logic. A good example is a typical e-commerce application-an online pet store.
The architecture looks like this:
In this architecture, the client can be relatively less intelligent, most of the logic is completed on the server side, authorization, page navigation, query, transaction and so on.
In a serviceless architecture, it looks like this:
In the comparison between the two, we can see a series of obvious changes:
We removed the authentication logic from the original application and replaced it with a third-party BaaS service (for example, Auth0)
We allow clients to directly access our database (used for product listings), which is itself entirely hosted by a third party (such as Google Firebase). We may use a different security configuration file than the server resource access database to allow the client to access the database.
The first two points mean a very important third point: some logic in the pet store server is now located in the client-for example, tracking user sessions, understanding the UX structure of the application, reading from the database and converting it to a usable Views and other clients are becoming single-page applications.
We may want to retain some UX-related functions in the server, for example, if it is computationally intensive or requires access to large amounts of data. In our pet store, an example is "search". Rather than having an always-running server as in the original architecture, we can implement a FaaS function that responds to HTTP requests through an API gateway. Both the client and server "search" functions read product data from the same database.
Finally, we can replace the purchased implementation with another independent Faas function. For security reasons, this is also introduced by the API Gateway. When using FAAS, it is a common method to split different logic requirements into independent deployment components.
From FaaS is to run back-end code without having to manage your own server system or application. Compared with other modern architecture trends such as containers and PaaS, the existence of long-standing servers and applications is a key difference.
FaaS products do not require coding of specific frameworks or libraries. FaaS functions are routine applications of language and environment.
The deployment is very different from traditional systems because we don’t have the server applications we run ourselves. In the FaaS environment, we upload the functional code to the FaaS provider, and the provider executes everything needed to configure resources, instance VMs (Containers), management processes, and so on.
Horizontal scaling is completely automatic, flexible, and managed by Faas. If the system needs to process 100 requests in parallel, Faas will process the request without any additional configuration. The containers that execute functions are temporary, and FaaS creates and destroys them completely at runtime. The most important thing is to use FaaS, cloud vendors can handle all the underlying resource configuration and allocation, and users do not need cluster or VM management at all.
The functions in FaaS are usually triggered by the event types defined by the provider. With AWS, such events include S3 (file/object) updates, time (timed tasks), and message bus messages.
Most Faas operators also allow HTTP request trigger functions, and in AWS, this is usually achieved by using an API gateway. We use the API gateway for the "search" and "buy" functions in the pet store example. Functions can also be called directly through the API provided by the platform, whether externally or in the same
cloud environment, but this is a relatively uncommon usage.
4. Features that Faas needs to pay attention to
Is there a state
The FaaS function has great limitations in
the local (VM/container instance) state (that is, data stored in variables in memory or written to local disk). Under normal circumstances, you can indeed store this way, but there is no guarantee that this state will remain unchanged in multiple calls. More importantly, you should not assume that the state of a call to a function can be used for another call of the same function. Therefore, FaaS functions are usually described as stateless, or more precisely, any state of the FaaS function that needs to be persisted needs to be performed outside the FaaS function instance.
For naturally stateless FaaS functions-that is, those that provide pure functional conversion of input to output-this is irrelevant. But for stateful, this may be more troublesome, and the restrictions that were previously distributed are now the same. Such state-oriented functions will typically use a database, cache (such as Redis), or network file/object storage (such as S3) to store state across requests.
Execution time
FaaS functions are usually limited to how long each call is allowed to run. Currently, the "timeout" of AWS Lambda function response events is at most five minutes before it is terminated. Microsoft Azure and Google Cloud Functions have similar restrictions. This means that certain categories of long-term tasks are not suitable for FaaS-unless you redesign the architecture, you need to create several different coordination FaaS functions, while in a traditional environment, you may have a long-term task execution coordination and execution.
Start delay and "cold start"
The FaaS platform takes some time to initialize the function instance before each event. Different functions, his startup delay may also change significantly, from a few milliseconds to a few seconds, depending on many factors, specific AWS Lambda as an example.
The initialization of the Lambda function can be either a "hot start" (a previously generated container using the Lambda function) or a "cold start" (creating a new container instance). The delay caused by the cold start should attract our attention.
The delay of a cold start depends on many factors: the development language, the libraries used, the amount of code, the configuration of the Lambda function environment itself, whether it needs to connect to VPC resources, etc. These aspects are under the control of developers, and optimization of these places can reduce part of the startup delay during cold start.
Also adjustable is the cold start frequency. For example, if a function processes 10 events per second and each event takes 50 milliseconds to process, then every 100,000-200,000 events, you may see a cold start of an instance. On the other hand, if you process events every hour, you might see a cold start when each event comes, because Amazon will exit the inactive Lambda instance after a few minutes. Knowing this helps to understand whether a cold start will affect the integration effect, and whether you may wish to perform "keep-alive" on function instances to avoid them being recycled.
Does cold start require too much attention? It depends on the load or flow of the application. If you need a low-latency trading application, then it is best to forget the FaaS system, no matter which programming language you use.
Whether you think your application has such problems or not, you'd better test the performance with a similar production load. If it's bad at this moment, don't worry, FaaS vendors are continuously improving, and maybe meet your requirements by the end of the year.
API Gateway
The API gateway is an HTTP server, where routes and load points are defined in the configuration, and each route is associated with a function that processes the route. When the API gateway receives the request, it will find the routing configuration that matches the request and call the relevant FaaS function. The API Gateway allows for a more concise input that maps from the HTTP request parameters to the FaaS function, or lets the HTTP request pass through intact. The FaaS function will execute its logic and return the result to the API Gateway, which in turn converts the result to HTTP response and pass it back to the original caller.
tool
Comments about tool maturity also apply to FaaS. By this year (2018), we have seen a marked improvement, and we hope that the tool will develop better.
Some good examples of "developer user experience" in the FaaS world are worth mentioning. The first is Auth0 Webtask, which attaches great importance to the user experience of developers. Followed by Microsoft, its Azure functional products. Microsoft has always placed Visual Studio and its feedback loop at the forefront of its developer products, and Azure Functions is no exception. Under the input of the cloud trigger event, the ability to provide local debugging function is very special.
Open source forces
The most common use of open source in serverless is FaaS tools and frameworks, which provide some tool abstractions across cloud providers. Examples of similar tools include Claudia and Zappa. Another example is Apex, which allows you to develop Lambda functions in languages other than those directly supported by Amazon. However, AWS' own deployment tool SAM (Serverless Application Model) is also open source.
One of the main benefits of proprietary FaaS is that you do not have to care about the underlying computing infrastructure (machines, virtual machines, containers). But what if you want to focus on these things? Maybe you have some security requirements that cloud vendors cannot meet, or you have some server racks that you have already purchased but do not want to discard. Open source help can be used in these scenarios, allowing you to run your own "Serverful" FaaS platform, there are many activities in this field. One of the original leaders of open source FaaS was IBM (using OpenWhisk, now an Apache project). Microsoft, it has open sourced many Azure functional platforms. Many other self-hosted FaaS implementations use the underlying container platform, usually Kubernetes. In this area, it is worth exploring projects such as Galactic Fog, Fission, and OpenFaaS. In future blogs, I will focus on the OpenFaas project, which currently has more than 10k+ Stars.
