Cloud platform management architecture, management method, management device, and storage medium

Abstract

A cloud platform management architecture, a management method, a management device, and a computer-readable storage medium are provided. The cloud platform management architecture (100) includes a first management device (200) configured to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load, a second management device (300) connected to the first management device (200) and configured to determine a capability boundary corresponding to the application capability according to the application capabilities from the first management device (200), the capability boundary being for representing each candidate cloud platform supporting the application capability, and an application orchestration and instantiation device connected to the first management device (200) and configured to determine an application orchestration and instantiation policy for each candidate cloud platform according to the capability boundary.

Description

[Technical field]

[0001] This application is filed based on a Chinese patent application with application number 202110915014.6 and filing date of August 10, 2021, and claims priority to the Chinese patent application, the entire contents of which are hereby incorporated by reference into this application.

[0002] The embodiments of the present application relate to, but are not limited to, the field of cloud native scene applications, and in particular to a cloud platform management architecture, a management method, a management apparatus, and a computer-readable storage medium. [Background technology]

[0003] Currently, most application orchestration on cloud platforms is performed in conjunction with cloud platforms, and cloud-native applications are orchestrated using native resources provided by the cloud platform. Due to the limited variety of resources, if the orchestration system hard-codes the various resource types of the cloud platform, it cannot make full use of the various resources provided by the cloud-native ecology, and there is no portability between various cloud platforms. In other words, for application developers, cloud platforms are in a capability dilemma. Most Platform as a Service (PaaS) systems are limited in the types of applications they support and the functions they support. This is reflected by the inability to extend and create their own plug-in system and maintain it by their own community. Meanwhile, this plug-in mechanism can only be applied to the closed, small-scale ecological capabilities dedicated to the PaaS system, and cannot be used reliably on a large scale. In addition, in practice, applications are designed for multi-cloud management systems, where a central room centrally manages different cloud platforms, and there are certain differences between different cloud platforms. Therefore, during orchestration, the available orchestration elements can usually only encapsulate some simple generic resources, and cannot design the capabilities of different plug-ins for a specific cloud platform. As a result, the orchestration capabilities are entirely dependent on simple resource encapsulation, and what fields are exposed is entirely dependent on the developer's understanding of the application. If a field needs to be updated later, it can only be resolved by modifying the code or redoing the version, which is not very flexible. In addition, a large number of operation and maintenance-related plug-ins cannot be used in the cloud native ecology, and complex application features cannot be orchestrated, resulting in a decline in the overall orchestration effect. Summary of the Invention [Problem to be solved by the invention]

[0004] The following provides a summary of the subject matter described in detail herein, without limiting the scope of protection of the claims.

[0005] The embodiments of the present application provide a cloud platform management architecture, a management method, a management apparatus, and a computer-readable storage medium. [Means for solving the problem]

[0006] In a first aspect, embodiments of the present application provide a cloud platform management architecture, comprising: a first management device configured to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load; a second management device connected to the first management device and configured to determine, according to the application capabilities from the first management device, a capability boundary corresponding to the application capabilities, the capability boundary being for representing each candidate cloud platform supporting the application capabilities; an application orchestration and instantiation device coupled to the first management device and configured to determine an application orchestration and instantiation policy for each of the candidate cloud platforms according to the capability boundary.

[0007] In a second aspect, the present embodiment also provides a cloud platform management method applied to a cloud platform management architecture, the cloud platform management architecture including: a first management device; and a second management device connected to the first management device. The cloud platform management method includes: Controlling the first management device to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load; controlling the second management device to determine, in response to the application capabilities from the first management device, a capability boundary corresponding to the application capabilities, the capability boundary being for representing each candidate cloud platform supporting the application capabilities; and determining an application orchestration instantiation policy for each of the candidate cloud platforms according to the capability boundaries.

[0008] In a third aspect, the present embodiment also provides a cloud platform management apparatus, the cloud platform management apparatus including a memory, a processor, and a computer program stored in the memory and operable on the processor, the computer program executing the processor realizing the cloud platform management method according to the second aspect.

[0009] In a fourth aspect, the present embodiment also provides a method for producing a composition comprising: When executed by the processor, The cloud platform management method according to the second aspect is implemented. current A computer-readable storage medium having stored thereon computer-executable instructions for performing the method of the present invention is provided.

[0010] Other features and advantages of the present application will be set forth in the following specification, and in part will be obvious from the specification, or may be learned by the practice of the present application. The objectives and other advantages of the present application may be attained by the structure particularly pointed out in the description, claims and accompanying drawings.

[0011] The drawings are used to provide a further understanding of the technical solutions of the present application, constitute a part of the specification, and are used to explain the technical solutions of the present application together with the embodiments of the present application, and are not intended to limit the technical solutions of the present application. [Brief description of the drawings]

[0012] [Figure 1] FIG. 1 is a schematic diagram of a cloud platform management architecture according to one embodiment of the present application. [Diagram 2] FIG. 1 is a schematic diagram of a cloud platform management architecture according to one embodiment of the present application. [Diagram 3] FIG. 2 is a schematic diagram of a capacity boundary according to one embodiment of the present application; [Figure 4] FIG. 2 is a schematic diagram of a blueprint designer interface according to one embodiment of the present application. [Diagram 5] 1 is a flowchart of a cloud platform management method according to an embodiment of the present application; [Figure 6] 4 is a flowchart illustrating a method for managing a cloud platform according to an embodiment of the present application for determining a target cloud platform; [Figure 7] 4 is a flowchart of a cloud platform management method according to another embodiment of the present application; [Figure 8] 4 is a flowchart of a cloud platform management method according to another embodiment of the present application; [Figure 9] 4 is a flowchart illustrating a capacity boundary determination method according to an embodiment of the present application; [Figure 10]4 is a detailed flowchart of a cloud platform management architecture for accessing a cloud platform according to an embodiment of the present application; [Figure 11] 4 is a detailed flowchart of a cloud platform management architecture according to an embodiment of the present application distributing capability definitions to underlying cloud platforms; [Figure 12] 4 is a detailed flowchart of application instantiation performed by a cloud platform management architecture according to an embodiment of the present application; DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0013] In order to make the objectives, technical solutions and advantages of the present application clearer, the present application will be described in more detail below with reference to the drawings and examples. The specific examples described in this specification are only used to interpret the present application, and are not used to limit the present application.

[0014] It should be noted that although the capability module division is shown in the schematic diagram of the device and the logical order is shown in the flowchart, in some cases the division of modules within the device may differ, or the steps shown or described may be performed in a different order than shown in the flowchart. Terms such as "first", "second", etc. in the specification and claims and the aforementioned drawings are not used to describe a particular order or priority, but are used to distinguish between similar objects.

