Introduction to the
Somewhere along the way, there was a pattern called Serverless architecture. Look at the English word Serverless, which means no service. How do you build an application without a service?
After a careful study, I found that Serverless does not mean that the service is not required, but that the service is built on the BaaS or FaaS platform. This is typically applied to single-page applications or programs for which business logic is not responsible.
It’s clear that the Serverless architecture is the brainchild of cloud vendors to get you to use their services. This is similar to the recently popular Cloud Native.
Such architectures, while eliminating the need to build services in traditional architectures, may benefit from significantly reduced operating costs, complexity, and engineering delivery times, at the expense of increased dependency on vendors and relatively immature support services.
This article discusses Serverless and the story behind it in more detail.
What is a serverless
The concept of Serverless is undoubtedly put forward by cloud vendors, such as Microsoft, Google, and Amazon are all proponents of Serverless, and deeply bind and recommend their services.
So what is Serverless?
Serverless can actually describe two states. The first state is for rich clients. For rich clients, business logic can be completed on the client side, and only database services or authentication services can be used in the cloud. These types of services are called BaaS.
In the other, server-side logic is still written by the application developer, but unlike traditional architectures, it runs in stateless computing containers that are event-triggered, ephemeral (perhaps lasting only one call), and invoked entirely by third parties. This service is called function as a service or FaaS. The most famous is the currently popular cloud service Lambda.
An example of serverless
Simple three-tier service
Let’s take a look at some specific examples where serverless can be used to help you understand.
Consider one of the most common Web projects that offers the ability to add, delete, and check. Obviously, we need a client, a server and a database, as shown in the figure below:
An example of a simple service is shown in the figure above. We have a client to display the UI, which is generally the browser. There is also a server that receives all client requests and business logic processing. Finally, a database is used to store the corresponding data.
If you convert the above service to a Serverless architecture, how do you modify it?
In the Serverless architecture, the server side is gone and replaced by various FaaS. The client is then enhanced to become a rich client, where most of the business logic is performed, and in some cases the database can be read directly from the client.
The business logic that must be used by FaaS services needs to be split, as shown below:
In the figure above, we used a third-party cloud authentication service for security authentication. At the same time for the unimportant data can directly authorize the client to query the database.
For the update service, it is still necessary to update the database with the help of the UPDATE API provided by FaaS.
As you can see, the Serverless architecture is completely different from the original architecture. The benefits are that the system is more flexible and functions are redivided, with less business logic on the server side and a somewhat distributed effect with lower server costs.
The disadvantage is that the original service is split into multiple services, which need to be monitored, and then basically all the data is stored in the cloud, which puts forward higher requirements on the security capability of the service provider. Finally, this reduction in flexibility and cost increases the complexity of the system and increases the difficulty of maintenance.
message-driven
A common message-driven example is clickstream reporting on the front end. When a user clicks a button on the client, it invokes an interface on the server. This interface sends a click message to the message queue, then enables an asynchronous back-end service to fetch the message from the message queue, and finally updates the database.
How would the above example be implemented with Serverless?
We need to replace the server with FaaS and the asynchronous service with the corresponding FaaS:
The benefit here is that FaaS’s fast scaling capabilities allow you to dynamically extend message processing functions in large numbers of messages, thus speeding up system processing.
FaaS
We’ve mentioned FaaS a lot, but what is it?
In its Original English meaning, FaaS means function as a service. Or you can view it as Amazon’s AWS Lambda service.
AWS Lambda can be run without any servers, simply uploading your business code and automatically generating a Lambda service. The service is then available for external invocation.
Of course, the “no server” here means that the customer does not need to buy a server and build services on it. In fact, lambda also needs to run on the server.
FaaS is basically compatible with Javascript, Python, Go, and any JVM language, and can be regenerated as a FaaS service with a few changes.
Another advantage of FaaS is that it scales horizontally, and this scaling is completely automatic. This scale-out automatic management is controlled by the carrier and the user does not need to worry about the low-level details of the implementation. This scale-out capability is very effective for peak application of services at any given time.
We just need to design the FaaS function and let the cloud vendors do the rest.
The disadvantage of FaaS
FaaS is stateless, meaning you can’t use local memory variables or local disk data, because FaaS does not guarantee the validity and persistence of the data.
So you need to externally persist the data that you want to store.
In addition, due to the limitations of the cloud server, each call to FaaS has a maximum timeout, so FaaS is only suitable for applications that can respond quickly.
In addition, THE FaaS may need to be initialized at startup, and the instantiation of this function may result in a delay in the request. So you need to consider the startup strategy of your cloud provider and adjust accordingly.
When we decide to use any outsourcing strategy, you give control of part of your system to a third party vendor. This lack of control can manifest as system outages, unexpected limitations, cost changes, loss of functionality, forced API upgrades, and so on.
- Multi-tenant problem
Multi-tenancy refers to the situation where multiple instances of software from multiple different customers (or tenants) are running on the same machine and possibly in the same managed application. This is a strategy for cloud providers to achieve economies of scale. Service providers do their best to make customers feel like each of them is the only one using their system, but, There is no perfect solution that addresses the security (one customer can see another customer’s data), robustness (an error in one customer’s software causes another customer’s software to fail), and performance (a high-load customer) aspects of multi-tenancy at the same time.
- Vendor binding
If you’re using Serverless on one provider, switching to another can be costly. Operational tools may need to be updated, and code may need to be updated.
The advantages of FaaS
Think of Serverless as the simplest outsourcing solution. Instead of managing your own servers and databases, you can host them to a cloud vendor.
On the one hand, there is less investment in infrastructure services, and on the other hand, there is less labor cost to maintain the infrastructure.
In addition, any performance optimizations you make to your code will not only increase the speed of your application, but they will be linked directly or indirectly to lower operating costs, depending on the service provider’s billing plan. For example, suppose an application initially takes a second to process an event. If you reduce this time to 200 milliseconds through code optimization, you will see an immediate 80% savings in computing costs without any infrastructure changes.
Packaging and deploying FaaS functionality is simple compared to deploying the entire server. All you do is package all the code into a ZIP file and upload it.
conclusion
Serverless architecture is one of the most popular architecture methods at present. We can try this new architecture method to see if it can bring different changes to our business. However, it should be noted that not all services can use the Serverless architecture. We need to weigh it.
This article is available at www.flydean.com/11-serverle…
The most popular interpretation, the most profound dry goods, the most concise tutorial, many you do not know the small skills waiting for you to find!