Node and methods performed thereby, for handling an application programming interface

Abstract

A computer-implemented method performed by a node (111). The method is for handling an application programming interface (API). The node (111) operates in a computer system (100). The node (111) determines (206), whether or not one or more capabilities of the a version of the API of a cloud orchestration platform (112) running in the computer system 5 (100) are a) new, with respect to one or more first capabilities of a first version of the API, and b) compatible with the first version of the API in a second version of the cloud orchestration platform (112) used to run the first version of the API. The version of the API is a newer version. The node (111) also initiates (207) implementing an update from the first version to the newer version with the proviso the one or more capabilities of the newer version, based on 10 the second version are compatible.

Description

[0001] NODE AND METHODS PERFORMED THEREBY, FOR HANDLING AN APPLICATION

[0002] PROGRAMMING INTERFACE

[0003] TECHNICAL FIELD

[0004] The present disclosure relates generally to a node and methods performed thereby for handling an application programming interface. The present disclosure also relates generally to a computer program and a computer-readable storage medium, having stored thereon the computer program to carry out this method.

[0005] BACKGROUND

[0006] Computer systems in a communications network or communications system may comprise one or more nodes. A node may comprise one or more processing circuitries or processors which, together with computer program code, may perform different functions and actions, a memory, a receiving port, and a sending port. A node may be, for example, a server. Nodes may perform their functions entirely on the cloud.

[0007] Computer systems may be comprised in a telecommunications network. The telecommunications network may cover a geographical area which may be divided into cell areas, each cell area being served by a type of node, a network node in the Radio Access Network (RAN), radio network node or Transmission Point (TP), for example, an access node such as a Base Station (BS), e.g., a Radio Base Station (RBS), which sometimes may be referred to as e.g., gNB, evolved Node B (“eNB”), “eNodeB”, “NodeB”, “B node”, or Base Transceiver Station (BTS), depending on the technology and terminology used. The base stations may be of different classes such as e.g., Wide Area Base Stations, Medium Range Base Stations, Local Area Base Stations and Home Base Stations, based on transmission power and thereby also cell size. A cell may be understood to be the geographical area where radio coverage may be provided by the base station at a base station site. One base station, situated on the base station site, may serve one or several cells. Further, each base station may support one or several communication technologies. The telecommunications network may also comprise network nodes which may serve receiving nodes, such as user equipments, with serving beams.

[0008] An Application Programming Interface (API) may be understood as a type of software interface that may enable communication between computer programs or computers. With the passage of time, APIs may deprecate. That is, its use may be discouraged or become obsolete. It may then be necessary to replace the deprecated APIs with new APIs. A service may be understood as an application that may have a variety of APIs for different functionalities. APIs may be organized in groups. Each API may be defined in a manifest file with API version and, e.g., API group.

[0009] Within the context of telecommunications, according to existing methods, the APIs provided by an underlying cloud orchestrator, such as e.g., Kubernetes (K8s) may be updated in the micro-services during the development time. Micro-services may be understood as independent services into which an application may be divided, which services may communicate via APIs. In existing methods, there may be utilities, such as, e.g., pluto or helm-mapkubeapis, that may enable to determine if an API is deprecated or removed in a specific version of a cloud orchestrating platform (COP). The current way to detect the deprecated APIs may be by integrating any such utilities in the Continuous Integration and Continuous Delivery (CI / CD) pipeline that may run against a specific version of a COP. The service owners may then get functional feedback on the functional correctness of the application when new APIs or capabilities may be incorporated. The service owners may get functional feedback before the application may be deployed on a target cluster, either through Flux or a similar agent which may build and deploy the service from periodic scanning of a GitOps repository.

[0010] Different aspects of handling APIs in cloud-based infrastructure have been dealt with in the literature, such as in CN113032097, US10225330, and CN111371679.

[0011] The existing technology for handing APIs in a cloud-based infrastructure may be time consuming and result in errors. As a consequence, services may not get installed properly or may not function as expected when incompatible APIs or incompatible capabilities in APIs may be used, which may not allow the services to start properly.

[0012] SUMMARY

[0013] As part of the development of embodiments herein, one or more problems with the existing technology will first be identified and discussed.

[0014] According to existing methods of API adaptiveness in services, the version of an API is determined from the version of the underlying platform used, e.g., in Kubernetes, and is adapted or incorporated in services. As a result, the applications may still use an older version of an API, unless this is detected manually. There is currently no utility, tool and / or mechanism in existing methods to determine if a service may be using the latest API version from the target COP on which it may be deployed.

[0015] Existing methods do not cover determining the API and autonomously updating deprecated APIs in a micro-service. The service owners may get feedback if an API is deprecated or removed in a COP version through existing utilities, as described earlier. That is, the service owners may get to see the functional correctness of the services after incorporating the APIs and the API capabilities. However, if APIs are not deprecated, the information of the latest and greatest API versions are not available through existing plugins. This makes it difficult for service owners to get proactive feedback well ahead of a COP version update. Accordingly, detecting the versions of APIs and updating to the latest API versions, if any, in micro-services is still a problem in e.g., a Business Support System (BSS) and may be a problem in all core cloud platforms.

[0016] As an illustrative example, a particular micro-service “A”, as part of a service chart, may have an API version update, e.g., from vi betai to stable version v1 in a cloud orchestration platform “X”, that may be greater than 1 .21 . All services may have to be scanned manually to know if micro-service A existed and a manual update to v1 version may need to be performed in those services that had micro-service A, and the services may then need to be redeployed. This takes a significant amount of time on design effort to get the e2e triggers and changes completed in all services.

[0017] In addition, there is currently no plugin to determine the latest API versions and to identify the changed and / or new capabilities of the API and the updates on services, if any. It may be understood that whenever an API version may be updated to a new version, not all capabilities may be updated. Conversely, some capabilities of an API may be updated, without creating a new version of the API. There is no mechanism to autonomously update the new API capabilities, which may be available in a latest version, in the service resource definitions. The new capabilities introduced in the latest version of the API are not updated in services until a COP version update is planned. Manual update of APIs, locally rendering manifest files and displaying the output of templates, e.g., helm templating, may be error prone and is tedious. Furthermore, service owners lose the advantages of the new capabilities that may be present in the latest API versions in the respective service definitions.

[0018] It is therefore an object of embodiments herein to improve the handling of an application programming interface (API).