[0015] The present application provides a cloud platform management architecture, a management method, a management device, and a computer-readable storage medium. In a specific scenario of an open application model, a first management device defines multiple application capabilities, so that capability abstraction of cloud native applications can be realized. As a result, the differentiation scenarios of each cloud platform can be consistently represented, and the portability of cloud native applications between each cloud platform can be improved. In addition, a second management device determines a capability boundary for representing candidate cloud platforms that support the defined application capabilities, and assists an application orchestration and instantiation device in determining an application orchestration and instantiation policy for each candidate cloud platform according to the capability boundary. As a result, the effects of managing the differentiation scenarios of multiple cloud platforms and optimizing application orchestration and instantiation can be obtained.

[0016] Hereinafter, the embodiments of the present application will be further described with reference to the drawings.

[0017] As shown in FIG. 1, FIG. 1 is a schematic diagram of a cloud platform management architecture 100 according to one embodiment of the present application.

[0018] 1, the cloud platform management architecture 100 may include, but is not limited to, a first management device 200. The first management device 200 is configured to define at least one application capability based on an open application model, where each application capability represents a load supported by one cloud platform or an operation and maintenance characteristic acting on the load.

[0019] Specifically, the cloud platform to which the cloud platform management architecture 100 of the embodiment of the present application is applied may have a cloud infrastructure as its core, and may operate on standardized hardware equipment and enhanced customized hardware equipment. The cloud platform may provide basic virtual single or mixed resource services such as virtual machines, bare metal, and containers to the outside, may provide technology components, networks, and business services in an integrated manner, and may be expanded as necessary to provide a cloud native technology stack for multiple products.

[0020] In one embodiment, the above standardized hardware equipment and enhanced customized equipment include, but are not limited to, general-purpose servers, memory, network equipment, customized all-in-one machines, smart network cards, acceleration hardware, etc.

[0021] Specifically, in the embodiment of the present application, the cloud platform may be a container cloud platform based on a K8S platform, or may be a dual-core cloud platform based on K8S and Openstack. The embodiment of the present application does not particularly limit the type of the cloud platform.

[0022] In one embodiment, the Open Application Model (OAM) is a standard specification for building and delivering cloud-native applications. Compared to traditional platforms, such as PaaS, which are closed and cannot integrate with the cloud-native ecology based on capabilities operators, a modern cloud-native application management platform built on OAM and K8S is essentially an "application-centric" K8S, ensuring that the application platform has seamless access to the entire cloud-native ecology. OAM also further shields the complexity and variance of container infrastructure, bringing a low-effort, standardized, and consistent application management and delivery experience to cloud platform users.

[0023] In the present application, application capabilities may refer to, but are not limited to, atomic functions that can compose a complete application and may be considered as abstractions of capabilities that a cloud platform provides to an application definer, primarily described as the loads it supports or the operational maintenance characteristics that act on those loads. Supporting these capabilities allows application definers to define cloud native applications that meet the requirements of their business.

[0024] Specifically, load includes, but is not limited to, various forms of workloads, such as functions, containers, cloud resources, and virtual machines. Load is used to describe how an application is operated. Operational characteristics include, but are not limited to, various operational capabilities, such as traffic management, release policies, elasticity policies, and observability policies. Finally, the cloud platform itself can provide differentiated scenarios for end users through the combination of different loads and operational characteristics, helping users define cloud-native applications.

[0025] In one embodiment, application capabilities are defined using standard templates, with reference to the method of defining application capabilities agreed upon in the Open Application Model specification.

[0026] In one embodiment, application capabilities are divided into load capabilities and trait capabilities. Load capabilities may be defined in a standard template of the Open Application Model Specification. For example, it may be defined in core.oam.dev / v1alpha2.WorkloadDefinition with oam-kubernetes-runtime. Trait capabilities may be defined in core.oam.dev / v1alpha2.TraitDefinition with oam-kubernetes-runtime. Both the workload definition and trait definition are K8S Custom Resource Definitions (CRDs), so the capability definitions can be obtained from the cloud platform by CRD type.

[0027] Specifically, referring to the open application model, depending on the characteristics of the application capabilities, the workload types can be divided into a core workload type, a standard workload type, and an extended workload type, and the trait capability range can be divided into a core trait range, a standard trait range, and an extended trait range.

[0028] Among these, the capabilities of the core characteristic range are capabilities predefined by an open application model. The capabilities of the standard characteristic range are application capabilities that can be realized by the device according to the embodiment of the present application, and in actual applications, operations on most cloud platforms can be supported. The capabilities of the extended characteristic range are application capabilities obtained based on secondary development of cloud platform users targeted by the device according to the embodiment of the present application, and various application capabilities required for application definition can be developed using various plug-ins widely available in the open source community in cooperation with the cloud platform ecology. Usually, the application capabilities of the core characteristic range and the standard characteristic range are not changed, and the application capabilities of the extended characteristic range can be updated and dynamically enabled at any time.

[0029] In one embodiment, the load capabilities of the K8S cloud platform can be defined by referencing resource or CRD definitions predefined by K8S, i.e., by a yaml file. If a new CRD needs to be introduced, a corresponding capability operator or a basic dependency plugin needs to be added. If a characteristic capability requires support by a basic plugin, the corresponding capability operator and basic plugin may be added as needed. Here, the capability definition supports defining initialization actions to load these capability operators and plugins.

[0030] In one embodiment, the application capability definition itself may be expressed in JavaScript Object Notation (JSON). Additionally, the application capability definition may be developed using a template language, including but not limited to CUELang or Helm.

[0031] In addition, the first management device 200 is also configured to determine, according to the target cloud platform and the application capabilities, target application capabilities supported by the target cloud platform, and send a target capability definition packet corresponding to the target application capabilities to the target cloud platform.

[0032] In one embodiment, when a cloud platform is incorporated into the management scope of the first management device 200, the first management device 200 may proactively discover the set of capabilities supported by the cloud platform. Since application capabilities are defined in the Open Application Model Specification, all load definition and characteristic definition instances can be queried through the K8S native interface to obtain detailed information such as the corresponding application capability description and operating range.

[0033] In one embodiment, the application capabilities discovered by the first management device 200 are persisted in a database of the first management device 200, a correspondence table is formed that stores the correspondence between cloud platforms and capabilities, and ultimately, a set of capabilities for each of the multiple cloud platforms managed by the first management device 200 is formed.

[0034] It should be noted that the capability sets for different instances of a cloud platform may be the same or different.

[0035] In one embodiment, the first management device 200 may support capability types defined in the Open Application Model Specification and also supports a set of predefined capabilities, such as capabilities corresponding to resource types predefined by K8S, which may be supported by default by most cloud platforms.

[0036] In one embodiment, the first management device 200 provides a capability definition specification, maintains various capabilities using a capability database, provides multiple predefined capabilities, and provides the ability for users to load secondary development and import capabilities defined in the cloud native community. All capability definitions are persisted in the capability database. In addition, capability discovery and capability delivery are performed for each cloud platform with access to the instance of the cloud platform, and the device simultaneously establishes a correspondence relationship between each capability and the instance of the cloud platform it manages in the capability database, and determines the capability set supported by each cloud platform. The embodiment of the present application also supports a remote capability repository. Various capabilities contributed by the open source community may be placed in the capability repository. The remote capability repository can be deployed to seamlessly cooperate with the cloud native ecology.

