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

In this issue, the editor will bring you about how to reduce the cost of micro-service application resources through Serverless technology. The article is rich in content and analyzed and described from a professional point of view. I hope you can get something after reading this article.

Preface

Micro-service is an indispensable technology in the field of large-scale distributed IT architecture. In essence, micro-service is an architectural style, which divides a large-scale system into multiple applications with independent life cycle, and the applications communicate with each other by lightweight communication mechanism. These applications are built around specific business, and can be deployed independently, iterated independently, or expanded horizontally according to the business load.

The idea of micro-service and related technologies have brought a series of profound changes to the development of IT architecture.

* * easy to develop and maintain: * * an application will only focus on a specific set of business functions. Service splitting can reduce the coupling between applications and make development and maintenance easier.

* * unlimited technology stack: * * in the micro-service architecture, the technology stack can be reasonably selected according to the characteristics of the project business and the team.

* * accelerate system evolution: * * each application can update the version independently, and ensure the stable operation of the whole system during the release process through technical means such as grayscale release.

* * Breaking through the performance bottleneck: * * each application can scale horizontally independently, so that the system performance can be expanded linearly according to the increase of computing resources.

The challenge of microservices

There is no free lunch in the world, and micro-service technology not only makes IT systems more agile, more robust, and higher performance, but also brings about an increase in architectural complexity. For developers, in order to better control the micro-service architecture, a series of problems need to be solved, such as continuous integration, service discovery, application communication, configuration management, traffic protection and so on. Fortunately, in view of these common problems, a series of excellent open source technology components and tools have emerged in the industry, which make it easier for developers to build micro-service applications. After years of development, technical frameworks such as Spring Cloud and Dubbo have evolved into general standards in the field of micro-services, greatly lowering the threshold of micro-services, but these technical frameworks still have no way to solve the two biggest challenges that developers face.

Challenge 1: an urgent need for a sound life cycle management and service governance plan

In a system with frequent iterations, each application will often face the need for new version release. It is necessary to centrally manage the online, offline, update, rollback and other processes of the application, and cooperate with fine-grained grayscale publishing means to reduce the impact of version iteration on the business.

In a simple micro-service architecture, if an application is at the entrance to the entire link, its front end is usually hung with a load balancing component (Application An in the figure above) to undertake business requests from end users. Such applications will be more complex in lifecycle management. In order to ensure the balance and stability of the application during the release of the new version, the following steps will be taken:

In this process, the advanced grayscale scheme for fine granularity control of traffic has not been involved, but it is complex enough and difficult to operate. If we only rely on simple release scripts for management, it is not only inefficient, but also easy to take care of one or the other, which poses a great risk to the stability of the system.

Challenge 2: the urgent need for a perfect horizontal capacity expansion and reduction plan

When there is a bottleneck in the performance of an application, and it is necessary to improve the performance by increasing the number of instances, it is necessary to introduce new computing resources.

Where do new computing resources come from?

For offline IDC, computing resources need to be planned in advance, and capacity expansion is not a simple thing, which may not be achieved due to various conditions. Of course, this kind of trouble no longer exists in the era of cloud computing, it is easy to expand computing resources for an application, but computing resources alone are not enough, we have to deploy applications on them and accommodate them into micro-service systems.

According to this process, if you need to expand an application instance, it is conservatively estimated that it will take more than 20 minutes, in which purchase, system initialization and application deployment all take a lot of time. Assuming a sudden increase in system traffic and the need for emergency capacity expansion within 2 minutes, this scheme is useless.

A good medicine: containerization technology

In order to solve these two problems, developers have tried a variety of solutions, new ideas and technical frameworks have emerged one after another in the past five years. Under the round of survival of the fittest, container technology, represented by Docker, has become the mainstream in the industry under the support of Kubernetes ecology, and is a necessary element for building cloud native (Cloud Native) applications. Containerization-related technologies can tap the value of cloud computing and help developers solve these two problems to a certain extent.