[0019] According to a first aspect of embodiments herein, the object is achieved by a computer- implemented method, performed by a node. The method is for handling an API. The node operates in a computer system. The node determines whether or not one or more capabilities of a version of the API of a cloud orchestration platform, the cloud orchestration platform running in the computer system, are a) new, with respect to one or more first capabilities of a first version of the API of the cloud orchestration platform running in the computer system, and b) compatible with the first version of the API in a second version of the cloud orchestration platform used to run the first version of the API. The version of the API is a newer version than the first version of the API. The node then initiates implementing an update from the first version of the API to the newer version of the API with the proviso the one or more capabilities of the newer version of the API, based on the second version of the cloud orchestration platform, are compatible.

[0020] According to a third aspect of embodiments herein, the object is achieved by the node. The node may be understood to be for handling the API. The node is configured to operate in the computer system. The node is further configured to determine whether or not the one or more capabilities of the version of the API of the cloud orchestration platform, the cloud orchestration platform being configured to run in the computer system, are a) new, with respect to the one or more first capabilities of the first version of the API of the cloud orchestration platform being configured to run in the computer system, and b) compatible with the first version of the API in the second version of the cloud orchestration platform configured to be used to run the first version of the API. The version of the API is configured to be a newer version than the first version of the API. The node is also configured to initiate implementing the update from the first version of the API to the newer version of the API with the proviso the one or more capabilities of the newer version of the API, based on the second version of the cloud orchestration platform, are compatible.

[0021] According to a third aspect of embodiments herein, the object is achieved by a computer program, comprising instructions which, when executed on at least one processing circuitry, cause the at least one processing circuitry to carry out the method performed by the node.

[0022] According to a fourth aspect of embodiments herein, the object is achieved by a computer-readable storage medium, having stored thereon the computer program, comprising instructions which, when executed on at least one processing circuitry, cause the at least one processing circuitry to carry out the method performed by the node.

[0023] Embodiments herein may be understood to address the problem of manual updates, in terms of identifying and filtering the latest API versions and the API capabilities, and updating the latest APIs autonomously in the services that may be provided by the underlying cloud orchestration platform.

[0024] By determining whether or not the one or more capabilities of the version of the API are new and compatible with the first version of the API in the second version of the cloud orchestration platform, the node may be enabled to initiate an update of the first one or more capabilities to the one or more newer capabilities. If they are not compatible, the node may be enabled to refrain from initiating the update and hence enable that compatibility errors that may surface may be avoided.

[0025] By initiating implementing the update, the node may enable that, based on the underlying, second, version of the cloud orchestration platform, the first API version and the one or more first capabilities of the API may be updated dynamically in the services. Considering the limitations in the existing methods of manually checking and adapting the latest APIs in a service, embodiments herein provide an approach to consume updated APIs from the underlying cloud orchestration platform.

[0026] BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Examples of embodiments herein are described in more detail with reference to the accompanying drawings, according to the following description.

[0028] Figure 1 is a schematic diagram illustrating two non-limiting examples of a computer system, according to embodiments herein.

[0029] Figure 2 is a flowchart depicting a method in a node, according to embodiments herein.

[0030] Figure 3 is a schematic diagram depicting particular aspects of a non-limiting example of the method performed by the node, according to embodiments herein.

[0031] Figure 4 is a schematic block diagram illustrating an embodiment of a node, according to embodiments herein.

[0032] DETAILED DESCRIPTION

[0033] Certain aspects of the present disclosure and their embodiments address the challenges identified in the Background and Summary sections with the existing methods and provide solutions to the challenges discussed.

[0034] Embodiments herein may be understood to relate to forward detection of API versions and API capabilities supported in an underlying cloud orchestration platform, and adaptation to the latest versions and capabilities supported.

[0035] Embodiments herein may be understood to enable a new utility which may identify and detect the latest API versions that may be available in the underlying COP. The utility may make use of an API compatibility matrix which may have the new capabilities, latest API version and API group supported in the underlying orchestrator version.

[0036] Whenever newer versions or capabilities may be available and supported in the underlying version of the cloud orchestration platform, they may be autonomously updated. Once the new capabilities from the latest API versions, identified from the API matrix, may be autonomously updated in the service resource definitions, the service pipeline may be triggered and give feedback on the functional verification, that is, on the verification that the application may be behaving functionally in a correct manner as intended.

[0037] A report on the changes performed to the resource definitions and the new capabilities added, may be provided as feedback, and notified to the service owners. A micro-service may be understood as a collection of multiple resources to achieve a functionality. It may be understood that a micro-service may have many resources definitions, e.g., specifications. Each resource may be understood as a smallest functional unit which may correspond to an API. All the specifications may be compiled in a manifest file. Every cloud orchestration platform may have a respective manifest file.

[0038] The feedback as an API acknowledgement back to the services may help the services from a consumer perspective to understand the latest APIs and the new features which may work fine in the version of the cloud orchestration platform.

[0039] Some of the embodiments contemplated will now be described more fully hereinafter with reference to the accompanying drawings, in which examples are shown. In this section, the embodiments herein will be illustrated in more detail by a number of exemplary embodiments. Other embodiments, however, are contained within the scope of the subject matter disclosed herein. The disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art. It should be noted that the exemplary embodiments herein are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments.

[0040] Several embodiments and examples are comprised herein. It should be noted that the embodiments and / or examples herein are not mutually exclusive. Components from one embodiment or example may be tacitly assumed to be present in another embodiment or example and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments and / or examples.

[0041] Figure 1 depicts two non-limiting examples, in panels “a” and “b”, respectively, of a computer system 100, in which embodiments herein may be implemented. In some example implementations, such as that depicted in the non-limiting examples of Figure 1 , the computer system 100 may be a computer network. In other example implementations, which are not depicted in Figure 1 , the computer system 100 may be implemented in a telecommunications system, sometimes also referred to as a cellular radio system, cellular network or wireless communications system. In some examples, the telecommunications system may comprise network nodes which may serve receiving nodes, such as wireless devices, with serving beams.

[0042] In some examples, the telecommunications system may for example be a network such as 5G system, or Next Gen network. The telecommunications system may also, or alternatively, support other technologies, such as an LTE network, e.g. LTE Frequency Division Duplex (FDD), LTE Time Division Duplex (TDD), LTE Half-Duplex Frequency Division Duplex (HD-FDD), and LTE operating in an unlicensed band. The telecommunications system may also support other technologies, such as Wideband Code Division Multiple Access (WCDMA), Universal Terrestrial Radio Access (UTRA) TDD, GSM / Enhanced Data Rate for GSM Evolution (EDGE) Radio Access Network (GERAN) network, Ultra-Mobile Broadband (UMB), EDGE network, network comprising of any combination of Radio Access Technologies (RATs) such as e.g. Multi-Standard Radio (MSR) base stations, multi-RAT base stations etc., any 3rd Generation Partnership Project (3GPP) cellular network, Wireless Local Area Network / s (WLAN) or WiFi network / s, Worldwide Interoperability for Microwave Access (WiMax), IEEE 802.15.4-based low-power short-range networks such as IPv6 over Low-Power Wireless Personal Area Networks (6LowPAN), Zigbee, Z-Wave, Bluetooth Low Energy (BLE), or any cellular network or system.