[0037] When a cloud platform is incorporated into the management of the first management device 200, first, it is confirmed that a capability operator exists in the cloud platform. Here, the capability operator is configured to process the defined application capabilities, and its specifications and contents can be selectively set according to the situation. If the capability operator does not exist, it is necessary to deliver the capability operator in a cloud native manner. When the first management device 200 accesses the cloud platform, it delivers various pre-configured capabilities to the target cloud platform, so that the target cloud platform has the corresponding capabilities. Since the capability definitions are K8S CRDs, these capability definitions can be delivered in a K8S native manner.

[0038] In addition, the platform developer may subsequently define more capabilities according to the open application model specifications, incorporate them into the management of the first management device 200, and specify and distribute them to the corresponding cloud platform. It is also possible to continuously expand the capabilities managed by the first management device 200 by using various open source capabilities in the K8S ecology in the cloud native community and importing them into the first management device 200. Furthermore, if an existing capability definition is changed, the capability definition may be redistributed and updated in the corresponding cloud platform.

[0039] In addition, if the capability definition package required for application definition and its dependent plug-in packages already exist in this device, the capability definition package may be distributed and loaded into the corresponding cloud platform system as necessary when the application is instantiated.

[0040] 1, the cloud platform management architecture 100 according to an embodiment of the present application further includes a second management device 300. The second management device 300 is connected to the first management device 200, and is configured to determine a capability boundary corresponding to the application capability according to the application capability from the first management device 200. The capability boundary is for representing each candidate cloud platform supporting the application capability.

[0041] Specifically, a capability boundary is the range of cloud platform instances that support a particular capability definition, which is closely related to the capability type and is also determined by the capability set supported by the cloud platform. For example, a pre-defined K8S platform capability works on all K8S-type cloud platforms. A capability defined in secondary development or an imported cloud native community-defined capability works on cloud platform instances that explicitly deliver the capability or that already have the capability installed on the cloud platform.

[0042] In addition, the second management device 300 is configured to check the operating status of the application capabilities from the first management device 200, adjust the application capabilities according to the operating status of the application capabilities, and determine a capability boundary corresponding to the adjusted application capabilities based on the adjusted application capabilities.

[0043] In addition, the capability definition itself is related to various operations such as cloud platform resources and plugins, and has a certain degree of complexity. It is necessary to consider the processes of development, testing, distribution, etc. The network hook (Webhook) mechanism of K8S can check the capability definition, check the validity of the capability definition YAML, inspect the validity of the capability definition template language, and verify the satisfaction of capability definition dependent resources and basic plugins.

[0044] The second management device 300 also provides a capability testing sandbox, which simulates and tests capabilities immediately after they are online, and assists in analyzing the test output to ensure that capability development meets the needs of users. The capability sandbox is a capability simulation execution environment, which is isolated from the production environment and adopts a simulation method for many capability-related logic executions, does not execute real resource operation operations, and can simulate the effect of the capability when it is actually executed to a certain extent, and helps capability developers judge the accuracy of the logic through the output. After passing the sandbox pre-test, the capability can be loaded into the formal cloud environment to provide services. In addition, in the capability definition upgrade scenario, a test capability can be provided by a webhook, which first guides some capability creation requests to the new version of the capability definition implementation, and replaces the old version with the new version according to the execution effect.

[0045] 1, the cloud platform management architecture 100 according to an embodiment of the present application further includes an application orchestration device 400. The application orchestration device 400 is connected to the first management device 200 and configured to determine an application orchestration policy for each candidate cloud platform according to a capability boundary.

[0046] In addition, the conventional application orchestration system basically adopts a hard-coding mode, and realizes a hard-coding orchestration interface according to the resource type of a specific cloud platform, but it is not extensible itself, and the defined application is not portable, so it cannot manage the difference in capabilities of multiple cloud platforms. Compared to the conventional hard-coding application orchestration system, the application orchestration device 400 of the embodiment of the present application can flexibly utilize application capability elements, dynamically generate application orchestration elements based on the capability template definition in the capability definition database, and allow the application definer to use the orchestration elements in correspondence with each other according to the capability boundary. In addition, the constantly introduced new capability definitions continuously improve the application-defined orchestration capabilities supported by the device, and make better use of cloud native shaping.

[0047] It should be noted that the application orchestration apparatus 400 of the embodiment of the present application is configured to determine a target cloud platform for executing the application instantiation from each candidate cloud platform according to the capability boundary.

[0048] A user may select a preset capability definition element when orchestrating an application, and depending on the selected cloud platform instance, various extended capability definitions may be used utilizing capability boundaries, or the capability boundaries may be ignored and all capability definitions managed by the application orchestration device 400 may be used to act on the capability boundaries until the application is instantiated.

[0049] Application definitions generated by embodiments of the present application may be packaged by Helm into CHART packages for instantiation.

[0050] During application instantiation, the actions of the capability definition need to be executed. The capabilities defined in this application are provided by K8S CRDs, and the corresponding capability CRDs need to be executed by a capability operator. The capability operator needs to provide a corresponding controller to realize the related logic. The capability operator converts the capabilities defined in the CRD into cloud platform native resources or custom resources according to the capability reference definition in the case of load capabilities, and executes the corresponding logic according to the capability template definition in the case of characteristic capabilities, and may also be assisted by other operators or controllers of the cloud platform and basic plug-ins.

[0051] When orchestrating a blueprint-instantiated application, the embodiment of the present application may select a cloud platform instance that supports the application according to the capability boundary, and proactively deliver the capabilities required by the application to the target cloud platform under corresponding conditions, thereby endowing the cloud platform with capabilities, creating application execution conditions, and finally ensuring that the defined application can be successfully instantiated on the cloud platform, and ensuring the portability of the application across different cloud platforms.

[0052] In addition, the cloud platform management architecture 100 of the embodiment of the present application further includes a capability database configured to store at least one capability template corresponding to at least one application capability. The capability database is connected to the application orchestration device 400 through the first management device 200. The application orchestration device 400 is also configured to generate, based on the capability template from the capability database, a programmable application capability orchestration element corresponding to the capability template.

[0053] The cloud platform capability templates managed by the first management device 200 are eventually persisted in a capability database, thereby providing continuous management of capabilities and later generating orchestration interfaces based on the capability data. The capability database also provides interfaces for registering, querying, updating, and deleting capability definition templates. For example, GET{apiRoot} / app_lcm / v2 / capabilities defines an interface to query all capability template definitions in the cloud platform, GET{apiRoot} / app_lcm / v2 / capabilities / :id defines an interface to query capability template information for a specified ID in the cloud platform, and 3. POST{apiRoot} / app_lcm / v2 / capability defines an interface to send a capability template customized by the user to the cloud platform.