In the aspect of application life cycle management and service governance, Kubernetes provides a relatively perfect implementation mechanism. Through the construction of Deployment resources, together with proStop and postStart scripts, it is more convenient to achieve rolling release and elegant online and offline applications. Although in the process of grayscale release, there is still no way to directly control the fine granularity of traffic (the introduction of Service Mesh technology can enhance the power of flow control, which is not discussed in this article), it has been improved by leaps and bounds compared with simple release scripts.

In terms of horizontal expansion and reduction of applications, the time for operating system installation and system-level initialization can be greatly reduced through containerization technology, but the purchase of virtual machines is inevitable, so when the system encounters traffic surge, there is still no way to achieve rapid horizontal expansion. We can reserve some computing resources and put them in the resource pool. When the application needs to expand its capacity, we apply for resources from the resource pool, and when the business load drops, we return the excess computing resources to the resource pool.

In fact, this is not a good idea, every computing resource needs cost, although the resource pool can solve the problem of rapid use of computing resources, it has caused a huge waste. In addition, it is also a nerve-racking thing to plan how big the resource pool is. The larger the pool, the greater the waste, but the pool is too small to meet the needs of capacity expansion.

A deeper analysis of resource cost

Some developers may think that the current business operation is very stable, and there is no obvious sudden increase in user traffic, so capacity expansion and reduction is a pseudo demand, and there will be no such demand in the future. This may be a misunderstanding of Internet business, because there is no need for expansion at all.

First of all, as long as a system is for human service, there must be peaks and troughs. For a system running 24 hours a day, it is impossible to maintain the same user traffic forever, and the 28 principle still applies to many business systems (80% of user traffic is concentrated in 20% of the time). Even if the user traffic is relatively balanced, there is a trough of traffic in the early hours of the morning. If we can further release idle computing resources and improve resource utilization, we can significantly reduce the cost of using resources.

In addition, compared with the production environment, the development and test environment for capacity expansion and reduction will be more urgent. A set of microservice applications is developed by different teams, and ideally, multiple teams will share a test environment:

However, each team has its own rhythm for the iteration of the application, and at the same time, they want to have an independent end-to-end test environment to achieve isolation between environments and avoid interaction between teams. In this case, there are likely to be multiple test environments:

With the increase of the number of applications, teams and business function points, the number of development and test environments required will grow exponentially, resulting in a huge waste of resources. For the computing resources of the test environment, the resource utilization rate is much lower than that of the production environment. Sometimes it is just a simple function point verification, in order to run through business functions end-to-end and avoid the interaction between teams, it will open a new environment that includes all micro-service applications. For many enterprises, such a waste of resources is a difficult problem that has not been solved for many years.

Therefore, the micro-service architecture essentially has a strong demand for elastic scaling, in the process of elastic scaling, whether it is the horizontal elastic scaling of a single application or the start and stop of the whole environment, resource utilization plays a decisive role in the final resource cost. If we can find a way to improve the utilization rate of resources, we can save a lot of resource costs for enterprises. What deserves our attention is that the resource utilization of the vast majority of micro-service applications is very low.

We can do a simple statistics: derive the CPU utilization of all servers every 5 minutes, calculate the average according to the day dimension, and we can understand the resource utilization data of the system as a whole. If the server resources of the development test environment are included in the statistical scope, the resource utilization is likely to be even lower.

Exploration of Serverless

The fundamental reason for the low resource utilization is that in the server-based application architecture, developers need to deploy the built package to the server to respond to multiple user events. In order to ensure the timeliness of event response, it is necessary to keep the program on the server and plan resources conservatively as much as possible to avoid overload and service crash. In this process, the actual load is not evenly distributed in time, resulting in low overall resource utilization.

The emergence of Serverless technology provides a new idea for improving the utilization rate of resources. Serverless is a complete process of building and managing a micro-service-based architecture that allows developers to deploy applications directly from server resources. It differs from the traditional architecture in that it is completely managed by a third party, triggered by events, and exists in a stateless (Stateless) computing container. Building serverless applications means that developers can focus on product code without having to manage and manipulate server resources, so that deployment of applications does not involve infrastructure construction.

