Shulou(Shulou.com)06/01 Report--

This article introduces you what the cloud native application is, the content is very detailed, interested friends can refer to, I hope it can be helpful to you.

The concept of cloud native applications

As the name implies, the concept of cloud native application consists of cloud and native. Here, cloud refers to the cloud platform, that is, platform as a service (Platform as a Service,PaaS). Native application refers to the design and implementation of the cloud platform, making full use of the characteristics of the cloud platform. The micro-service of the application can focus on the implementation of business logic and leave the complexity of the micro-service architecture to the cloud platform.

The word native has its unique meaning in software development. Nativeness usually means efficient and difficult to migrate, and it also means that it is designed for a specific platform and can take full advantage of the features of the platform, so it runs very efficiently; it also means that it is deeply bound to a particular platform and is difficult to migrate to other platforms. Cloud native applications also have these two characteristics. For cloud native applications, it is not a problem that it is difficult to migrate. After all, after migrating to the cloud platform, you will not want to migrate back.

Characteristics of cloud native applications

Compared with other applications, to sum up, cloud native applications have the following 15 characteristics.

1. Single code base

Cloud native applications must have a single code base and be tracked in the version management system. A single code base can be a version library or multiple version libraries that share the same root directory, and its importance is that each code Commit corresponds to an immutable build. After each code submission, the continuous integration process is triggered, resulting in a series of application container images, which establishes an one-to-one correspondence between the code submission and the build. This one-to-one relationship ensures that each build is traceable and that code changes between different versions can be compared.

For the application of micro-service architecture, each application consists of multiple services, which should be managed by a single code base, which ensures the stability of the build. If a change involves multiple services, the modification of all related services should be completed in one code submission; if the code of the service is scattered in multiple code bases, the change will be divided into multiple code commitations. each code submission triggers a continuous integration process, resulting in a build version of the corresponding service, which contains only partial changes and is incomplete. When the application is deployed, some services may contain some changes, while others may not, which makes the deployed application actually unable to work. Therefore, the application of micro-service architecture should use a single code base.

2. API priority

Cloud native applications should adopt the design strategy of API priority. The application of the microservice architecture uses the public API as the external interface of the service, and the API shields the internal implementation details of the service. The API first design strategy means that during the design phase, the API should be designed first and the details of the API should be determined. The design process of API requires the participation of multiple teams, including implementers and potential users of API, who have finally completed the definition of API in full discussion. API can be described using the OpenAPI specification from which API documents and mock servers can be generated.

The strategy of API priority ensures the stability of API while reducing unnecessary later modifications. Because API is the interface between services, modifying API means that the relevant internal implementations, test cases and consumers of API all need to be modified. If it is necessary to modify API in application development, it will have a great impact. API gives priority to ensuring that there are as few changes to API as possible in development.

Another benefit of API priority is that it can improve development efficiency. Once API is determined, tools can be used to generate documents and simulate servers, and users of API can write code that uses API based on the documentation. Testers can write API-related test cases and run the tests with a simulation server. Different teams can work in parallel to improve efficiency.

3. Dependency management

Cloud native applications should manage their own dependencies, and Java developers should be familiar with dependency management. The commonly used Java building tools Maven and Gradle provide dependency management support. In the development process, you only need to make use of the support of the build tool; when managing dependencies, you need to distinguish between the dependencies provided by the application and those provided by the running environment. Cloud native applications usually contain all the required dependencies, especially those that run in container form. A typical example is the REST API of microservices. Cloud native applications come with embedded servers such as Tomcat to provide HTTP services.

4. Design, build, release and run

Cloud native applications should have a complete design, build, release, and run process, as shown in the following figure.

Design

Design is essential in the development of cloud native applications. Traditional applications usually use the waterfall development process, which allocates enough time for design. Cloud native applications generally adopt agile software development processes, but this does not mean that the design is no longer important, but the design process becomes an iterative process, and the scope of each design is small. Usually only some new features need to be designed.

Construction

The build phase creates binary artifacts with version numbers from a single code base, and the build process is usually completed by the continuous integration server. Each build must have a unique version number, and the built binary artifacts are immutable. This ensures that after the same build has been tested, the deployed version is consistent with the tested version.

Publish

Push the built artifacts onto the cloud platform and you get a release that contains configuration information related to the deployment environment. When cloud native applications are deployed, there are usually three environments: development, testing and production, and the configuration information in each environment is different. Releases are also immutable, with a unique release number, and each build may correspond to multiple releases.

Running

The run phase runs applications on top of the cloud platform, depending on the cloud platform, and can be a virtual machine or a container. The cloud platform is responsible for managing the operation of the application, including monitoring the running status of the application, dealing with failures and dynamic horizontal expansion.

5. Code, configuration, and credentials