[0054] In one embodiment, the application orchestration apparatus 400 may present all predefined capabilities during orchestration since its capability boundary is the entire set of cloud platforms, and may provide the application definer with the union of capabilities of one or more cloud platform instances on which the defined application will subsequently be executed, if such a capability boundary can be specified during orchestration, so that the defined application can subsequently be successfully instantiated on the target cloud platform.

[0055] In addition, some cloud platforms may be incorporated into the management of the first management device 200 later, so there is no need to focus on the difference in the capability set of each cloud platform to orchestrate the application. In addition, various capabilities may be actively installed in the cloud platform instances after being incorporated into the first management device 200. Therefore, the user may select all the capability types managed by the first management device 200 as needed. During instantiation, the candidate target cloud platform instances may be filtered by capability boundaries. Only cloud platform instances with capability boundaries corresponding to all the capabilities required to support the application are filtered and selected by the user. This can also effectively ensure that the application is successfully instantiated in the target cloud platform.

[0056] In one embodiment, the first management device 200 may extend the capability set of an instance of a cloud platform and extend the capability boundary of a capability. If a corresponding capability definition package and a plug-in package on which the capability definition package depends exist in the first management device 200, the capability definition package may be distributed to and installed on the corresponding cloud platform. This may provide the cloud platform with the capability to support the deployment of applications that the cloud platform does not originally support.

[0057] Therefore, in the embodiment of the present application, in a specific scenario of an open application model, the first management device 200 defines multiple application capabilities, so that capability abstraction of cloud native applications can be realized. As a result, the differentiation scenarios of each cloud platform can be consistently represented, and the portability of cloud native applications between each cloud platform can be improved. In addition, the second management device 300 determines a capability boundary for representing candidate cloud platforms that support the defined application capabilities, and assists the application orchestration device 400 in determining an application orchestration policy for each candidate cloud platform according to the capability boundary. As a result, the differentiation scenarios of multiple cloud platforms can be managed, and the effect of optimizing application orchestration can be obtained.

[0058] In order to more clearly explain the working principles of the above various embodiments, a specific example will be given below.

[0059] Example 1 Please refer to FIG. 2, which is a schematic diagram of a cloud platform management architecture according to an embodiment of the present application.

[0060] In the example of Fig. 2, the first cloud platform includes a capability manager and a capability operator. The capability manager is a capability management control plane configured for capability management. The capability operator is a capability management data plane configured for capability loading, execution and application package instantiation, e.g., application instances of the second cloud platform and the third cloud platform. The first cloud platform also has a data plane function.

[0061] Here, the capacity management control plane provides capacity definition by adopting a standard template by referring to the capacity definition method agreed upon in the open application model specification. It clarifies the capacity range of each cloud platform by abstracting the elements that support the application definition by capacity and differentiating and managing the capacity of multiple lower cloud platforms. It also persists the capacity of each cloud platform in a capacity definition database, and finally provides complete capacity management. It provides capacity delivery by delivering pre-configured capabilities and user-customized extended capacity sets to the target cloud platform when accessing the lower cloud platform. It provides capacity discovery of multi-cloud platforms by querying the details of all load definitions and characteristic definitions in K8S and obtaining detailed information such as corresponding capacity descriptions and operating ranges.

[0062] The capability management control plane distributes and loads capability operators for the data plane when accessing each lower cloud platform. Thus, when the lower cloud platform receives the capability template definition distributed from the control plane, it has capabilities that depend on the legality of the capability definition template language and the satisfaction of cloud platform resources and basic plug-ins. In addition, the capability operator provides a capability test sandbox module to simulate and test the capability immediately after going online, and assists in analyzing the test output to ensure that the capability development meets the needs of the user, and finally ensures smooth capability loading. In addition, the capability operator provides a test capability for the capability definition upgrade scene, guides some capability creation requests to a new version of the capability definition implementation, and gradually replaces the old version with the new version according to the execution effect. The blueprint orchestrator obtains the capability template definition of the capability definition database from the capability management control plane, dynamically generates application orchestration elements, and may also allow the application definer to flexibly select the orchestration elements according to the capability boundary. The user uses the orchestrator to publish the application package file to the control plane. During instantiation, the control plane determines the cloud platform that can be deployed according to the capability boundary, and distributes the application package to the lower cloud platform. After receiving the application package orchestrated by the blueprint, the lower cloud platform converts each capability used in the application definition into cloud platform CRD and K8S native resources through the capability operator of the data plane, thereby instantiating the application package.

[0063] Example 2 Please refer to FIG. 3, which is a schematic diagram of the capacity boundaries of an embodiment of the present application.

[0064] In the example of FIG. 3, capabilities are divided into three types, namely, Core Capability (CC), Standard Capability (SC), and Extended Capability (EC), according to the capability characteristics of operation and maintenance and workload.

[0065] Here, CC is a predefined capability of the open application model. SC is a capability that is realized by default by the cloud platform management architecture of the embodiment of the present application and can support operation on most cloud platforms. EC is a capability that is secondarily developed by the cloud platform user based on the cloud platform management architecture of the embodiment of the present application, and can develop various capabilities required for application definition by connecting with the cloud platform ecology and using various plug-ins widely available in the open source community. The capabilities of CC and SC cannot be changed, and EC is updated and enabled dynamically.

[0066] Therefore, in the case of a multi-cloud platform, the CC and SC of each platform are the same. That is, in Fig. 3, the fourth cloud platform, the fifth cloud platform, and the sixth cloud platform all have the same first core capability, second core capability, and third core capability. In the embodiment of the present application, the entire set of CCs and SCs is called a preset capability set, and its capability boundary is all cloud platforms, which are the fourth cloud platform, the fifth cloud platform, and the sixth cloud platform in Fig. 3.

[0067] In addition, since ECs are generally secondary developed by users, different cloud platforms may have different or identical ECs when actually operated, depending on the user's distribution situation and the infrastructure of the cloud platforms. Therefore, in terms of capability boundaries, different ECs may have the same or different capability boundaries. Taking FIG. 3 as an example, the capability boundaries of the first extended capability and the fourth extended capability are the fourth cloud platform and the fifth cloud platform. The capability boundaries of the second extended capability and the third extended capability are the fourth cloud platform. The capability boundary of the fifth extended capability is the fifth cloud platform. The capability boundaries of the sixth extended capability, the seventh extended capability, and the ninth extended capability are the sixth cloud platform.

[0068] Example 3 Please refer to Figure 4, which is an interface diagram of the blueprint designer according to an embodiment of the present application. The blueprint designer is composed of an orchestration element bar, a capability screening bar, a capability full set radio box, an attribute input box, a canvas, and necessary buttons.