There are many forms of Serverless technology, the most typical of which is FaaS (Function as a Service, function as a service), such as Aliyun's function computing (Function Compute,FC) product. In the field of functional computing, the application and scheduling of all computing resources are triggered by specific business events. When the task corresponding to the business event is completed, the computing resources will be released immediately. This way really achieves the on-demand allocation of computing resources, can significantly improve the utilization of resources, and is the ultimate form of Serverless technology.

The other is Serverless-based container technology. Serverless-based container instances run in a case-isolated environment, and each computing node is completely strongly isolated by lightweight virtualization security sandbox technology. For users, container applications can be deployed directly without purchasing server resources, and there is no need for node maintenance and capacity planning for the cluster. They can pay on demand according to the amount of CPU and memory resources configured by the application. When micro-service applications need to be expanded, they can quickly obtain computing resources, and no longer need to go through the step of purchasing servers, which can help developers reduce computing costs, reduce the waste of idle resources, and smoothly cope with sudden traffic peaks. Aliyun's Serverless Kubernetes (ASK) is the representative product of Serverless container technology.

Further explore the demands of developers

Seamless Serverless technology is the development direction of cloud computing and cloud native application architecture, but for developers of micro-service applications, whether in FaaS form or Serverless Kubernetes, there are some limitations.

Not every service is suitable to be built through FaaS, especially for applications with long links and obvious dependence on upstream and downstream, there is no way to transform it into FaaS at all. Even if the FaaS transformation of some business systems is proved to be feasible, transforming the existing micro-service architecture into FaaS architecture also requires a certain amount of work, and can not be seamlessly transplanted.

Although Serverless Kubernetes architecture can adapt to all business scenarios, for developers, to build a complete Kubernetes system, it is necessary to master a series of complex concepts related to Kubernetes, with a very steep learning curve. Moreover, the construction of various components in the Kubernetes ecology, coupled with the adaptation of the network layer and the storage layer, involves very complex work.

The reason for this limitation is very simple. In the micro-service technology camp represented by Spring Cloud, the construction of the system is carried out around the application (which can also be understood as a single service). Whether it is version update or horizontal expansion, it is aimed at the application itself. The core of Serverless Kubernetes architecture is Pod, which is more inclined to the bottom of the system than applications, so users need to devote more energy to the management of lower-level resources of applications. The core of the FaaS architecture is the function, which is more inclined to the upper layer of the system than the application, so the flexibility will be reduced and can not adapt to all business scenarios.

For developers who use mainstream Spring Cloud or Dubbo systems to build micro-service applications, if they need to introduce a solution to reduce resource costs, their final appeal must include two aspects:

(1) whether the transformation cost can be zero or close to zero; (2) whether it can adapt to all business scenarios.

Application layer Serverless technology

Is there a technology between FaaS and Serverless containers that can achieve these important demands? Of course, this is the application layer Serverless technology represented by Aliyun Serverless Application engine (SAE).

(figure: different levels of Serverless technology)

SAE realizes the perfect integration of Serverless architecture and micro-service architecture. For mainstream micro-service architectures such as Spring Cloud and Dubbo, it can achieve seamless compatibility, basically no transformation cost, and real on-demand and postpaid, saving idle computing resources, while eliminating the work of IaaS layer operation and maintenance, effectively improving the efficiency of development and operation and maintenance.

Take the Spring Cloud application as an example. If you need to deploy a new application, you only need two steps:

(1) tell SAE how many instances the application needs, and specify the CPU / memory specifications required for each instance. (2) upload the JAR package / WAR package of the application, and start the application.