[0043] The computer system 100 may comprise nodes, whereof a node 111 is depicted in Figure 1 . The computer system 100 may comprise additional nodes.

[0044] The computer system 100 also comprises a cloud orchestration platform 112.

[0045] The cloud orchestration platform 112 may support an Application Programming Interface (API) 113.

[0046] Any of the node 111 and the cloud orchestration platform 112 may be understood, respectively, as a first computer system or server, and a second computer system or server. Any of the node 111 and the cloud orchestration platform 112 may be implemented as a standalone server in e.g., a host computer in the cloud 120, as depicted in the non-limiting example of Figure 1b). In other examples, any of the node 111 and the cloud orchestration platform 112 may be a distributed node or distributed server, such as a virtual node in the cloud 120, and may perform some of its respective functions locally, e.g., by a client manager, and some of its functions in the cloud 120, by e.g., a server manager. In other examples, any of the node 111 and the cloud orchestration platform 112 may perform its functions entirely on the cloud 120, or partially, in collaboration or collocated with a radio network node. Yet in other examples, any of the node 111 and the cloud orchestration platform 112 may also be implemented as processing resources in a server farm. Any of the node 111 and the cloud orchestration platform 112 may be under the ownership or control of a service provider or may be operated by the service provider or on behalf of the service provider.

[0047] The node 111 may be understood as a network node, e.g., a core network node, having a capability to manage one or more components comprised in the cloud orchestration platform 112.

[0048] The cloud orchestration platform 112 may comprise one or more hardware components having a capability to run on one or more core network nodes. The cloud orchestration platform 112 may be, for example, Ericsson’s Cloud Container Distribution (CCD).

[0049] The telecommunications system may cover a geographical area, which in some embodiments may be divided into cell areas, wherein each cell area may be served by a radio network node, although, one radio network node may serve one or several cells. A radio network node may be a transmission point such as a radio base station, for example a gNB, an eNB, or any other network node with similar features capable of serving a wireless device, such as a user equipment or a machine type communication device, in the computer system 100. In typical examples, the radio network node may be a base station, such as a gNB or an eNB. In other examples, the radio network node may be a distributed node, such as a virtual node in the cloud 120, and may perform its functions entirely on the cloud 120, or partially, in collaboration with a radio network node. The network node may be of different classes, such as, e.g., macro eNodeB, home eNodeB or pico base station, based on transmission power and thereby also cell size. In the example of Figure 1 , the cells are not depicted to simplify the figure. In some examples, the network node may serve receiving nodes with serving beams.

[0050] Any of the node 111 , the cloud orchestration platform 112, and / or any of the nodes comprised in the computer system 100 may support one or several communication technologies, and its name may depend on the technology and terminology used. Any of the radio network nodes that may be comprised in the computer system 100 may be directly connected to one or more core networks.

[0051] A plurality of devices may be comprised in the telecommunication network. Any device comprised in the wireless computer system 100 may be a wireless communication device such as a 5G UE, or a UE, which may also be known as e.g., mobile terminal, wireless terminal and / or mobile station, a Customer Premises Equipment (CPE) a mobile telephone, cellular telephone, or laptop with wireless capability, just to mention some further examples. Any of the devices comprised in the telecommunications system may be, for example, portable, pocket-storable, hand-held, computer-comprised, or a vehicle-mounted mobile device, enabled to communicate voice and / or data, via the RAN, with another entity, such as a server, a laptop, a Personal Digital Assistant (PDA), or a tablet, Machine-to-Machine (M2M) device, device equipped with a wireless interface, such as a printer or a file storage device, modem, or any other radio network unit capable of communicating over a radio link in a communications system. Any device comprised in the telecommunications system may be enabled to communicate wirelessly in the telecommunications system. The communication may be performed e.g., via a RAN, and possibly the one or more core networks, which may be comprised within the wireless telecommunications system.

[0052] The node 111 may be configured to communicate within the computer system 100 with cloud orchestration platform 112 over a first link 130, e.g., a radio link, or a wired link.

[0053] The first link 130 may be a direct link or may be comprised of a plurality of individual links, wherein it may go via one or more computer systems or one or more core networks in the computer system 100, which are not depicted in Figure 1 , or it may go via an optional intermediate network. The intermediate network may be one of, or a combination of more than one of, a public, private or hosted network; the intermediate network, if any, may be a backbone network or the Internet; in particular, the intermediate network may comprise two or more sub-networks, which is not shown in Figure 1 .

[0054] In general, the usage of “first”, “second” and / or “third” herein may be understood to be an arbitrary way to denote different elements or entities, and may be understood to not confer a cumulative or chronological character to the nouns they modify.

[0055] Some of the embodiments contemplated herein will now be described more fully with reference to the accompanying drawings. Other embodiments, however, are contained within the scope of the subject matter disclosed herein, the disclosed subject matter should not be construed as limited to only the embodiments set forth herein; rather, these embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[0056] Embodiments of a computer-implemented method, performed by the node 1 11 , will now be described with reference to the flowchart depicted in Figure 2. The method is for handling the API 1 13. The node 11 1 operates in the computer system 100.

[0057] Several embodiments are comprised herein. In some embodiments all the actions may be performed. In some embodiments, some actions may be optional. In Figure 2, optional actions are indicated with dashed lines. It should be noted that the examples herein are not mutually exclusive. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description.

[0058] Some of the Actions may be performed in a different order than that represented in Figure 2. For example, Action 202 may be performed after Action 204 an Action 205.

[0059] Action 201

[0060] Embodiments herein may be understood to enable to check if an update may be possible of a version of the API 113 which may be currently used by the cloud orchestration platform 112 running in the computer system 100. This version of the API 1 13 may be referred to herein as the first version of the API 113.

[0061] In this Action 201 , the node 11 1 may obtain a version, referred to herein as a second version, of the cloud orchestration platform 1 12, used to run the first version of the API 113.

[0062] Obtaining may comprise, e.g., receiving, fetching, determining or similar and may be performed, e.g., via the first link 130.

[0063] The obtaining in this Action 201 of the second version may be performed by sending a first REST message, e.g., a first GET message to the cloud orchestration platform 112. The obtaining in this Action 201 of the second version may be performed, e.g., in response to an application being deployed and / or hosted on the cloud orchestration platform