[0069] Here, the orchestration element bar on the left mainly shows various capabilities supported by the cloud platform management architecture of the embodiment of the present application, including pre-defined capabilities and extended capabilities, which are elements required for application definition.

[0070] Capability screening supports the creation of an application package by specifying the cloud platforms on which the package can be deployed through capability boundaries. When the capability screening box is selected, the capability screening bar lists all underlying cloud platforms accessed by the cloud platform management architecture of the embodiment of the present application for selection. In response to the selection, the extended capabilities portion of the orchestration element bar displays the union of the extended capability sets of all selected cloud platforms. Since all required capabilities are supported, the applications of the orchestration in this scene can be directly instantiated on these selected cloud platforms.

[0071] The blueprint designer also supports not specifying the cloud platform by capability boundary, i.e., the full set of capabilities selection box, when creating a package. The cloud platform management architecture of the present example shows the union of all cloud platform extended capability sets in the extended capabilities portion of the capability selection bar when the full set of capabilities selection box is checked. The application definition can maximize the capabilities managed using the cloud platform management architecture of the present example. When the application is deployed using this package, the capability boundary comes into play.

[0072] Finally, when a particular capability definition is selected on the Blueprint Designer canvas, the designer dynamically displays in the attribute bar the capability definition parameters that can be created based on the capability definition in the capability definition database.

[0073] The following is a process for defining an application using an embodiment of the present application: For example, when defining a virtual Content Delivery Network (vCDN) content service application (App) for 5G edge services, generic characteristics include running as a container, exposing web services to the outside world, and supporting elasticity, and traffic characteristics include providing appropriate edge routing.

[0074] The initialization actions include accessing individual edge clouds to support the operation of the vCDN App. The capabilities of these edge clouds are found in the cloud platform management architecture of the embodiment of the present application, for example, specific capabilities to support edge application shunting.

[0075] The orchestration process includes the following:

[0076] Open the application blueprint orchestrator of the cloud platform management architecture of the embodiment of the present application and start defining the application. The edge cloud platform on which the vCDN App can run may be selected in the capability selector. The blueprint orchestrator displays the orchestrator element bar according to the capability database and capability boundaries. The orchestrator elements include general capabilities such as container load, elasticity characteristics, and edge cloud specific capabilities such as diversion capabilities and extended capabilities. According to the needs of the vCDN App, drag the container load, elasticity characteristics, ingress capabilities, and diversion capabilities of the orchestrator onto the canvas to define the application. For specific capabilities, the corresponding attributes may be set on the right edge of the orchestrator based on the capability definition. In addition, the user needs to upload an image of the business container and set the image name in the Image attribute of the container load. After defining the vCDN App, click Save to publish the App blueprint, i.e., the application defined by the user.

[0077] In one embodiment, a vCDN App blueprint may be selected, a specific cloud platform may be selected, an application instantiation action may be performed, and finally the App may be deployed to a specific edge cloud. The App may modify traffic rules to direct edge-side content service requests to the App, cache various content information, and serve it to nearby users. The App also provides a management interface to the operation and maintenance user through Ingress.

[0078] From the above, most of the conventional application orchestration systems are hard-coded, and have characteristics such as lack of scalability, lack of portability of defined applications, and inability to respond to the difference in capabilities of multi-cloud platforms. In contrast, the cloud platform management architecture according to the embodiment of the present application can flexibly apply application capability elements, dynamically generate application orchestration elements based on capability template definitions in a capability definition database, and allow application definers to flexibly select orchestration elements according to capability boundaries. In addition, by constantly introducing new capability elements, the application-defined orchestration capabilities supported by the cloud platform management architecture of the embodiment of the present application can be continuously improved and the cloud native ecology can be more effectively utilized. In other words, in response to the dilemma of application-defined capabilities in the existing cloud platform, the embodiment of the present application uses an open application model and a mature cloud native ecology to define cloud platform capabilities, and clearly proposes operations such as corresponding management of capabilities, capability type classification, and provision of pre-defined capabilities. Particularly in a multi-cloud scenario, it actively discovers application-defined capabilities such as application loads and operation and maintenance characteristics supported by each cloud platform, supports the development of various application capabilities based on various existing plug-ins of the cloud platform, and distributes them centrally to each cloud platform, endowing the cloud platform with capabilities. In addition, the embodiment of the present application also puts forward the concept of capability boundary, manages the capability difference between each cloud platform, and dynamically generates an application orchestration interface based on application capabilities and capability boundary, so as to help application developers orchestrate and deploy application blueprints on multi-cloud platforms, and further optimize the effect of application orchestration.

[0079] Based on the above cloud platform management architecture, various embodiments of the cloud platform management method of the present application are proposed.

[0080] As shown in Fig. 5, Fig. 5 is a flowchart of a cloud platform management method according to an embodiment of the present application, which is applicable to the cloud platform management architecture in the embodiment shown in Fig. 1. The cloud platform management method includes, but is not limited to, steps S100 to S300.

[0081] Step S100: Control the first management device to define at least one application capability based on an open application model, each application capability being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load. Step S200: Control the second management device so that the second management device determines, according to the application capability from the first management device, a capability boundary corresponding to the application capability, where the capability boundary is to represent each candidate cloud platform that supports the application capability. Step S300: Determine an application orchestration policy for each candidate cloud platform according to the capability boundary.

[0082] In a specific scenario of the open application model, the first management device defines multiple application capabilities, so that capability abstraction of cloud native applications can be realized. As a result, the differentiation scenarios of each cloud platform can be consistently represented, and the portability of cloud native applications between each cloud platform can be improved. In addition, the second management device determines capability boundaries to represent candidate cloud platforms that support the defined application capabilities, and assists the application orchestration device in determining application orchestration policies for each candidate cloud platform according to the capability boundaries. As a result, the differentiation scenarios of multiple cloud platforms can be managed, and the effect of optimizing application orchestration can be obtained.

[0083] In one embodiment, the first management device provides a capability definition specification, maintains various capabilities using a capability database, provides multiple predefined capabilities, and provides the ability for users to load secondary development and import capabilities defined in the cloud native community. All capability definitions are persisted in the capability database. In addition, capability discovery and capability delivery are performed for each cloud platform with access to the instance of the cloud platform, and the device simultaneously establishes a correspondence relationship between each capability and the instance of the cloud platform it manages in the capability database, and determines the capability set supported by each cloud platform. In the embodiment of the present application, a remote capability repository is also supported. Various capabilities contributed by the open source community may be placed in the capability repository. By deploying the remote capability repository, it is possible to seamlessly cooperate with the cloud native ecology.

[0084] In one embodiment, the capability definition itself is related to various operations such as resources and plugins of the cloud platform and has a certain degree of complexity. It is necessary to consider the processes of development, testing, distribution, etc. The network hook (Webhook) mechanism of K8S can check the capability definition, check the validity of the capability definition YAML, inspect the validity of the capability definition template language, and verify the satisfaction of the capability definition dependent resources and basic plugins.