Code, configuration, and credentials are three different types of entities created in cloud native application development. The code includes source code and related resource files; configuration is configuration information related to the deployment environment, usually in the form of XML, YAML, JSON or properties files. The information contained in the configuration includes the connection method of third-party services, database connection information and the configuration properties of the application itself. Credentials refer to sensitive information such as passwords, private keys and API keys.

The difference between code and configuration is that code does not change with the deployment environment, while configuration is the opposite. In practice, the configuration should be separated from the application and externalized as far as possible, the constructed binary artifacts do not contain any configuration information, and the actual configuration value is determined according to the environment at the time of deployment. At run time, environment variables are generally used to pass configuration values, and specialized configuration servers such as Spring Cloud Config can be used to manage configuration values, and credentials should be removed from the source code repository.

6. Log

Log is an indispensable part of application development. Unlike traditional applications, cloud native applications do not need to configure the output mode of logs, but simply write logs to standard output streams (stdout) and standard error streams (stderr). Log collection and processing are provided by other services on the cloud platform, which frees application developers from tasks related to log management. There are many log management services on the cloud platform, and typical open source implementations include Elastic technology stack (ElasticSearch + LogStash + Kibana) and Fluentd.

7. Can be discarded at any time

The life cycle of cloud native applications may be short and may be terminated at any time. The cloud platform may start and stop instances of applications at any time, which requires that native cloud applications start and stop very quickly. When the load of the application suddenly increases, you can quickly start a new instance to process the request; when there is a problem with the instance of the application, you can quickly start a new instance instead. Stopping applications quickly is as important as starting applications quickly. Stopping applications quickly ensures that resources can be released in a timely manner.

8. Support service

Cloud native applications can not run without supporting services. Support service is a broad concept, including database, message middleware, caching, user authentication and authorization, storage and so on. The configuration information to connect these support services should be extracted and the actual values should be provided at run time based on the deployment environment.

9. Environmental equivalence

Different deployment environments for cloud native applications are the same. There should be no difference between development, testing and production environment. The equality of environment ensures that cloud native applications can be deployed quickly. This feature and the invariance of building artifacts complement each other, and both are indispensable. With these two features, each unique version of the build artifact can be deployed to a different environment in turn, and the tested version on the test environment can be deployed directly to the production environment. We can make sure that the behavior of the application in the production environment is the same as in the test environment.

10. Administrative tasks

Cloud native applications may need to perform some management tasks, such as generating reports or performing one-time data queries, which are usually not part of the business process, but more for the needs of management and operation and maintenance. These tasks will be performed using the supporting services that cloud native applications rely on. For these tasks, separate applications should be created and run on the same cloud platform. For tasks that are performed on a regular basis, you can take advantage of the support of the cloud platform, for example, Kubernetes provides support for scheduled tasks (CronJob).

To generate reports, for example, you can create a separate application to read the database and generate reports, the application can have its own independent container image. If report generation is triggered manually, the application should run independently and provide an API interface to allow external triggers. If the report is generated on a regular basis, you can create a corresponding scheduled task to run the container when the application is deployed, and automatically generate the report when the container starts. After the report is generated, the container runs to an end. The following figure illustrates the difference between the two trigger methods. The border of the rounded rectangle represents the boundary of the application.

11. Port binding

Cloud native applications are not responsible for managing the actual port binding at run time, but are managed by the cloud platform. For example, a Spring Boot-based micro-service application usually runs HTTP services on port 8080. When the application runs on the cloud platform, this port is only the port in the virtual machine or container, not the actual port when external users or other services access. The cloud platform manages the network uniformly and is responsible for allocating the actual ports. the cloud platform also provides a corresponding mechanism to discover the actual address and port of the access service.

12. Stateless process

Cloud native applications should be stateless. All status information should be extracted from the application and stored in supporting services, such as databases. It is precisely because the application is stateless that it can be quickly started and stopped by the cloud platform and expanded vertically or horizontally.

13. Concurrency

Cloud native applications use horizontal scaling to run multiple instances concurrently and load balancers to assign requests to an instance for processing.

14. Telemetry data

Cloud native applications need to collect a series of telemetry data, including application performance indicators, running status and logs, which are equally important for cloud platforms and applications. Cloud platforms can automatically scale horizontally with performance metrics. For example, Kubernetes supports automatic horizontal scaling of Pod. When the utilization of CPU exceeds a predetermined threshold, a new Pod is automatically launched to process requests. Performance metrics are divided into two categories: one is business-independent, such as the number of requests, the processing speed of requests, and the average request processing time; the second is business-related, which needs to be collected by applications according to business requirements, such as the number of orders processed and the sales of different goods. Cloud native applications usually create dashboards to display the overall running status in real time, making it easy for operators to monitor.

15. Authentication and authorization

Cloud native applications should be secure, and security should be fully considered at the design stage of the application. In the implementation, role-based access control (RBAC) can be used to protect API, and there are a large number of open source frameworks to help achieve authentication and authorization.

So much for sharing about what the cloud native application is. 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 for more people to see.

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.