We find that these two steps do not involve capacity assessment, server purchase, operating system installation, resource initialization and other work, so that micro-service applications with multiple peer instances can be run. This is because in the world of Serverless, there is no longer the concept of server resources, and the carrier of the application is the sandbox container dispatched by SAE. Each instance will not be billed according to the duration of use until it is really put into use.

For developers, they do not need to care about whether the application is deployed in a physical machine, a virtual machine, or a container, nor do they need to know what version of the underlying operating system is. Just pay attention to how many computing resources each application instance occupies. If the application needs to be expanded from 4 instances to 6 instances, or reduced to 2 instances, it can be completed with only one instruction, and even the binding relationship with SLB can be established or removed automatically. This is the great value that Serverless technology brings to developers.

Using SAE to deploy micro-service applications, because it only changes the carrier in which the application runs, it can be 100% compatible with the existing technical architecture and business functions, and the migration cost is negligible.

The extreme elasticity of SAE

In addition to manual expansion instructions, SAE also supports two automatic resilience mechanisms, which can flexibly scale micro-service applications horizontally and further give full play to the resilience of cloud computing.

* * timing resilience mechanism: * * you can set a timing elasticity policy for periodic behaviors that are expected to occur. For example, if the business peak is at 9 a.m. every day, you can increase the number of instances at 08:30 every day and reduce the number of instances at 09:30.

* * resilient mechanism based on metric threshold: * * for a sudden increase in business traffic that exceeds expectations, you can set an elastic policy based on metric threshold. According to resource metrics such as CPU and memory, applications can automatically achieve elastic scaling with business metrics such as QPS.

Through a variety of elastic mechanisms, the system capacity can be managed with fine granularity, so that the usage of resources can be adjusted with the change of business traffic, so as to greatly increase the utilization of resources and greatly reduce the cost of resources.

SAE has made a number of optimizations on the scheduling and startup of computing resources. It only takes a few seconds to pull up the expanded new instances. This capability is of great significance for some sudden scenarios that require emergency and rapid expansion.

For the development and test environment, the mechanism flexibility of SAE can be reflected more incisively and vividly, thanks to the excellent resource scheduling ability of SAE, you can start and stop a whole set of micro-service applications with one click. Even if it is only a smoke test of a simple new feature, it is possible to start a new complete and isolated test environment. The new environment can be built in seconds, put into use quickly, and can be released immediately after testing. In terms of cost, the actual time for a new environment to be put into use is very short, so it will only cost very little. This is a great change for multi-team cooperation in the process of micro-service application development.

Cost analysis

SAE pays by the actual usage of resources. The fee consists of two parts. Each part is settled according to the statistical results and calculation method, and the bill is deducted on an hourly basis. The resources used by each application are measured as follows:

Application CPU resource usage = CPU specification of ∑ instance × duration of this month (in minutes), that is, the sum of CPU specifications of all instances in the application multiplied by the duration of this month.

Application memory resource usage = ∑ instance memory specification × current running time (in minutes), that is, the sum of the memory specifications of all instances in the application multiplied by the current running time.

The price of CPU part is 0.0021605 yuan / minute / Core, and the price of memory part is 0.0005401 yuan / minute / GiB. SAE also provides a prepaid resource package, which is equivalent to pre-purchasing computing resources in a wholesale way. As long as it can be consumed within the validity period, it can further save costs. When the resource package is deducted, the system will automatically change to the pay-by-quantity mode.

Let's use a practical case to further understand how SAE can help micro-service applications reduce resource costs. Suppose a micro-service system contains 87 application instances, each with an average running time of 8 hours per day, and the instance is configured with 2 Core + 4 GiB + 20 G disks.

Deploy applications with an annual or monthly plan: you need to purchase 87 computing c5s. The monthly cost of each unit is RMB186and the total monthly cost is RMB 16146.

Use postpaid ECS to deploy applications: the price of a single unit is RMB 0.63 / hour, with a total cost of 20880 hours per month, with a total cost of RMB 13154.