[0064] 112 and / or periodically, etc.

[0065] By, in this Action 201 , obtaining the second version of the cloud orchestration platform 112, the node 111 may then be enabled to determine the first version of the API 113. The first node 111 may also be enabled to determine whether or not the second version of the cloud orchestration platform 112 may be the latest version that may be available or not, as well as which capabilities the second version of the cloud orchestration platform 112 may provide.

[0066] Action 202

[0067] In this Action 202, the node 111 may obtain the first version of the API 113 used by the cloud orchestration platform 112 running in the computer system 100.

[0068] Obtaining may comprise, e.g., receiving, fetching, determining or similar and may be performed, e.g., via the first link 130.

[0069] The obtaining in this Action 202 of the first version may be performed by sending a second REST message, e.g., a second GET message to the cloud orchestration platform 112.

[0070] The API 113 may be comprised in, and / or used by, a micro-service or service. The micro-service or service comprising the API 113 may be used as input in the obtaining in this Action 202.

[0071] The second version of the cloud orchestration platform 112 may also be used as input in the obtaining in this Action 202.

[0072] The obtaining in this Action 202 of the first version may be performed, e.g., in response to the application being deployed and / or hosted on the cloud orchestration platform 112 and / or periodically, etc.

[0073] By obtaining the first version of the API 113 in this Action 202, the node 111 may then be enabled to determine whether or not the first version of the API 113 may be the newest version that may be available or not, as well as which capabilities the first version of the API

[0074] 113 may provide. The node 111 may therefore enable avoiding manual scanning of the latest API versions and new APIs in the latest version of the cloud orchestration platform 112 on which services may be deployed.

[0075] Action 203

[0076] As explained earlier, a version may be associated with an update of one or more capabilities. A capability may be understood as a set of tasks or functions that may enable to achieve a certain functionality or required performance level or similar. A capability may be, for example, metrics based resource utilization in HPA. Not all capabilities may be updated at the same time. Hence, in any particular version, a single or several of the capabilities supported may be updated.

[0077] In this Action 203, the node 111 may obtain one or more first capabilities of the obtained first version of the API 113, and one or more second capabilities of the obtained second version of the cloud orchestration platform 112.

[0078] Obtaining may comprise, e.g., receiving, fetching, determining or similar and may be performed, e.g., via the first link 130.

[0079] The obtaining in this Action 203 of the first and second capabilities may be performed by sending a respective third REST message, e.g., a respective third GET message to the cloud orchestration platform 112.

[0080] The obtaining in this Action 203 of the one or more first and second capabilities may be performed in response to the application being deployed and / or hosted on the cloud orchestration platform 112, periodically, etc.

[0081] The obtaining in this Action 203 of the one or more first capabilities may use the first version of the API 113 as input.

[0082] The obtaining in this Action 203 of the one or more second capabilities may use the second version of the cloud orchestration platform 112 as input.

[0083] By determining the one or more first and second capabilities in this Action 203, the node 111 may then be enabled to determine whether newer versions of the first and second capabilities may be available or not, as well as their compatibility with the second version of the cloud orchestration platform 112 used to run the first version of the API 113.

[0084] Action 204

[0085] In this Action 204, the node 111 may determine, based on the one or more second capabilities, whether or not a newer version of the first version of the API 113 a) may be available, and b) may be compatible with the second version of the cloud orchestration platform 112. The newer version of the API 113 may be referred to herein as a “third version” or latest version. In examples wherein Action 202 may be performed after Action 204 and 205, as the non-limiting example that will be described in Figure 3, the first node 111 may determine, in this Action 204, based on the one or more second capabilities, which may be the latest version of the API 113 that a) may be available, and b) may be compatible with the second version of the cloud orchestration platform 112.

[0086] Determining may comprise, e.g., checking.

[0087] In some embodiments, the determining in this Action 204 of whether or not the newer version, of the first version of the API 113 may be available and compatible with the second version of the cloud orchestration platform 112 may be based on a matrix. That is, may be checked by using the matrix. The matrix may indicate compatibilities between respective capabilities and respective versions of the API 113 and the cloud orchestration platform 112.

[0088] The matrix may be an API compatibility matrix. The matrix, e.g., API compatibility matrix, may be used to map the latest API versions and API capabilities against the specific second version of the cloud orchestration platform 112.

[0089] API versions may be parsed, e.g., by a second node operating in the communications system 100, from service manifest definitions and may be updated in the matrix with the latest versions. The service manifest definitions may also be checked for the new capabilities introduced in the latest APIs and may be updated dynamically with the new capabilities. The changes may be auto pushed in a source code repository of a corresponding micro-service and once the changes may be merged, the pipeline may be triggered to check the service functionalities against the respective APIs.

[0090] A sample of the matrix, that is, of the API compatibility matrix, to map APIs, API versions and API capabilities is depicted in Table 1. In the example of the matrix of Table 1 , the API 113 is the API Horizontal Pod Auto scaler (HPA) of Kubernetes. The cloud orchestration platform 112 is the Cloud Container Distribution (CCD). The one or more third capabilities of the newer, or third, version of the API, that is, the latest API version, v2, are shown.

[0091] Table 1

[0092] The node 111 may use the matrix to check the latest API versions against the respective second version of the cloud orchestration platform 112. The new and latest API versions and the additional capabilities introduced in the new, third, version of the API, which is version 2 (v2) in the example of Table 1 , may be mapped in the matrix. The matrix may be used as input together with the underlying second version of the cloud orchestration platform 112 to perform this Action 204. The node 111 may then autonomously check the existing manifests in the micro micro-service.

[0093] By determining in this Action 204 whether or not a newer version of the first version of the API 113 may be available, and compatible with the second version of the cloud orchestration platform 112, the node 111 may then be enabled to initiate implementing an update from the first version of the API 113 to the newer version of the API 113, as will be described later.

[0094] Action 205

[0095] With the proviso the node 111 may determine in Action 204 that the newer version of the API 113 may be available and compatible with the second version of the cloud orchestration platform 112, in this Action 205, the node 111 may obtain the one or more third capabilities of the newer version of the API 113.

[0096] In examples wherein Action 202 may be performed after Action 204 and 205, as the non-limiting example that will be described in Figure 3, the first node 111 may, in this Action 205, with the proviso the node 111 may determine in Action 204 that the latest version of the API 113 may be available and compatible with the second version of the cloud orchestration platform 112, obtain the one or more third capabilities of the latest version of the API 113.

[0097] In some embodiments, the obtaining in this Action 205 of the one or more third capabilities may be based on the matrix. The matrix may indicate the compatibilities between respective capabilities and respective versions of the API 113 and the cloud orchestration platform 112.