[0085] In one embodiment, a pre-defined capability definition element can be selected when orchestrating an application. Also, depending on the selected cloud platform instance, various extended capability definitions can be used utilizing capability boundaries. Furthermore, the capability boundaries can be ignored and all capability definitions managed by the application orchestration device can be used to act on the capability boundaries until the application is instantiated.

[0086] The application definition generated by the embodiment of the present application is packaged by Helm into a CHART package for instantiation.

[0087] During application instantiation, the action of the capability definition needs to be executed. The capabilities defined in the embodiments of this application are provided by K8S CRDs, and the corresponding capability CRDs need to be executed by a capability operator. The capability operator needs to provide a corresponding controller to realize the related logic. The capability operator converts the capabilities defined in the CRD into cloud platform native resources or custom resources according to the capability reference definition in the case of load capabilities, and executes the corresponding logic according to the capability template definition in the case of characteristic capabilities, and may also be assisted by other operators or controllers of the cloud platform and basic plug-ins.

[0088] When orchestrating a blueprint-instantiated application, the embodiment of the present application may select a cloud platform instance that supports the application according to the capability boundary. If the condition is met, the capability required for the application may be proactively delivered to the target cloud platform, thereby endowing the cloud platform with capabilities and creating the application execution conditions. The ultimate goal is to ensure that the defined application can be successfully instantiated on the cloud platform and guarantee the portability of the application across different cloud platforms.

[0089] In addition, the cloud platform management architecture of the embodiment of the present application further includes a capability database configured to store at least one capability template corresponding to at least one application capability. The capability database is connected to the application orchestration device through the first management device. The application orchestration device is also configured to generate a programmable application capability orchestration element corresponding to the capability template based on the open application model.

[0090] As shown in FIG. 6, FIG. 6 is a detailed flowchart of step S300 of the cloud platform management method of FIG.

[0091] In the example of FIG. 6, step S300 includes, but is not limited to, step S310.

[0092] Step S310: Determine a target cloud platform for executing the application instantiation from each candidate cloud platform according to the capability boundary.

[0093] In one embodiment, the application orchestration device may present all pre-defined capabilities during orchestration, since its capability boundary is the entire set of cloud platforms, and may provide the application definer with the union of capabilities of one or more cloud platform instances on which the defined application will subsequently be executed, if such a union can be specified during orchestration, so that the defined application can subsequently be successfully instantiated on the target cloud platform.

[0094] Furthermore, some cloud platforms may be incorporated into the management of the first management device later, so there is no need to focus on the difference in the capability set of each cloud platform to orchestrate the application. Also, various capabilities may be proactively installed in the cloud platform instances after being incorporated into the first management device. Therefore, the user may select all the capability types managed by the first management device as needed. During instantiation, the candidate target cloud platform instances may be filtered by capability boundaries. Only cloud platform instances with capability boundaries corresponding to all the capabilities required to support the application may be filtered and selected by the user. This can also effectively ensure that the application is successfully instantiated in the target cloud platform.

[0095] In one embodiment, the first management device may extend the capability set of an instance of a cloud platform and extend the capability boundary of a capability, and if a corresponding capability definition package and a plug-in package on which the capability definition package depends exist in the first management device, the first management device may distribute and install the capability definition package to the corresponding cloud platform, thereby providing the cloud platform with the capability to support the deployment of applications that the cloud platform does not natively support.

[0096] As shown in FIG. 7, FIG. 7 is a flowchart of a cloud platform management method according to another embodiment of the present application.

[0097] In the example of FIG. 7, the cloud platform management method according to the embodiment of the present application further includes, but is not limited to, step S400.

[0098] Step S400: Control the first management device to determine, according to a target cloud platform and an application capability, a target application capability supported by the target cloud platform.

[0099] In the example of FIG. 8, the cloud platform management method according to the embodiment of the present application further includes, but is not limited to, step S410.

[0100] Step S410: Control the first management device to send a target capability definition packet corresponding to the target application capability to the target cloud platform.

[0101] In one embodiment, when a cloud platform is incorporated into the management scope of a first management device, the first management device proactively discovers the set of capabilities supported by the cloud platform. Because the capabilities are defined in the Open Application Model Specification, all load and characteristic definition instances can be queried through K8S native interfaces to obtain detailed information such as corresponding capability descriptions and operating ranges.

[0102] The capabilities discovered by the first management device are persisted in a database of the first management device, and a correspondence table that stores the correspondence between the cloud platforms and the capabilities is formed. Finally, a capability set for each of the multiple cloud platforms managed by the first management device is formed.

[0103] It should be noted that the capability sets for different instances of a cloud platform may be the same or different.

[0104] In one embodiment, the first management device supports capability types defined in the Open Application Model Specification and also supports a set of predefined capabilities, such as capabilities corresponding to resource types predefined by K8S, which may be supported by default by most cloud platforms.

[0105] When a cloud platform is incorporated into the management of the first management device, it is first confirmed that a capability operator exists in the cloud platform. If not, the capability operator needs to be distributed cloud natively. When the first management device accesses the cloud platform, it distributes various pre-configured capabilities to the target cloud platform, so that the target cloud platform has corresponding capabilities. Since the capability definitions are K8S CRDs, these capability definitions can be distributed K8S natively.

[0106] In addition, the platform developer may subsequently define more capabilities through the open application model specification, incorporate them into the management of the first management device, and specify and distribute them to the corresponding cloud platform. It is also possible to continuously expand the capabilities managed by the first management device by using various open source capabilities in the K8S ecology in the cloud native community and importing them into the first management device. Furthermore, if an existing capability definition is changed, the capability definition may be redistributed and updated correspondingly in the target cloud platform.

[0107] In addition, if the capability definition package required for application definition and its dependent plug-in packages already exist in this device, the capability definition package may be distributed and loaded into the target cloud platform system as necessary when the application is instantiated.

[0108] As shown in FIG. 9, FIG. 9 is a detailed flowchart of step S200 of the cloud platform management method of FIG.

[0109] In the example of FIG. 9, step S200 includes, but is not limited to, step S210.

[0110] Step S210: The second management device checks the operation status of the application capability from the first management device, the second management device adjusts the application capability according to the operation status of the application capability, and controls the second management device to determine a capability boundary corresponding to the adjusted application capability according to the adjusted application capability.

[0111] In one embodiment, the capability testing sandbox is used to simulate and test capabilities immediately after they are online, and to assist in the analysis of the test output to ensure that capability development meets the needs of users. The capability sandbox is a capability simulation execution environment that is isolated from the production environment and adopts a simulation method for many capability-related logic executions, without performing real resource operation operations, and can simulate to a certain extent the effect of the capability when it is actually executed, and the output helps capability developers to judge the accuracy of the logic. After passing the sandbox pre-test, the capability can be loaded into the official cloud environment to provide services. In addition, in the capability definition upgrade scenario, the test capability can be provided by webhook. First, some capability creation requests are guided to the new version of the capability definition implementation, and the old version is replaced with the new version according to the execution effect.