Use SAE to deploy applications: purchase an annual resource pack of 75000 yuan. 87 instances run for 8 hours a day, which just uses up the quota of the resource pack, which is equivalent to a total cost of 6250 yuan per month.

From this comparison, we can draw a conclusion that as long as we can reasonably run the flexibility of SAE, we can greatly reduce the resource cost for micro-service applications.

Additional capacity

In addition to simplifying the workload of operation and maintenance and reducing resource costs, SAE also improves a series of additional functions for micro-service applications, which is the additional value that application-layer Serverless technology brings to developers. We can make use of these out-of-the-box features as much as possible to make it easier to build micro-service applications.

* * complete application lifecycle management: * * after the application is hosted to SAE, you can perform application lifecycle management operations such as update, scaling, start and stop, delete, monitor start and stop, and so on.

* * out-of-the-box registry: * * SAE comes with a commercial Nacos registry, which can be used free of charge and does not need to be built on its own. If there are special needs, such as allowing applications deployed in SAE and other applications to discover each other, you can also use a registry provided by the Micro Services engine (MSE) product, or a self-built registry.

* * out-of-the-box configuration management center: * * SAE integrates the configuration management features of ACM (Application Configuration Management), and you can use ACM to centrally manage application configurations in SAE.

Application-level traffic protection: SAE integrates AHAS to achieve application-level flow control and degradation capabilities, fully ensuring the high availability of applications.

* * Monitoring capability: * * after the application is hosted to SAE, you can get the monitoring capabilities of basic resources (including CPU, memory, load and network) and application layer (including JVM analysis, API call analysis, etc.) free of charge. If you need more advanced SQL analysis, exception analysis, link upstream and downstream, and interface snapshots, you can integrate Ali Cloud Application time Monitoring product (ARMS).

* * CI/CD integration capability: * * SAE is deeply integrated with Cloud effect, Cloud effect 2020, Jenkins and other products, making it convenient for developers to quickly deploy built applications.

Multilingual support

For applications written in non-Java languages, or Java applications that do not use micro-service frameworks such as Spring Cloud, can SAE perfectly support and help enterprises reduce resource costs?

Of course you can. SAE provides container image deployment, which means that no matter which programming language is used, as long as the final application can be released as a container image, it can be deployed on SAE.

For micro-service applications of Java system, common applications of Java system, and non-Java applications, there is no essential difference in the extreme elasticity of SAE, which can provide system resource utilization through Serverless technology. It's just that some of the added value provided by SAE, such as a free micro-service registry, can only serve Spring Cloud or Dubbo applications.

Let's use this picture to review the great value of Serverless technology:

Frequently asked questions:

1. Q: the application instance does not have fixed machine resources, not even a fixed IP address, how to SSH to a server to troubleshoot problems?

A: fixed machine resources and fixed IP addresses are not required to troubleshoot problems. In the era of cloud computing, logging in to a machine through SSH is not a good practice. On the contrary, SAE provides perfect monitoring capabilities, and can be easily integrated with cloud monitoring, ARMS and other new generation of monitoring and diagnosis products, providing greater convenience for troubleshooting. Of course, if you have to log in to a machine, SSH can still support it, or you can use the Webshell tool provided by SAE to simplify the process.

two。 Q: isn't disk a billing dimension? What if the application requires high-capacity disks? Do you still retain the data in the touch disk after the application is restarted?

A: in the field of microservices, applications are generally Stateless, and there is no need to save a large amount of local data. If you can't do without this requirement in a particular scenario, you can integrate NAS and use a centralized storage implementation.

3. Q: how do I view the log of the application?

A: the SAE console interface provides real-time access to file logs, which is equivalent to providing a distributed log collection platform for free. Of course, it is strongly recommended to connect to Ali Cloud Log Service (SLS) products to further give full play to the value of application logs.

The above is what the editor shares with you on how to reduce the resource cost of micro-service applications through Serverless technology. If you happen to have similar doubts, please refer to the above analysis. If you want to know more about it, you are welcome to follow the industry information channel.

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.