[0098] By obtaining the one or more third capabilities of the newer version of the API 113 in this Action 205, the node 111 may then be enabled to determine if they may be compatible with the second version of the cloud orchestration platform 112. If they are compatible, the node 111 may then be enabled to initiate an update of the first one or more capabilities to the one or more third capabilities. If they are not compatible, the node 111 may be enabled to refrain from initiating the update and hence enable that compatibility errors that may surface may be avoided. The node 111 may therefore enable autonomously performing the adaptation of the API 113 only in the service consumers which may have the support for the API 113.

[0099] Action 206

[0100] In this Action 206, the node 111 determines whether or not one or more capabilities, that is, the one or more third capabilities, of a version of the API 113, that is, the newer version than the first version of the API 113, of the cloud orchestration platform 112, the cloud orchestration platform 112 running in the computer system 100, are a) new, with respect to the one or more first capabilities of the first version of the API 113 of the cloud orchestration platform 112 running in the computer system 100, and b) compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112 used to run the first version of the API 113.

[0101] Determining may be understood as calculating, deriving or equivalent.

[0102] In some embodiments, at least one of the determining in Action 204 of whether or not the newer version, that is the third version, of the first version of the API 113 may be available and compatible, the obtaining in Action 205 of the one or more third capabilities, and the determining in this Action 206 of whether or not the one or more third capabilities of the newer version may be compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112 may be based on the matrix. The matrix may indicate compatibilities between respective capabilities and respective versions of the API 113 and the cloud orchestration platform 112.

[0103] The matrix may be the API compatibility matrix.

[0104] By determining whether or not the one or more third capabilities of the third version of the API 113 are new and compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112 in this Action 206, the node 111 may then be enabled to initiate an update of the first one or more capabilities to the one or more third capabilities. Particularly, by determining whether or not the one or more third capabilities of the third version of the API 113 are compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112, the node 111 may be enabled to ensure backward compatibility of the API 113 when it may be included in the service. If they are not compatible, the node 111 may be enabled to refrain from initiating the update and hence enable that compatibility errors that may surface may be avoided.

[0105] Action 207

[0106] In this Action 207, the node 111 initiates implementing an update from the first version of the API 113 to the newer version of the API 113, with the proviso the one or more capabilities of the newer version of the API 113, that is, the one or more third capabilities, based on the second version of the cloud orchestration platform 112, are compatible.

[0107] Initiating may comprise starting or triggering itself, or facilitating or enabling that another node implements the update.

[0108] The node 111 may implement the update by updating the resource definition dynamically where a change may be detected.

[0109] In some embodiments, with the proviso the node 111 may determine the newer version of the API 113 may be available and compatible with the second version of the cloud orchestration platform 112, the initiating implementing the update, in Action 207, from the first version of the API 113 to the newer version of the API 113, may further comprise updating an API group corresponding to the newer version of the API 113.

[0110] By initiating implementing the update in this Action 207, the node 111 may enable that, based on the underlying, second, version of the cloud orchestration platform 112, the API version, API group and the one or more first capabilities of the API 113 may be updated dynamically in the services. Considering the limitations in the existing methods of manually checking and adapting the latest APIs in a service, embodiments herein provide an approach to consume updated APIs from the underlying cloud orchestration platform 112.

[0111] Particularly, the node 111 may enable an autonomous update of the latest version of the API 113 and latest API compatibilities in the applicable micro-services. Manual intervention in updating the APIs in the micro-services may therefore be avoided. Thereby, the first node 111 , by autonomously initiating updating to the latest API version, together with the new capabilities may enable that service owners obtain a proactive and functional feedback of the API 113 well ahead of a version update of the cloud orchestration platform 112. This may also help in ensuring that the service owners may get feedback with the new capabilities introduced in the latest API version which may be dynamically updated in the micro-services.

[0112] Enabling a service to get a feedback / acknowledgement as per the underlying second version of the cloud orchestration platform 112 may be understood to assist the service in reducing the manual intervention required for detecting if a latest API version is already available and to adapt the new capabilities of the API in a micro service based on the target version of the cloud orchestration platform 112.

[0113] Action 208

[0114] In this Action 208, the node 111 may obtain feedback information on a usage and the one or more capabilities of the updated newer version, that is, the one or more third capabilities.

[0115] The functional feedback of the new capabilities introduced in the latest version of the APIs may need to be verified against the specific second version of the cloud orchestration platform 112, in order to get an end-to-end (e2e) functional verification, that is, functional correctness, overview.

[0116] Micro-services may be verified with the latest API version and the capabilities, enabling to provide pro-active feedback and enabling to avoid having to wait until verification with the respective version of the cloud orchestration platform 112 in the target cluster.

[0117] By obtaining the feedback information on the usage and the one or more third capabilities of the updated newer version in this Action 208, the node 111 may then enable to provide feedback of the functional correctness of the applicable services after incorporating the APIs and API versions.

[0118] Action 209

[0119] In embodiments wherein the update may be implemented, in this Action 209, the node 111 may provide an indication of the updated newer version.

[0120] Providing in this Action 209 may be understood as sending or broadcasting, or providing, outputting or displaying, e.g., on an interface.

[0121] The indication may be a report of changes done to a micro-service based on the API 113. The indication may, for example, indicate a successful update to the third version of the API 113, e.g., in a micro-service.

[0122] The indication provided in this Action 209 may be based on the obtained feedback in Action 208.

[0123] By providing the indication on the updated newer version in this Action 209, the node 111 may then enable that other similar micro-services may update the respective APIs. The feedback provided may be understood to be helpful for other services to understand if the API update may be useful.

[0124] Figure 3 is a schematic diagram depicting a non-limiting example of the method performed by the node 111 , according to embodiments herein. Particularly, Figure 3 depicts hybrid blocks that may be involved in a chain of parsing events when an API may be adapted in a service. The method in this non-limiting example may start at 301 , by passing, or inputting, a deployed service instance, comprising the API 113, and the second version of the cloud operating platform 112. Next, the node 111 , according to Action 204 may fetch the latest version of the API 113 from the underlying cloud orchestration platform 112, based on the second version of the cloud orchestration platform 112, obtained based on Action 201 . Next, according to Action 205, the node 111 may fetch the one or more third capabilities of the API 113 for the latest version of the API 113. The node 111 may then, according to Action 202, look for API versions in the service manifest definitions of the matrix, to determine the first version of the API 113. The node 111 may then, according to Action 204, conclude that the first version of the API 113 existing in the cloud orchestration platform 112 is an older version. The node 111 may then, according to Action 206, determine whether the one or more third capabilities are new and compatible with the first version of the API 113. If compatibility is found, the node 111 may then, according to Action 207, update the first version of the API 113 to the newer version of the API 113, and the capabilities of the API 113 from the one or more first capabilities to the one or more third capabilities. Only if the compatibility is found and a newer version is found, may the update happen. The node 111 may then, according to Action 208, get service feedback for the update in the API capabilities and API version. Finally, according to Action 209, the node 111 may broadcast the feedback after successful adaptation of the API 113, e.g., to all applicable services for other similar micro-services to update the respective APIs.