[0112] It should be noted that the cloud platform management method in this embodiment belongs to the same inventive idea as the cloud platform management architecture in the above embodiment, and therefore the specific embodiment of the cloud platform management method in this embodiment may refer to the specific embodiment of the cloud platform management architecture in the above embodiment, and has all the improvements of the cloud platform management architecture in the above embodiment, which will not be described here.

[0113] The cloud platform management method according to the embodiment of the present application further includes, but is not limited to, step S420.

[0114] Step S420: Generate a programmable application capability orchestration element corresponding to the capability template based on the open application model.

[0115] In one embodiment, by generating the application capability orchestration element through an open application model, users can flexibly use the application capability orchestration element, and the effect of application orchestration can be further optimized.

[0116] It should be noted that the cloud platform management method in this embodiment belongs to the same inventive idea as the cloud platform management architecture in the above embodiment, and therefore the specific embodiment of the cloud platform management method in this embodiment may refer to the specific embodiment of the cloud platform management architecture in the above embodiment, and has all the improvements of the cloud platform management architecture in the above embodiment, which will not be described here.

[0117] Example 4 Please refer to FIG. 10, which is a specific flowchart of the cloud platform management architecture according to the embodiment of the present application accessing the cloud platform.

[0118] In the example of FIG. 10, a specific process of the cloud platform management architecture according to the embodiment of the present application accessing the cloud platform includes the following steps: Step S500: Initiate an access operation to a cloud platform instance. Step S510: Distribute the capability operator through a Helm client, and load the capability operator into the target cloud platform. Step S520: Determine whether the loading of the capability operator is successful, and if so, proceed to step S530; if not, execute step S521. Step S521: Notify that access to the cloud platform has failed. Step S530: The loading of the prefabricated capability template Chart is distributed via the Helm client, and various plugins required for the prefabricated capability template are loaded. Step S540: Determine whether the loading of the prefab ability is successful, if so, proceed to step S550, otherwise execute step S541. Step S541: Uninstall the capability operator and notify the failure to access the cloud platform. Step S550: Through capability discovery, discover the capabilities supported by the newly accessed cloud platform. Step S560: Build the capability set data supported by the cloud platform into a capability definition database. Step S570: The capacity management boundary is updated.

[0119] Example 5 Please refer to FIG. 11, which is a specific flowchart of the cloud platform management architecture according to the embodiment of the present application distributing capability definitions to the underlying cloud platforms.

[0120] In the example of FIG. 11, a specific process of the cloud platform management architecture according to the embodiment of the present application distributing capability definitions to the underlying cloud platforms includes the following steps:

[0121] Step S600: The capability manager starts a capability definition distribution operation. Step S601: Determine whether a current capability definition exists in the target cloud platform, if so, proceed to step S610, if not, proceed to the next step. Step S602: Determine whether or not a current capability definition package exists in the own device; if so, deliver the capability definition package to the target platform and proceed to the next step; if not, proceed to step S609. Step S603: The capability operator of the target cloud platform checks the capability definition template, and judges whether the check is passed, if so, proceed to the next step, if not, proceed to step S609. Step S604: The capability operator of the target cloud platform parses the capability definition template and determines whether an initialization action initAction definition exists, and if so, proceeds to the next step; if not, proceeds to step S609. Step S605: A capability operator of the target cloud platform loads the plug-ins that the capability depends on into the cloud platform according to the initAction description in the capability definition. Step S606: The target cloud platform loads the capability definition into the sandbox and executes the capability sandbox test. Step S607: Determine whether the capability definition passes the sandbox test, if so, proceed to the next step, if not, proceed to step S609. Step S608: The target platform loads the capability definition while providing feedback that the capability has been successfully delivered. Step S609: A failure in loading the capability definition is notified, and the reason is fed back. Step S610: Notify that the delivery capability has been successful.

[0122] Example 6 As shown in FIG. 12, FIG. 12 is a specific flowchart of application instantiation in the cloud platform management architecture according to an embodiment of the present application.

[0123] In the example of FIG. 12, a specific process of application instantiation by the cloud platform management architecture according to the embodiment of the present application includes the following steps:

[0124] Step S700: Execute an application instantiation operation. Step S701: Determine whether a cloud platform instance is selected when orchestrating an application package, if so, proceed to step S710, if not, proceed to the next step. Step S702: Analyze all capability definition elements used by the application definition in the application package, and obtain the cloud platform instances that support this application according to the capability boundary. Step S703: Based on the cloud platform instance, determine whether there is a cloud platform that can deploy this application, if so, proceed to step S710, if not, proceed to the next step. Step S704: Determine whether "Advanced" capability is selected to further deploy this application package, if so, proceed to the next step, if not, proceed to step S711. Step S705: Display all instances of the accessed cloud platform. Step S706: Identify an instance of a cloud platform on which to deploy this application package. Step S707: According to the capability boundary, calculate a set of capabilities that are missing for the target cloud platform to deploy this application, and determine whether there is a capability installation package corresponding to the missing capability set, if so, proceed to the next step, if not, proceed to step S711. Step S708: Deliver the corresponding capability installation package to the target cloud platform to perform capability installation, and judge whether the installation is successful, if so, proceed to the next step, if not, proceed to step S711. Step S709: execute an application instantiation action in the target cloud platform, and determine whether the instantiation is successful; if the instantiation is unsuccessful, suggest to proceed to step S711. Step S710: A list of cloud platforms supported by the application is presented to the user for selection. Step S711: Indicates that the application instantiation has failed.

[0125] It should be noted that the cloud platform management method in this embodiment belongs to the same inventive idea as the cloud platform management architecture in the above embodiment, and therefore the specific embodiment of the cloud platform management method in this embodiment may refer to the specific embodiment of the cloud platform management architecture in the above embodiment, and has all the improvements of the cloud platform management architecture in the above embodiment, which will not be described here.

[0126] An embodiment of the present application also provides a cloud platform management device, which includes the cloud platform management architecture in the embodiment shown in FIG.

[0127] Here, the non-transitory software programs and instructions required to realize the cloud platform management method of the above embodiment are stored in a memory, and when executed by a processor, execute the cloud platform management method of the above embodiment, for example, method steps S100 to S300 of Figure 5, method step S310 of Figure 6, method step S400 of Figure 7, method step S410 of Figure 8, method step S210 of Figure 9, method steps S500 to S570 of Figure 10, method steps S600 to S610 of Figure 11, method steps S700 to S711 of Figure 12, or method step S420.

[0128] In addition, the cloud platform management device according to this embodiment can also be applied to the cloud platform management architecture of the embodiment shown in Fig. 1 and the cloud platform management architecture of the embodiment shown in Fig. 2. These embodiments all belong to the same inventive idea, and therefore have the same realization principles and technical effects, and will not be described in detail here.

