Shulou(Shulou.com)05/31 Report--

This article will explain in detail the advantages and disadvantages and best practice analysis of Serverless microservices. The content of the article is of high quality, so Xiaobian shares it with you for reference. I hope you have a certain understanding of relevant knowledge after reading this article.

Serverless is a complete process for building and managing a microservices-based architecture that allows you to manage your application deployment at the service deployment level rather than the server deployment level.

It differs from traditional architectures in that it is completely managed by a third party, triggered by events, and exists in a stateless, temporary (perhaps only during a single call) computation container. Building serverless applications means developers can focus on product code without having to manage and operate servers or runtimes in the cloud or on-premises. Serverless truly deploys applications without involving infrastructure construction, automatically building, deploying and launching services.

The concept of microservices fits well into the architecture of Serverless functionality, making it easy to isolate different services both at deployment and runtime. In terms of data storage, using databases such as DynamoDB also enables each microservice to have its own database and makes it easier to scale them independently when needed.

Before we dive into the details, consider whether the benefits of microservices outweigh the disadvantages for your particular project and team. Please don't choose microservices just because they are a trend. Monolith also has its application scenarios.

The advantages of Serverless microservices 1. Selective scalability and concurrency Serverless features make it easy to manage concurrency and scalability of your applications. We take advantage of this in our microservices architecture, where each microservice can have its own concurrency/scalability settings as needed. This is valuable: mitigating the likelihood of DDoS attacks, reducing financial risk from uncontrollable cloud bills, better allocating resources, and more. 2. Fine-grained resource allocation allows detailed control over resource allocation priorities through selective scalability and concurrency. Each (micro) service can have different levels of memory allocation depending on its needs and purpose. Customer-facing services can allocate higher memory because it will help reduce execution times and improve response times. Latency insensitive internal services can be deployed with optimized memory settings. The same is true for storage mechanisms, where databases such as DynamoDB or Aurora Serverless can have different levels of capacity allocation depending on the needs of (micro) services. 3. Loose coupling This is an essential property of microservices, so that it makes it easier to decouple system components with different uses. 4. Support for multiple runtimes Serverless feature configuration, ease of deployment and execution opens up the possibility for systems based on multiple runtimes. Although Node.js is one of the most popular technologies in backend Web applications, it is unlikely to be the best tool for every task. But, for data-intensive tasks, predictive analytics, and any form of machine learning, Python might be your choice. Dedicated platforms, such as SageMaker, are better suited for larger projects. With Serverless infrastructure, you can choose Node.js for regular back-end projects and Python for data-intensive projects without extra effort on the operational side. Of course, this will add some effort to code maintenance and team management. 5. Independence of development teams Different developers or teams can work on their own (micro) services, fixing bugs, extending functionality, etc. Tools like AWS SAM, Serverless, allow for greater independence in operations as well. AWS CDK constructs enable greater independence without sacrificing higher quality and operational standards. Disadvantages of microservices in Serverless 1. Difficulty Monitoring and Debugging Of the many challenges that Serverless presents, monitoring and debugging are the most difficult. Because compute and storage systems are scattered across many different nodes, not to mention other services such as caching. However, there are professional platforms that can solve all these problems. 2. May experience more cold starts

Lambda checks to see if the microVM is activated when the function is invoked. If a free microVM is available, it will be used to service new incoming requests. In this particular case, there is no boot time because the microVM is already started and the code package is already in memory. This is called hot start.

The opposite approach-having to provision new microVMs from scratch to satisfy incoming requests-is known as cold boot.

A cold start occurs when a FaaS(Function as a Services) platform, such as Lambda, needs to start a new virtual machine to run functional code. If your apps are sensitive to latency, they may have problems because cold starts can add hundreds of milliseconds to a few seconds to the total startup time. FaaS platforms typically leave microVMs idle for a while after a request is completed, then shut them down after 10-60 minutes. Therefore, the more frequently the function executes, the more likely the microVM is to run incoming requests (avoiding cold starts). When we spread our application across hundreds or thousands of (micro) services, we may also spread out the invocation time of each service, resulting in less frequent invocation of each function, potentially experiencing more cold starts. 3. The microservices concept itself has other inherent disadvantages. These are not inherently linked to Serverless. Nevertheless, every team adopting this architecture should strive to reduce its potential risks and costs:

Defining service boundaries is not easy

A broader attack surface

service orchestration overhead

Synchronizing computation and storage is not easy

Serverless Microservices Challenges and Best Practices 1. How big should microservices be in Serverless?

Microservices are another hot topic in the software architecture industry. If microservices are based on small functional blocks focused on a single responsibility and function, and complex large applications are assembled in a modular way, we can further think that Serverless architecture can provide a more "code fragmentation" software architecture paradigm, which we call Function as a Services (FaaS).

A so-called "function" provides smaller program units than microservices. For example, microservices can represent the code needed to perform all CRUD operations for a customer, while "functions" in FaaS can represent each operation the customer wants to perform: create, read, update, and delete. When the Create Account event is triggered, the corresponding "function" is executed in the manner of an AWS Lambda function. In this sense, we can simply equate Serverless architecture with the FaaS concept.

In Serverless, the concept of "Function as a Services (FaaS)" is often confused with function statements in the programming language of your choice. We're entering an area where it's impossible to draw perfect boundaries, but experience shows that using very small Serverless features is not a good idea. One thing you should keep in mind is that when deciding to split (micro) services into separate functions, you're going to have to deal with the Serverless dilemma. Whenever possible, there are many benefits to keeping the relevant logic in a single function. The decision-making process should also take into account the advantages of having individual microservices. If I spin off this microservice, will this allow different teams to work independently? Can I benefit from fine-grained resource allocation or selective scalability features? If not, consider bundling the service with required components, etc. 2. Loosely coupling your architecture There are many ways to orchestrate microservices by composing Serverless functionality. When synchronous communication is required, direct calls can be made (i.e., the AWS Lambda RequestResponse call method), but this results in a highly coupled architecture. A better option is to use Lambda Layers or HTTP APIs, which make it possible to modify or migrate services later without interrupting client requests. For asynchronous communication, we have several options: Message Queue (SQS), Topic Notification (SNS), Event Bridge, or DynamoDB Streams. 3. Component isolation Ideally, microservices should not expose implementation details to users. Serverless platforms such as Lambda already provide APIs for isolation capabilities. But this in itself leads to implementation details leaking, and ideally we would add an agnostic HTTP API layer on top of the functionality to make it truly isolated. 4. To mitigate DDoS attacks, when using services such as the AWS API Gateway, make sure you have a separate concurrency policy for each public-facing endpoint. Such services have a global concurrency quota in the cloud platform. If you don't have endpoint-based restrictions, an attacker can exhaust your resource quota and bring down the entire system by targeting just one endpoint. The advantages and disadvantages of microservices and best practices analysis in Serverless are shared here. I hope the above content can be helpful to everyone and learn more knowledge. If you think the article is good, you can share it so that more people can see it.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.