[0125] Example

[0126] Embodiments herein will now be illustrated with a non-limiting particular example.

[0127] For illustration purpose, the API HPA of Kubernetes may be taken as a non-limiting example of the API 113. The HorizontalPodAutoscaler may be implemented as a Kubernetes API resource and a controller. The resource may determine the behavior of the controller. The horizontal pod autoscaling controller, running within the Kubernetes control plane, may periodically adjust the desired scale of its target, for example, a deployment, to match observed metrics such as average Central Processing Unit (CPU) utilization, average memory utilization, or any other custom metric that may be specified.

[0128] In the Kubernetes version 1.21 , autoscaling / v1 apiVersion has been used for HPA in the services as the first version of the API 113. From version 1 .23 of the cloud controlling orchestrator 112 Kubernetes, the new apiVersion autoscaling / v2 is available as the newer version of the API 113.

[0129] When the node 111 may perform Action 204 for a service using the one or more first capabilities of autoscaling / v1 against the cloud orchestration platform 112 running on 1.23, the availability of the newer version of the API 113, api version v2 for HPA, is detected. v2 may then be adapted in the service with the new one or more third capabilities. The service feedback obtained according to Action 208 after adapting the HPA and after verification may be broadcasted to all applicable services, according to Action 209.

[0130] For instance, if a Performance Management (PM) server is the micro-service which may need to update the HPA apiVersion, the new updates in the HPA API may be automatically updated in the PM server service, based on apiVersions of the underlying orchestrator, according to embodiments herein.

[0131] The APIs comprised in the microservice may be obtained from the apiServer by passing the underlying cloud orchestration platform 112.

[0132] The following pseudocode may be used as a non-limiting example of how the first node

[0133] 111 may get the API versions corresponding to the underlying cloud orchestration platform

[0134] 112 CCD.

[0135] Function detect_apiVersion(micro_service_name, orchestrator_ccd_version) GET apiVersions from the API compatibility matrix in the orchestrator CACHE the apiVersions and the resource kind

[0136] FOR each resource yaml definition in the micro_service 202 PARSE apiVersion from the resource definition

[0137] PARSE the K ind of the resource

[0138] 204 Check the apiVersion if the same version is used for API from compatibility matrix

[0139] IF same version

[0140] Then ignore

[0141] ELSE IF apiVersion is different

[0142] IF no alpha or beta version in apiVersion

[0143] Then check the last digit of the resource with cached entry for resource Kind

[0144] Use the latest version

[0145] ELSE

[0146] IF alpha version used in resource

[0147] Then check if beta version or stable version available

[0148] Use stable version if available, otherwise use beta version

[0149] ELSE IF beta version used in resource

[0150] Then check if stable version is available, use stable version

[0151] End

[0152] End

[0153] End

[0154] 207 Apply the version for the API in micro_service

[0155] 205 Check for new capability of the API from the compatibility matrix. 207 Apply new capabilities in the resource yaml definition scanned from micro_service End For

[0156] Auto commit the changes done to micro_service

[0157] 208,209 Produce report of changes done to micro_service based on the APIs

[0158] For instance, if classification of service is not required to be highly available, then the resource such as Horizontal Pod Auto Scaler (HPA) may not need be applied in the service. If the apiVersion update is only for HPA from the underlying orchestrator, it may be skipped in the service if the service does not need the API.

[0159] Once the apiVersion is updated in the service, the api Version successful update in the micro-service may be broadcasted in accordance with Action 209, for other similar microservices to update the respective APIs.

[0160] Certain embodiments herein may provide one or more of the following technical advantage(s). A first advantage may be understood to be that embodiments herein may enable detecting the latest API versions from the underlying cloud orchestrator platform 112. A second advantage may be understood to be that embodiments herein may enable forming an API compatibility matrix with the API version and new capabilities in the latest API. Yet a further advantage may be understood to be that embodiments herein may enable that, based on the underlying version of the cloud orchestration platform 112, the API version, API group and the capabilities may be updated dynamically in the services. No manual intervention may be required in updating the APIs in the micro-services. Micro-services may be verified with the latest API version and the capabilities, giving pro-active feedback. Hence, advantageously, embodiments herein may enable that it may no longer be necessary to wait until a verification with the respective version of a cloud orchestration platform in a target cluster.

[0161] Figure 4 depicts an example of the arrangement that the node 111 may comprise to perform the method described in Figure 2 and / or Figure 3. The node 111 may be understood to be for handling the API 113. The node 111 is configured to operate in the computer system 100.

[0162] Several embodiments are comprised herein. It should be noted that the examples herein are not mutually exclusive. One or more embodiments may be combined, where applicable. All possible combinations are not described to simplify the description. Components from one embodiment may be tacitly assumed to be present in another embodiment and it will be obvious to a person skilled in the art how those components may be used in the other exemplary embodiments. The detailed description of some of the following corresponds to the same references provided above, in relation to the actions described for the node 111 , and will thus not be repeated here. For example, the indication may be configured to be broadcasted to all applicable services.

[0163] The node 111 is configured to determine whether or not the one or more capabilities of the version of the API 113 of the cloud orchestration platform 112, the cloud orchestration platform 112 being configured to run in the computer system 100, are a) new, with respect to the one or more first capabilities of the first version of the API 113 of the cloud orchestration platform 112 being configured to run in the computer system 100, and b) compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112 configured to be used to run the first version of the API 113. The version of the API 113 is configured to be a newer version than the first version of the API 113.

[0164] The node 111 is also configured to initiate implementing the update from the first version of the API 113 to the newer version of the API 113 with the proviso the one or more capabilities of the newer version of the API 113, based on the second version of the cloud orchestration platform 112, are compatible. In some embodiments wherein the update may be configured to be implemented, the node 111 may be further configured to provide the indication of the newer version configured to be updated.

[0165] In some embodiments, the node 111 may be further configured to obtain the feedback information on the usage and the one or more capabilities of the updated newer version. In such embodiments, the indication provided may be configured to be based on the feedback configured to be obtained.