[0129] The above device embodiment is merely an example, and the units described as separate components may or may not be physically separated, i.e., they may be located in one place or distributed among multiple network units. Some or all of these modules may be selected to achieve the purpose of the embodiment according to actual needs.

[0130] Further, an embodiment of the present application also provides a computer-readable storage medium, which stores computer-executable instructions, which, when executed by a processor or controller, such as the processor in the above-mentioned device embodiment, can cause the processor to execute the cloud platform management method in the above-mentioned embodiment, such as method steps S100 to S300 in FIG. 5, method step S310 in FIG. 6, method step S400 in FIG. 7, method step S410 in FIG. 8, step S210 in FIG. 9, method steps S500 to S570 in FIG. 10, method steps S600 to S610 in FIG. 11, method steps S700 to S711 in FIG. 12, or method step S420 in FIG.

[0131] An embodiment of the present application includes a cloud platform management architecture. The cloud platform management architecture includes: a first management device configured to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load; a second management device connected to the first management device and configured to determine a capability boundary corresponding to the application capability according to the application capabilities from the first management device, the capability boundary being for representing each candidate cloud platform supporting the application capability; and an application orchestration and instantiation device connected to the first management device and configured to determine an application orchestration and instantiation policy for each candidate cloud platform according to the capability boundary. According to the embodiment of the present application, in a specific scenario of the open application model, a plurality of application capabilities are defined by the first management device, so that capability abstraction of cloud native applications can be realized. Thereby, the differentiation scenarios of each cloud platform can be consistently represented, and the portability of cloud native applications between each cloud platform can be improved. In addition, the second management device determines a capability boundary for representing candidate cloud platforms that support the defined application capabilities, and the application orchestration and instantiation device assists in determining an application orchestration and instantiation policy for each candidate cloud platform according to the capability boundary, thereby achieving the effect of managing differentiation scenarios of multiple cloud platforms and optimizing application orchestration and instantiation.

[0132] All or a portion of the steps in the methods and systems disclosed above may be implemented as software, firmware, hardware, and appropriate combinations thereof. Some or all of the physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit. Such software may be distributed on a computer readable medium, which may include computer storage media (or non-transitory media) and communication media (or transitory media). Computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (e.g., computer readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cartridge, magnetic tape, magnetic disk storage or other magnetic storage device, or any other medium that can be used to store the desired information and that can be accessed by a computer. Additionally, communication media typically includes computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transmission mechanism and may include any information delivery media.

[0133] The above is a specific description of some embodiments of the present application, but the present application is not limited to the above embodiments, and a person skilled in the art may make various equivalent modifications or substitutions without departing from the spirit of the present application, and these equivalent modifications or substitutions are intended to be included within the scope limited by the claims of the present application.

Claims

1. a first management device configured to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by a cloud platform or an operation and maintenance characteristic acting on the load; a second management device connected to the first management device and configured to determine, according to the application capabilities from the first management device, a capability boundary corresponding to the application capabilities, the capability boundary being for representing each candidate cloud platform supporting the application capabilities; an application orchestration and instantiation device connected to the first management device and configured to determine an application orchestration and instantiation policy for each of the candidate cloud platforms according to the capability boundary.

2. 2. The cloud platform management architecture of claim 1, wherein the application orchestration instantiation unit is configured to determine, from each of the candidate cloud platforms according to the capability boundary, a target cloud platform for performing application orchestration instantiation.

3. The cloud platform management architecture of claim 2 , wherein the first management device is further configured to determine, according to the target cloud platform and the application capabilities, target application capabilities supported by the target cloud platform.

4. The cloud platform management architecture of claim 3 , wherein the first management device is further configured to send a target capabilities definition packet corresponding to the target application capabilities to the target cloud platform.

5. The cloud platform management architecture of any one of claims 1 to 4, wherein the second management device is configured to check the operation status of the application capability from the first management device, adjust the application capability according to the operation status of the application capability, and determine the capability boundary corresponding to the adjusted application capability according to the adjusted application capability.

6. 2. The cloud platform management architecture of claim 1, further comprising a capability database that stores at least one capability template corresponding to at least one of the application capabilities, the capability database being connected to the application orchestration and instantiation device via the first management device.

7. 7. The cloud platform management architecture of claim 6, wherein the application orchestration and instantiation unit is further configured to generate, based on the open application model, a programmable application capability orchestration element corresponding to the capability template.

8. A cloud platform management method applied to a cloud platform management architecture, the cloud platform management architecture including: a first management device; and a second management device connected to the first management device; The cloud platform management method includes: Controlling the first management device to define at least one application capability based on an open application model, each of the application capabilities being for representing a load supported by one cloud platform or an operation and maintenance characteristic acting on the load; Controlling the second management device to determine a capability boundary corresponding to the application capability according to the application capability from the first management device, the capability boundary being for representing each candidate cloud platform supporting the application capability; determining an application orchestration instantiation policy for each of the candidate cloud platforms according to the capacity boundary.

9. determining an application orchestration instantiation policy for each of the candidate cloud platforms according to the capability boundaries, The cloud platform management method of claim 8 , comprising determining a target cloud platform for performing application orchestration instantiation from each of the candidate cloud platforms according to the capability boundary.

10. After the step of determining an application orchestration instantiation policy for each of the candidate cloud platforms according to the capability boundaries, 10. The cloud platform management method of claim 9, further comprising: controlling the first management device to determine, according to the target cloud platform and the application capabilities, target application capabilities supported by the target cloud platform.

11. After the step of controlling the first management device to determine target application capabilities supported by the target cloud platform according to the target cloud platform and the application capabilities, The cloud platform management method of claim 10 , further comprising: controlling the first management device to send a target capability definition packet corresponding to the target application capability to the target cloud platform.

12. The step of controlling the second management device such that the second management device determines a capability boundary corresponding to the application capability according to the application capability from the first management device, 9. The cloud platform management method of claim 8, further comprising controlling the second management device to check an operation status of the application capability from the first management device, the second management device adjusting the application capability according to the operation status of the application capability, and the second management device determining, according to the adjusted application capability, the capability boundary corresponding to the adjusted application capability.

13. The cloud platform management architecture further includes a capability database configured to store at least one capability template corresponding to at least one of the application capabilities, the capability database being connected to an application orchestration and instantiation device via the first management device; The cloud platform management method includes:

9. The cloud platform management method of claim 8, further comprising: controlling the application orchestration and instantiation device to generate, based on the open application model, a programmable application capability orchestration element corresponding to the capability template.

14. A cloud platform management device comprising: a memory; a processor; and a computer program stored in the memory and operable by the processor, the processor implementing the cloud platform management method according to any one of claims 8 to 13 when it executes the computer program.

15. A computer-readable storage medium storing computer-executable instructions for implementing the cloud platform management method according to any one of claims 8 to 13, when executed by a processor.

Images