[0166] In some embodiments the one or more capabilities of the newer of the API 113 may be configured to be the one or more third capabilities, and the node 111 may be further configured to at least one of the next four options.

[0167] In some examples, the first node 111 may be further configured to obtain the first version of the API 113 configured to be used by the cloud orchestration platform 112 configured to be running in the computer system 100.

[0168] In some examples, the first node 111 may be further configured to obtain the second version of the cloud orchestration platform 112 configured to be used to run the first version of the API 113.

[0169] In some examples, the first node 111 may be further configured to obtain the one or more first capabilities of the first version of the API 113 configured to be obtained, and the one or more second capabilities of the second version of the cloud orchestration platform 112 configured to be obtained.

[0170] In some examples, the first node 111 may be further configured to determine, based on the one or more second capabilities, whether or not the newer version of the first version of the API 113 a) may be available, and b) may be compatible with the second version of the cloud orchestration platform 112.

[0171] In some embodiments, the node 111 may be further configured to, with the proviso the node 111 determines the newer version of the API 113 is available and compatible with the second version of the cloud orchestration platform 112, obtain the one or more third capabilities of the newer version of the API 113.

[0172] In some embodiments, at least one of the determining of whether or not the newer version of the first version of the API 113 may be available and compatible, the obtaining of the one or more third capabilities and the determining of whether or not the one or more third capabilities of the newer version may be compatible with the first version of the API 113 in the second version of the cloud orchestration platform 112 may be configured to be based on the matrix configured to indicate compatibilities between the respective capabilities and the respective versions of the API 113 and the cloud orchestration platform 112.

[0173] In some embodiments, the initiating implementing the update from the first version of the API 113 to the newer version of the API 113 may be further configured to comprise, with the proviso the node 111 may determine the newer version of the API 113 is available and compatible with the second version of the cloud orchestration platform 112, updating the API group corresponding to the newer version of the API 113.

[0174] The embodiments herein in the node 111 may be implemented through one or more processors, such as a processing circuitry 401 in the node 111 depicted in Figure 4, together with computer program code for performing the functions and actions of the embodiments herein. A processor, as used herein, may be understood to be a hardware component. The program code mentioned above may also be provided as a computer program product, for instance in the form of a data carrier carrying computer program code for performing the embodiments herein when being loaded into the node 111. One such carrier may be in the form of a CD ROM disc. It is however feasible with other data carriers such as a memory stick. The computer program code may furthermore be provided as pure program code on a server and downloaded to the node 111.

[0175] The node 111 may further comprise a memory 402 comprising one or more memory units. The memory 402 is arranged to be used to store obtained information, store data, configurations, schedulings, and applications etc. to perform the methods herein when being executed in the node 111.

[0176] In some embodiments, the node 111 may receive information from, e.g., the cloud orchestration platform 112, and / or another structure in the computer system 100, through a receiving port 403. In some embodiments, the receiving port 403 may be, for example, connected to one or more antennas in node 111. In other embodiments, the node 111 may receive information from another structure in the computer system 100 through the receiving port 403. Since the receiving port 403 may be in communication with the processing circuitry 401 , the receiving port 403 may then send the received information to the processing circuitry 401 . The receiving port 403 may also be configured to receive other information.

[0177] The processing circuitry 401 in the node 111 may be further configured to transmit or send information to e.g., the cloud orchestration platform 112, and / or another structure in the computer system 100, through a sending port 404, which may be in communication with the processing circuitry 401 , and the memory 402.

[0178] Those skilled in the art will also appreciate that the units comprised within the node 111 described above as being configured to perform different actions, may refer to a combination of analog and digital circuits, and / or one or more processors configured with software and / or firmware, e.g., stored in memory, that, when executed by the one or more processors such as the processing circuitry 401 , perform as described above. One or more of these processors, as well as the other digital hardware, may be included in a single Application-Specific Integrated Circuit (ASIC), or several processors and various digital hardware may be distributed among several separate components, whether individually packaged or assembled into a System-on-a-Chip (SoC).

[0179] Also, in some embodiments, the different units comprised within the node 111 described above as being configured to perform different actions described above may be implemented as one or more applications running on one or more processors such as the processing circuitry 401 .

[0180] Thus, the methods according to the embodiments described herein for the node 111 may be respectively implemented by means of a computer program 405 product, comprising instructions, i.e., software code portions, which, when executed on at least one processing circuitry 401 , cause the at least one processing circuitry 401 to carry out the actions described herein, as performed by the node 111. The computer program 405 product may be stored on a computer-readable storage medium 406. The computer-readable storage medium 406, having stored thereon the computer program 405, may comprise instructions which, when executed on at least one processing circuitry 401 , cause the at least one processing circuitry 401 to carry out the actions described herein, as performed by the node 111. In some embodiments, the computer-readable storage medium 406 may be a non-transitory computer- readable storage medium, such as a CD ROM disc, or a memory stick. In other embodiments, the computer program 405 product may be stored on a carrier containing the computer program 405 just described, wherein the carrier is one of an electronic signal, optical signal, radio signal, or the computer-readable storage medium 406, as described above.

[0181] The node 111 may comprise a communication interface configured to facilitate, or an interface unit to facilitate, communications between the node 111 and other nodes or devices, e.g., the cloud orchestration platform 112, and / or another structure in the computer system 100. The interface may, for example, include a transceiver configured to transmit and receive radio signals over an air interface in accordance with a suitable standard.

[0182] In other embodiments, the node 111 may comprise a radio circuitry 407, which may comprise e.g., the receiving port 403 and the sending port 404.

[0183] The radio circuitry 407 may be configured to set up and maintain at least a wireless connection with the cloud orchestration platform 112, and / or another structure in the computer system 100. Circuitry may be understood herein as a hardware component.

[0184] Hence, embodiments herein also relate to the node 111 operative to operate in the computer system 100. The node 111 may comprise the processing circuitry 401 and the memory 402, said memory 402 containing instructions executable by said processing circuitry 401 , whereby the node 111 is further operative to perform the actions described herein in relation to the node 111 , e.g., in Figure 2 and / or Figure 3. When using the word "comprise" or “comprising”, it shall be interpreted as non- limiting, i.e., meaning "consist at least of".

[0185] The embodiments herein are not limited to the above-described preferred embodiments. Various alternatives, modifications and equivalents may be used. Therefore, the above embodiments should not be taken as limiting the scope of the invention.

[0186] Generally, all terms used herein are to be interpreted according to their ordinary meaning in the relevant technical field, unless a different meaning is clearly given and / or is implied from the context in which it is used. All references to a / an / the element, apparatus, component, means, step, etc. are to be interpreted openly as referring to at least one instance of the element, apparatus, component, means, step, etc., unless explicitly stated otherwise. The steps of any methods disclosed herein do not have to be performed in the exact order disclosed, unless a step is explicitly described as following or preceding another step and / or where it is implicit that a step must follow or precede another step. Any feature of any of the embodiments disclosed herein may be applied to any other embodiment, wherever appropriate. Likewise, any advantage of any of the embodiments may apply to any other embodiments, and vice versa. Other objectives, features and advantages of the enclosed embodiments will be apparent from the following description.

[0187] As used herein, the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “and” term, may be understood to mean that only one of the list of alternatives may apply, more than one of the list of alternatives may apply or all of the list of alternatives may apply. This expression may be understood to be equivalent to the expression “at least one of:” followed by a list of alternatives separated by commas, and wherein the last alternative is preceded by the “or” term.

[0188] Any of the terms processor and circuitry may be understood herein as a hardware component.

[0189] As used herein, the expression “in some embodiments” has been used to indicate that the features of the embodiment described may be combined with any other embodiment or example disclosed herein.

[0190] As used herein, the expression “in some examples” has been used to indicate that the features of the example described may be combined with any other embodiment or example disclosed herein.

Claims

CLAIMS:1 . A computer-implemented method, performed by a node (111 ), the method being for handling an application programming interface, API, (113) the node (111) operating in a computer system (100), the method comprising:- determining (206) whether or not one or more capabilities of a version of the API(113) of a cloud orchestration platform (112), the cloud orchestration platform (112) running in the computer system (100), are a) new, with respect to one or more first capabilities of a first version of the API (113) of the cloud orchestration platform (112) running in the computer system (100), and b) compatible with the first version of the API (113) in a second version of the cloud orchestration platform(112) used to run the first version of the API (113), wherein the version of the API(113) is a newer version than the first version of the API (113), and- initiating (207) implementing an update from the first version of the API (113) to the newer version of the API (113) with the proviso the one or more capabilities of the newer version of the API (113), based on the second version of the cloud orchestration platform (112), are compatible.

2. The method according to claim 1 , wherein the update is implemented and wherein the method further comprises:- providing (209) an indication of the updated newer version.

3. The method according to claim 2, further comprising:- obtaining (208) feedback information on a usage and the one or more capabilities of the updated newer version, and wherein the indication provided is based on the obtained feedback.

4. The method according to any of claims 1-3, wherein the one or more capabilities of the newer of the API (113) are one or more third capabilities, and wherein the method further comprises at least one of:- obtaining (201) the second version of the cloud orchestration platform (112) used to run the first version of the API (113),- obtaining (202) the first version of the API (113) used by the cloud orchestration platform (112) running in the computer system (100),- obtaining (203) the one or more first capabilities of the obtained first version of the API (113), and one or more second capabilities of the obtained second version of the cloud orchestration platform (112),- determining (204), based on the one or more second capabilities, whether or not the newer version of the first version of the API (113) a) is available, and b) is compatible with the second version of the cloud orchestration platform (112).

5. The method according to claim 4, wherein with the proviso the node (111) determines the newer version of the API (113) is available and compatible with the second version of the cloud orchestration platform (112), the method further comprises:- obtaining (205) the one or more third capabilities of the newer version of the API (113).

6. The method according to any of claims 4-5, wherein at least one of the determining (204) of whether or not the newer version of the first version of the API (113) is available and compatible, the obtaining (205) of the one or more third capabilities and the determining (206) of whether or not the one or more third capabilities of the newer version are compatible with the first version of the API (113) in the second version of the cloud orchestration platform (112) is based on a matrix indicating compatibilities between respective capabilities and respective versions of the API (113) and the cloud orchestration platform (112).

7. A node (111), for handling an application programming interface, API, (113), the node (111 ) being configured to operate in a computer system (100), the node (111) being further configured to:- determine whether or not one or more capabilities of a version of the API (113) of a cloud orchestration platform (112), the cloud orchestration platform (112) being configured to run in the computer system (100), are a) new, with respect to one or more first capabilities of a first version of the API (113) of the cloud orchestration platform (112) being configured to run in the computer system (100), and b) compatible with the first version of the API (113) in a second version of the cloud orchestration platform (112) configured to be used to run the first version of the API (113), wherein the version of the API (113) is configured to be a newer version than the first version of the API (113), and- initiate implementing an update from the first version of the API (113) to the newer version of the API (113) with the proviso the one or more capabilities of the newerversion of the API (113), based on the second version of the cloud orchestration platform (112), are compatible.

8. The node (111) according to claim 7, wherein the update is configured to be implemented, and wherein the node (111) is further configured to:- provide an indication of the newer version configured to be updated.

9. The node (111) according to claim 8, being further configured to:- obtain feedback information on a usage and the one or more capabilities of the updated newer version, and wherein the indication provided is configured to be based on the feedback configured to be obtained.

10. The node (111) according to any of claims 7-9, wherein the one or more capabilities of the newer of the API (113) are configured to be one or more third capabilities, and wherein the node (111 ) is further configured to at least one of:- obtain the first version of the API (113) configured to be used by the cloud orchestration platform (112) configured to be running in the computer system (100),- obtain the second version of the cloud orchestration platform (112) configured to be used to run the first version of the API (113),- obtain the one or more first capabilities of the first version of the API (113) configured to be obtained, and one or more second capabilities of the second version of the cloud orchestration platform (112) configured to be obtained,- determine, based on the one or more second capabilities, whether or not the newer version of the first version of the API (113) a) is available, and b) is compatible with the second version of the cloud orchestration platform (112).11 . The node (111) according to claim 10, wherein the node (111) is further configured to, with the proviso the node (111) determines the newer version of the API (113) is available and compatible with the second version of the cloud orchestration platform (112):- obtain the one or more third capabilities of the newer version of the API (113).

12. The node (111) according to any of claims 10-11 , wherein at least one of the determining of whether or not the newer version of the first version of the API (113) is available and compatible, the obtaining of the one or more third capabilities and thedetermining of whether or not the one or more third capabilities of the newer version are compatible with the first version of the API (113) in the second version of the cloud orchestration platform (112) is configured to be based on a matrix configured to indicate compatibilities between respective capabilities and respective versions of the API (113) and the cloud orchestration platform (112).

13. A computer program (405), comprising instructions which, when executed on at least one processing circuitry (401), cause the at least one processing circuitry (401 ) to carry out the method according to any of claims 1-6.

14. A computer-readable storage medium (406), having stored thereon a computer program (405), comprising instructions which, when executed on at least one processing circuitry (401 ), cause the at least one processing circuitry (401) to carry out the method according to any of claims 1-6.

Images