Technical Field

The present disclosure relates to a method for managing provision of an application service, and to a method for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The methods are performed by an application node and by an infrastructure node respectively. The present disclosure also relates to an application node, an infrastructure node, and to a computer program product configured, when run on a computer, to carry out a method for managing provision and/or deployment of an application service.

Background

Cloud computing refers to the delivery of on-demand computing services, and is fundamental to the provision of a wide range of communication network and other services that underpin commercial, industrial, financial, scientific and other activity. An increasing amount of computing and information services are moving to the cloud every day, taking advantage of the flexibility and other advantages offered by the cloud computing model. At the core of this evolution in computing services is the edge cloud. Edge clouds are facilities that contain tens of thousands of components of compute servers, storage servers, cache servers, routers, Power Distribution Units (PDUs), Uninterruptible Power Sources (UPSs), and air-conditioning units, all with multiple possible configurations and tuning parameters, resulting in a highly complex environment that requires careful management. The strong integration between the components of an edge cloud, and the lack of a priori information about the behaviours, execution contexts, and interactions between these components, exacerbate the difficulties of performing effective management of an edge cloud facility.

Recent advances in artificial intelligence (Al), optimization, machine learning (ML), and data analytics allow for automation of certain procedures in the management of edge clouds, offering improvements in reliability of cloud operations. Operations including placement, service mapping, scaling, network design, and data organization can consequently be at least partially automated. In general, the goal of techniques supporting management automation is to satisfy the requirements of applications deployed on the cloud infrastructure, and to satisfy the expectations of users accessing the applications in terms of quality of service. In other words, automated management techniques seek to accommodate the different scenarios or usage behaviours that may be triggered at the user side and, for example, ensure sufficient resources are available at the cloud application side to host users’ requests. In this manner, the overall availability and reliability of edge cloud environments can be improved. Key to automated management of cloud and edge cloud services is some level of advance knowledge about the behaviours and execution contexts at the client and application levels. Accurate data regarding user behaviour, including for example which type of application service will be required when, enables effective decisions to be made that will ensure user expectations in terms of quality of delivered service can be met.

Cloud infrastructure providers generally collect data about the different executed usage scenarios of clients from thousands of distributed components, in order to inform future management decisions for the cloud infrastructure. However, in real-life scenarios, many unforeseen events may impact the data collection process in the cloud, extending the total execution time of data collection procedures. Consequently, management decisions may be based on out of date information, negatively impacting performance. Many techniques additionally rely to a greater or lesser extent on predicted usage information. For example, a placement algorithm could use predictions about workload distribution (i.e. , number of users on each application) for different virtual machines in order to find an optimal deployment of the workload over the existing resources (i.e., CPU, memory), in which requirements of Service Level Agreements (SLAs) are satisfied. Predicted usage data is inevitably based on assumptions that may be made about what is in reality a highly dynamic and rapidly evolving cloud environment. In real-life scenarios, many unexpected events can occur, in addition to baseline variations in service usage, which can have a significant impact on prediction accuracy. Automated operations, including for example scaling, network design, placement etc., which are based on such inaccurate predictions can negatively impact performance, for example resulting in uneven load distribution across the cloud platform, increased latency, etc.

Taleb et al. "User mobility-aware Virtual Network Function placement for Virtual 5G Network Infrastructure," 2015 IEEE International Conference on Communications (ICC), London, 2015, pp. 3879-3884, study the placement problem in a cloud infrastructure with reference to a communication network Virtual Network Function (VNF). The two principal design goals of the study are to minimize the path between users and their respective data gateways, and to optimise user session mobility. Different strategies are proposed based on mobility features and service usage behavioural patterns of mobile users. For User Equipment (UEs) displaying high mobility features but which are not highly active in terms of IP flow generation, the VNFs are placed at datacenters that are near their corresponding Radio Access Network (RAN) nodes. For UEs displaying high mobility features and generating many IP flows, the VNFs are instantiated at distant datacenters while seeking to minimize the cost of the communication paths to such datacenters.

Taleb et al. is an example of existing studies in which cloud providers use predicted behavioural information and probability distribution data to inform operational management decisions. For example, the behaviour-related information in Taleb et al. is proactively detected (via ML techniques). Such information may well be obtained in a non-timely manner, and also may be inaccurate. This data is then used to train ML models to analyse application usage at the side of the users, and inform cloud infrastructure management decisions. The deficiencies in the training and input data inevitably result in management decisions that are not optimal. Furthermore, the collected data cannot cover new scenarios that could be triggered by new users, nor can it accurately reflect evolving situations resulting from unexpected events.

Summary

It is an aim of the present disclosure to provide methods, an application node, and infrastructure node and a computer readable medium which at least partially address one or more of the challenges mentioned above. It is a further aim of the present disclosure to provide methods, an application node, and infrastructure node and a computer readable medium which cooperate to facilitate behaviour-based management of application deployment on a cloud infrastructure, exploiting information that may be available both at application provider layer and at infrastructure provider layer, and thus offering a full stack solution for behaviour-based management of a cloud infrastructure.

According to a first aspect of the present disclosure, there is provided a method for managing provision of an application service, wherein the service is deployed on a cloud infrastructure. The method, performed by an application node, comprises receiving, from a user device of a user of the service, information about an expected future use of the service by the user, and obtaining a probability parameter associated with at least one of the user or the service. The probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. The method further comprises assessing the obtained probability parameter against an action criterion and, if the obtained probability parameter fulfils the action criterion, performing at least one of sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user, or determining, based on the expected future use of the service by the user, an operational change in provision of the service to the user, and executing the determined change.

According to another aspect of the present disclosure, there is provided a method for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The method, performed by an infrastructure node, comprises receiving, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. The method further comprises mapping the expected future use of the service by a user to a behaviour-based requirement of the application, and initiating updating of the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met.

According to another aspect of the present disclosure, there is provided a computer program product comprising a computer readable medium, the computer readable medium having computer readable code embodied therein, the computer readable code being configured such that, on execution by a suitable computer or processor, the computer or processor is caused to perform a method according to any one or more of the aspects or examples of the present disclosure.

According to another aspect of the present disclosure, there is provided an application node for managing provision of an application service, wherein the service is deployed on a cloud infrastructure. The application node comprises processing circuitry configured to cause the application node to receive, from a user device of a user of the service, information about an expected future use of the service by the user, and to obtain a probability parameter associated with at least one of the user or the service. The probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. The processing circuitry is further configured to cause the application node to assess the obtained probability parameter against an action criterion, and if the obtained probability parameter fulfils the action criterion, perform at least one of sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user, or determining, based on the expected future use of the service by the user, an operational change in provision of the service to the user and executing the determined change.

According to another aspect of the present disclosure, there is provided an infrastructure node for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The infrastructure node comprises processing circuitry configured to cause the infrastructure node to receive, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. The processing circuitry is further configured to cause the infrastructure node to map the expected future use of the service by a user to a behaviour-based requirement of the application, and initiate updating of the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met.

According to another aspect of the present disclosure, there is provided an application node for managing provision of an application service, wherein the service is deployed on a cloud infrastructure. The application node comprises an Application Behaviour Aware Agent comprising a Behaviour Monitor and an Alert Generator. The Behaviour Monitor is for receiving, from a user device of a user of the service, information about an expected future use of the service by the user. The Alert Generator is for obtaining a probability parameter associated with at least one of the user or the service, wherein the probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. The application node further comprises an Application Agent for assessing the obtained probability parameter against an action criterion, and if the obtained probability parameter fulfils the action criterion, performing at least one of sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user, or determining, based on the expected future use of the service by the user, an operational change in provision of the service to the user and executing the determined change. According to another aspect of the present disclosure, there is provided an infrastructure node for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The infrastructure node comprises an Infrastructure Behaviour Aware Agent comprising a Behaviour Monitor and a Behaviour Interpreter. The Behaviour Monitor is for receiving, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. The Behaviour Interpreter is for mapping the expected future use of the service by a user to a behaviour-based requirement of the application, and for initiating updating of the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met.

Aspects of the present disclosure thus provide methods and nodes that facilitate a “behaviour aware” management of application service deployment on a cloud infrastructure, sharing information about expected future use of services between application provider and infrastructure provider layers. In this manner, effective operational decisions for the cloud infrastructure may be made dynamically, taking account of evolution in the cloud environment and of evolving use patterns and requirements amongst users of application services hosted on the cloud infrastructure.

Brief Description of the Drawings

For a better understanding of the present disclosure, and to show more clearly how it may be carried into effect, reference will now be made, by way of example, to the following drawings in which:

Figure 1 is a flow chart illustrating process steps in a method performed by an application node for managing provision of an application service;

Figure 2 is a flow chart illustrating process steps in a method performed by an infrastructure node for managing deployment of an application service;

Figures 3a to 3c show a flow chart illustrating process steps in another example of a method performed by an application node for managing provision of an application service; Figures 4a to 4c show a flow chart illustrating process steps in another example of a method performed by an infrastructure node for managing deployment of an application service;

Figure 5 is a block diagram illustrating functional modules in an application node;

Figure 6 is a block diagram illustrating functional modules in an infrastructure node;

Figure 7 is a block diagram illustrating functional modules in another example of an application node;

Figure 8 is a block diagram illustrating functional modules in another example of an infrastructure node;

Figure 9 illustrates an example architecture for implementing the methods and nodes of Figures 1 to 8;

Figure 10 illustrates an example application graph;

Figure 11 is a sequence diagram illustrating implementation of the methods of Figures 1 to 4c; and

Figure 12 illustrates an example use case for the methods of Figures 1 to 4c.

Detailed Description

As discussed above, examples of the present disclosure provide methods and nodes that cooperate to offer a full-stack, behaviour-aware architecture, enabling the sharing of behaviour related data between relevant entities, for example from users to application providers and infrastructure providers. In this manner, improved operational decisions, including decisions relating to placement, service mapping, scaling, etc., can be made on the fly, as events occur that may impact the cloud environment. In some examples, the present disclosure allows for the monitoring and analysis of data about behaviour, execution contexts and usage scenarios as provided from the user side, as well as the sharing of such data with application and cloud infrastructure providers. The proposed functionality is provided via the application node and infrastructure node introduced above.

The application node presented herein is located at the application provider layer, and is operable to monitor the behaviour of different application users, and changes in such behaviour over time. New user behaviours can be notified to the infrastructure provider layer, as well as being stored to inform future notification decisions. The infrastructure node presented herein is located at the infrastructure provider layer, and is operable to analyse behaviour-aware data that may be sent from different applications, which applications may be in different domains. The infrastructure node may aggregate such data, and map the data to application requirements which will satisfy the behavioural changes represented by the data. The infrastructure node then initiates updating of the operational deployment of relevant services and applications to reflect the application requirements, and may save the relevant data about application behaviour-aware changes and their associated application requirements, for use in future mapping of behavioural data to application requirements.

It will be appreciated that while the application node and infrastructure node are envisaged to cooperate, so as to offer optimal functionality for management of application service deployment over a cloud infrastructure, each of the nodes presented herein is operable to complement existing cloud systems, and may be deployed independently, without the presence of the other node. Application and cloud infrastructure vendors can therefore choose to deploy an application node or infrastructure node according to their own requirements, without the need to ensure that the corresponding node be present in the other layer. If present, the application node may offer a dedicated interface to application users, over which the users may provide the information about expected future use of application services, which information is then used by the application node.

Examples of the present disclosure thus exploit information that may be available in the application provider layer in order to facilitate improved management of application deployment at the cloud infrastructure layer. This is in contrast to existing cloud management systems, in which the process of data collection about user behaviours is typically performed at the infrastructure layer, and consequently lacks information about the actual users of applications. Owing to a current lack of cooperative communication through all the layers in a cloud system, important information about behavioural changes with respect to deployed applications, which information could be highly relevant to the management of the cloud infrastructure, is not shared with the infrastructure providers. For example, application providers have data about users experiencing high latency or service unavailability, and they currently use this data to adjust their application requirements for sending to the infrastructure layer. This impacts the application provider in terms of the number of operations or requests it has to handle, and may result in application providers changing resource planning and/or SLA levels. In addition, it can also negatively impact user experience. By facilitating the transmission of relevant user behavioural information to the infrastructure layer, and enabling the use of such information to inform operational management decisions in the infrastructure layer, examples of the present disclosure offer performance improvements and efficiency gains in both the cloud infrastructure and application provider layers.

For the purposes of the present disclosure, the term “User Behaviour data” encompasses data about execution contexts of one or more applications running at the user side, and consequently consists of data describing the existing or possible future scenarios or usage behaviours that could be triggered at the user side. For example, user behaviour data, or behavioural information, may include data about a user history, a user transaction, a geographic location, a user device, etc. Such data may include the answers to one or more of the questions: “Who” (user identification) did/does/will do “What” (executed application services and scenarios), “When” (service time) and “Where” (location of an executed service, or location of the user at the time a service is executed)?

For the purposes of the present disclosure, the term “Cloud Operations” encompasses the processes of managing and delivering cloud services and infrastructure in order to satisfy the services and expectations of cloud clients. This may involve optimization of performance and capacity, data management, service scaling, resource management, placement planning, recovery and mitigation management, etc.

Figure 1 is a flow chart illustrating process steps in a method 100 for managing provision of an application service, wherein the service is deployed on a cloud infrastructure. The method is performed by an application node, which may be implemented in any number of different ways, according to the constraints, priorities and any other factors impacting implementation decisions for a given deployment. For example, an application node may comprise a physical node such as a computing device, server etc., or may comprise a virtual node. A virtual node may comprise any logical entity, such as a Virtualised Network Function (VNF) which may itself be running in a cloud, edge cloud or fog deployment. The application node may therefore encompass multiple logical entities, as discussed in greater detail below with reference to Figures 7 and 9.

Referring to Figure 1 , the method 100 comprises, in a first step 110, receiving, from a user device of a user of the service, information about at least one expected future use of the service by the user. The information may be about a plurality of future uses of the service. The method then comprises, at step 120, obtaining a probability parameter associated with at least one of the user or the service, wherein the probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. In step 130, the method 100 comprises assessing the obtained probability parameter against an action criterion. If, in step 140, the obtained probability parameter is found to fulfil the action criterion, the method 100 comprises performing at least one of step 150, or step 160 and step 170. In step 150, the method 100 comprises sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user. For the purposes of the present disclosure, the phrase “operational deployment of the service on the cloud infrastructure” encompasses any aspect of how the service is deployed, including for example resource allocation, placement, scheduling, fault tolerance, etc. In step 160, the method 100 comprises determining, based on the expected future use of the service by the user, an operational change in provision of the service to the user, and in step 170 the method comprises executing the determined change.

Execution of the method 100 may involve performing either step 150, or steps 160 and 170, and may in some examples involve performing all of steps 150, 160 and 170. Steps 160 and 170 may be appropriate if an infrastructure node according to examples of the present disclosure is not present in the infrastructure layer of a particular deployment. In such circumstances, the application node may implement operational changes in provision of the relevant service at the application layer, and may in some examples interact with legacy components in the infrastructure provider layer. Step 150 (sending a message to an infrastructure node) may be appropriate if a particular deployment includes an infrastructure node according to example of the present disclosure in the infrastructure provider layer. Even if such a node is present, the application node may still execute steps 160 and 170 in addition to step 150, so both forwarding relevant information to the infrastructure layer, so that appropriate operational decisions may be taken in that layer, and making one or more operational changes in provision of the relevant service at the application provider layer and/or via interaction with legacy components in the infrastructure provider layer.

It will be appreciated that the method 100, in contrast to existing cloud infrastructure management processes, involves the receipt of expected user behaviour from a user of an application service, as opposed to predicting behaviour-based on historical trends. In addition, a probability parameter is used to control whether or not action is taken on the basis of the received information about expected future use. The probability parameter indicates a likelihood that a received expected future use of the service by the user will be executed. The probability parameter thus offers an evaluation of the confidence with which the received expected future use may be used to manage future operational requirements for the service, and may be viewed as a confidence rate to be applied to the received expected future use. As discussed in further detail below, the probability parameter may evolve with experience of particular users, groups of users and/or services, so as to accurately reflect the likelihood that received expended future use information is accurate.

The method 100 may be complemented by a method 200 for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure, as illustrated in Figure 2. The method 200 is performed by an infrastructure node, which, as for the application node discussed above, may be implemented in any number of different ways according to the constraints, priorities and any other factors impacting implementation decisions for a given deployment. For example, an infrastructure node may comprise a physical node such as a computing device, server etc., or may comprise a virtual node. A virtual node may comprise any logical entity, such as a Virtualised Network Function (VNF) which may itself be running in a cloud, edge cloud or fog deployment. The infrastructure node may therefore encompass multiple logical entities, as discussed in greater detail below with reference to Figures 8 and 9.

Referring to Figure 2, the method 200 comprises, in step 210, receiving, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. In step 220, the method 200 comprises mapping the expected future use of the service by a user to a behaviour-based requirement of the application. In step 230, the method 200 comprises initiating updating of the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met.

Examples of the method 200 thus act to map expected future use of a service to application requirements for the service, and initiate operational changes to meet those requirements. As for the method 100, it will be appreciated that the method 200 may be performed with or without the presence of an application node according to the present disclosure in the application provider layer. The requested change based on expected future use of service by a user could for example be based on information provided by an application node in accordance with the method 100. Alternatively, the requested change could be general data based on prediction for a plurality of users according to legacy techniques, in which case the application node from which the message is received may be any node in the application provider layer, such as for example an Application Agent in a legacy deployment, as discussed below with reference to Figure 9. For example, a legacy Application Agent could anticipate that it needs to service fewer users between 4am and 6am based on a prior art prediction method, or an application node according to the present disclosure could anticipate increased need at 10am based on data provided by users according to the method 100. The infrastructure node performing the method 200 is operable to map the information it receives to application requirements and initiate changes in operational deployment accordingly.

Figures 3a to 3c, and 4a to 4c, show flow charts illustrating process steps in further examples of methods 300 and 400 for managing provision and deployment of an application service, wherein the service is deployed on a cloud infrastructure.

Referring initially to Figures 3a to 3c, the method 300 provides various examples of how the steps of the method 100 may be implemented and supplemented to achieve the above discussed and additional functionality. As for the method 100, the method 300 is performed by an application node, which may be a physical or virtual node, and which may encompass multiple logical entities.

Referring to Figure 3a, in a first step 310, the application node receives, from a user device of a user of the service, information about an expected future use of the service by the user. As illustrated at 310a, receiving the information from a user device of a user of the service may comprise receiving the information about expected future use of the service by the user as an input from the user over an interface within the application. Such an interface may be provided within the application to support implementation of the method 300. In this manner, it will be appreciated that the information about expected future use may be provided by the user, as opposed to in an automated fashion by the device itself or one or more processes running on the device. For example, an automated script might provide, based on information available on the device, suggested future behaviour for the user to review, and which the user may choose to input or not via the interface provided within the application. Alternatively, the user may provide new expected behaviour information without input from the device. The user thus has ultimate control over what is input to this “behaviour interface”, making the information both more timely and more reliable than in legacy solutions based on prediction using historical data. The information about expected future use of the service by the user may include any one or more of an identification of the user, identification of the service, a time at which the service will be used and/or a location in which the user will be when using the service.

In step 320, the application node obtains a probability parameter associated with at least one of the user or the service, wherein the probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. It will be appreciated that information about expected future use of services by users may be found to demonstrate certain patterns of reliability, for example associated to particular applications, services, users, groups of users etc. Probability parameters may thus be associated with any one or more of a particular service, user, group of users, etc., and such probability parameters may be obtained in step 320. Additional steps which may be executed in order to obtain a probability parameter are illustrated in Figure 3c.

Referring to Figure 3c, in step 320a, the application node may check a user behaviour repository for a record corresponding to the received information about expected future use of the service by the user. Presence of a record corresponding to the expected future use would indicate that information about such expected future use has previously been received. If a record corresponding to the received information about expected future use of the service by the user is found to exist in the user behaviour repository in step 320b, the application node retrieves a value of the probability parameter that is stored in the user behaviour repository and is associated with at least one of the user or the service in step 320f. The application node may additionally increment the retrieved value in the user behaviour repository, allowing for example for distinguishing in the user behaviour repository between regular and occasional user behaviour patterns. It will be appreciated that regular behaviour patterns are also likely to be associated with a high value for the probability parameter, as regular behaviour patterns will offer frequent opportunity for checking of expected against actual behaviour, and consequent updating of the probability parameter value. This is discussed in greater detail below.

If a record corresponding to the received information about expected future use of the service by the user is not found in the user behaviour repository in step 320b, then the application node creates a record of the received information about expected future use of the service by the user in step 320c, and determines in step 320d that a value of the probability parameter does not yet exist. A value for this parameter may be added in a later method step, following monitoring of use of the service by the user, as discussed below.

As discussed above, different levels of granularity may exist for the probability parameter. For example, a probability parameter may be associated with a combination of specific user and specific service, or with a user, a service, a group of users, etc. It is therefore possible that although a value for the probability parameter will not exist for an expected future use that is notified for the first time by a user (and consequently for which a record did not exist in the user behaviour repository), a value of a related probability parameter may exist. For example, a value of the probability parameter may exist for other behaviour of the user, or a group to which the user belongs, or for that service as used by other users. In some examples, the application node may therefore follow a procedure for suggestion of a related probability parameter value in step 320e. Such a related probability parameter value may then be updated as discussed below following monitoring of actual user behaviour, to provide a more accurate indication of the likelihood of the particular expected future use of the service by the user being executed.

Referring again to Figure 3a, in step 330, the application node assesses the obtained probability parameter against an action criterion. The action criterion enables the application node to determine whether or not an action should be taken on the basis of the received information about expected future user of the service by the user. For example, if the probability parameter indicates that the likelihood of the expected future use being executed is relatively low, then it may not be appropriate to take action to accommodate that expected future use. Conversely, an expected future use that is associated with a very high likelihood of being executed may warrant action to accommodate that use in the manner in which the application service is deployed on the cloud infrastructure. The action criterion may therefore comprise a threshold against which the value of the probability parameter may be compared, as illustrated at 330a. In other examples, a more complex criterion may be used incorporating one or more additional rules for assessment of the probability parameter. In the absence of a value for the probability parameter, a rule-based procedure may be used to determine whether or not action should be taken on the basis of the received information about expected future use. In one example, an operational change may always, or never, be requested for a previously unseen behaviour. In other examples, operational changes may always be requested for information received from particular users (for example associated with high value subscriptions) or relating to particular services. Other rules, for example involving checking against similar behaviour for other users, checking against other behaviour for that user, etc., may be envisaged.

If the probability parameter fails to fulfil the action criterion (No at step 340), then the application node returns to step 310, awaiting receipt of a new information about expected future use without requesting any operational change. If the obtained probability parameter fulfils the action criterion (Yes at step 340), the application node may then aggregate, at step 345, the received information about an expected future use of the service by the user with at least one of: information about expected use of the service by other users, information about expected use of another service of the application by the user, and/or information about expected use of another service of the application by other users.

Such aggregation may enable sending in a single message of information relating to behaviour changes for many or all users of the relevant service or services in the application. Performing such aggregation after the assessment against the action criterion ensures that only expected future use that warrants operational change in order to accommodate it is forwarded to the infrastructure provider layer. A decision on whether or not to perform aggregation at step 345 may be based on a range of factors, including the particular service and user(s) concerned, operational priorities, deployment specific factors, etc. Referring now to Figure 3b, following aggregation, if aggregation is performed, the application node then performs at least one of step 350 and/or steps 360 and 370. In step 350, the application node sends a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the (aggregated) expected future use of the service (or services) by the user (or users). This may comprise sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user. As illustrated at step 350, the application node may include in the message at least a part of the received information about an expected future use of the service by the user. For example, the message may include location and time information, service identification, etc. The message may further include a description of the received information and/or further specifications generated from the received information. For example, if the information is aggregated across users, the information included in the message may be some or all of the aggregated information for multiple users. The requested change in the operational deployment of the service on the cloud infrastructure may comprise a change in any aspect of how the service is deployed on the cloud infrastructure, including for example resource allocation, placement, scheduling, fault tolerance, etc.

In step 360, the application node determines, based on the (aggregated) expected future use, an operational change in provision of the service to the user, and, in step 370, the application node executes the determined change. In some examples, the operational change in provision of the service to the user may comprise a change that may be executed independently of the cloud infrastructure. In other examples, the change may be implemented through interaction with one or more components in the infrastructure layer, which may for example comprise legacy components.

As discussed above with reference to the method 100, execution of the method 300 may involve performing either step 350, or steps 360 and 370, and may in some examples involve performing all of steps 350, 360 and 370. Steps 360 and 370 may be appropriate if an infrastructure node according to examples of the present disclosure is not present in the infrastructure layer of a particular deployment. In such circumstances, the application node may implement operational changes in provision of the relevant service at the application layer, and may in some examples interact with legacy components in the infrastructure provider layer. Step 350 (sending a message to an infrastructure node) may be appropriate if a particular deployment includes an infrastructure node according to examples of the present disclosure in the infrastructure provider layer. Even if such a node is present, the application node may still execute steps 360 and 370 in addition to step 350, both forwarding relevant information to the infrastructure layer, so that appropriate operational decisions may be taken in that layer, and making one or more operational changes in provision of the relevant service at the application layer and/or via interaction with legacy components in the infrastructure provider layer.

Referring still to Figure 3b, the application node monitors use of the service by the user in step 380. In step 390, the application node determines whether or not the expected future use of the service by the user was executed, and in step 395, the application node updates a value of a probability parameter associated with at least one of the user or the service based on the determination. This may comprise for example updating a percentage score of the number of times the expected use of the service by the user (including the location, time and service used) was executed. The updated value may be stored in the user behaviour repository. As discussed above, different granularities may exist for the probability parameter, including for example a probability parameter that is associated with a particular user and service and time combination, a probability parameter that is associated with a user only, with a group of users, with a service only, etc. According to examples of the present disclosure, if more than one probability parameter exists for the particular expected future use that was received in step 310 (for example a user probability parameter, a service probability parameter and a probability parameter for the particular combination of user and service), then values of one, some or all parameters may be updated based on execution or not of the expected use of the service by the user. In the case of an expected future use for which a probability parameter value did not previously exist, that is a new expected future use that had not previously been received by the application node, then a probability parameter may be created for that expected future use and stored with a record of the expected future use in the user behaviour repository.

Figures 4a to 4c show a flow chart illustrating process steps in a further example of method for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The method 400 may complement either of the methods 100 and/or 300, and is performed by an infrastructure node. The method 400 illustrates examples of how the steps of the method 200 may be implemented and supplemented to achieve the above discussed and additional functionality. As discussed above with reference to the method 200, the infrastructure node performing the method 400 may be a physical or virtual node, and may encompass multiple logical entities.

Referring first to Figure 4a, in a first step 410 of the method 400, the infrastructure node receives, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. As illustrated at 410a, step 410 may comprise receiving in the message information about an expected future use of the service by the user. The information about an expected future use of the service by the user may comprise any one or more of: aggregated information about expected use of the service by a plurality of users including the user, aggregated information about expected use of a plurality of services of the application by the user, and/or aggregated information about expected use of a plurality of services of the application by a plurality of users.

In some examples of the present disclosure, the information may have been directly provided by the user via an interface that may be provided in the application, discussed above with reference to the method 300. In further examples, the infrastructure node may receive information that has been aggregated across users of the application and/or application service. In other examples, the information about expected future use of the service by the user may be predicted information that is generated in the application provider layer. The application node from which the information is received may comprise an application node according to the present disclosure, or any node in the application provider layer, such as for example an Application Agent in a legacy deployment, as discussed below with reference to Figure 9.

In step 412, the infrastructure node checks whether a provider of the application service has authorised aggregation of information about expected future use with another service or application. Different application service providers may for example authorise aggregation of information relating to use of their application services with information about use of services accessed through applications provided by a different provider. Such aggregation may allow for more effective and efficient management of cloud infrastructure resources, thus benefitting all providers. However, some application providers may choose not to authorise such aggregation, for example owing to privacy or security concerns, or to ensure a particular level of service etc. If the check returns a negative result, indicating that the application provider does not authorise aggregation of information, then the infrastructure node proceeds directly to step 420.

If aggregation is authorised, then the infrastructure node may select suitable criteria for aggregation and then aggregate the expected future use of the service by a user with expected future use of another service or application in step 414. Suitable criteria for aggregation may include applications to be hosted at the same geographic location, applications with same users (if visible to the infrastructure provider), applications of the same type (i.e., memory-intensive, lO-intensive applications, delay-sensitive) and/or applications with the same device type of users.

In step 420, the infrastructure node maps the expected future use of the service by a user to a behaviour-based requirement of the application. Additional steps which may be executed in order to map the expected future use of the service to a behaviour-based requirement of the application are illustrated in Figure 4c.

Referring to Figure 4c, in step 420a, the infrastructure node checks for the expected future use of the service in a behaviour requirement repository. The behaviour requirement repository contains expected future use of services by users and associated behaviour-based application requirements. If, at step 420b, the expected future use of the service is present in the behaviour requirement repository, the infrastructure node selects a behaviour-based application requirement that is associated in the behaviour requirement repository with the expected future use of the service in step 420c. Owing to the dynamic nature of cloud environments, and changes that may occur in the cloud infrastructure and/or its management, it is possible that multiple behaviour-based requirements may be generated, for example at different times, for the same expected future use of a service. As illustrated at 420c, if a plurality of behaviour-based application requirements are associated in the behaviour requirement repository with the expected future use of the service, the infrastructure node may select a behaviour-based application requirement from among the plurality according to a success measure associated with the behaviour-based application requirements. This success measure may be a function of one or more Key Performance Indicators (KPIs), or other parameters relating to performance of the cloud infrastructure or the services deployed on the cloud infrastructure. The success measure is discussed in further detail below. If, at step 420b, the expected future use of the service is not present in the behaviour requirement repository, the infrastructure node uses a mapping function in step 420d to map the expected future use of the service to a behaviour-based requirement of the application. In step 420e, the infrastructure node stores the expected future use of the service, and the behaviour-based requirement of the application to which the expected future use of the service was mapped by the mapping function, in the behaviour requirement repository. A range of suitable mapping functions may be envisaged, including for example rule based procedures established on the basis of domain knowledge, and supervised Machine Learning (ML) models trained using historical records of expected future user behaviour, behaviour-based application requirements, and success measures. Reinforcement Learning processes, designed to maximise a measure of performance of the cloud infrastructure and/or performance of specific services deployed on the infrastructure, may also be envisaged, as well as other possibilities for a mapping function.

In some examples, the check at step 420a may verify not only the presence or absence of the expected future use of the service in a behaviour requirement repository, but may also check that at least one behaviour-based application requirement stored in connection with the expected future use is associated with a success measure that meets a criterion. The criterion may for example be a threshold, which may in some examples be specific to a particular circumstance, application provider etc. If none of the behaviour-based requirements stored in connection with the expected future use is associated with a success measure that meets the criterion, the infrastructure node may perform step 420d, using a mapping function to map to a new behaviour-based requirement. In this manner, a range of different behaviour-based requirements may be generated and stored in connection with the same expected future use of a service. The behaviour requirement repository thus offers a short cut to efficiently translate information about expected future use of services to application requirements based on such information. If previous behaviour-based requirements are available, and meet a criterion with respect to their success, then the infrastructure node can select an existing behaviour-based requirement, so saving time and computing resource. If however no previous behaviour-based requirement exists for a given expected future use, or if only behaviour-based requirements with low success measures that do not meet a criterion exist, then the infrastructure node can use a mapping function to generate a new behaviour-based requirement for execution. Referring now to Figure 4b, in step 430 the infrastructure node initiates updating of the operational deployment of the service on the cloud infrastructure such that the behaviourbased requirement of the application is met. As illustrated at 430a, this may comprise sending a message to an infrastructure operations node of the cloud infrastructure including the behaviour-based requirement of the application, and a request to update the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met. It will be appreciated that existing logical operations nodes within the infrastructure provider layer may be equipped to receive and execute such a request, making appropriate decisions regarding operational deployment of application services such that application requirements are met. The fact that the requirements provided to such an operations node according to the method 400 are behaviour-based requirements may be transparent to the operations node.

In step 440, the infrastructure node obtains a measure of success of the update to the operational deployment of the service on the cloud infrastructure that was initiated on the basis of the behaviour-based application requirement. This may comprise obtaining, at step 440a, a value of at least one performance parameter for the application, and calculating, at step 440b, a percentage improvement in the performance parameter as a consequence of the update to the operational deployment of the service on the cloud infrastructure that was initiated on the basis of the behaviour-based application requirement. Other measures of success of the update to the operational deployment may be envisaged.

In step 450, the infrastructure node associates the measure of success with the behaviour-based application requirement and the expected future use of the service in the behaviour requirement repository. This success measure may then be used by the infrastructure node in selecting future behaviour-based requirements for the same received information about expected future use of a service.

As discussed above, the methods 100 and 300 may be performed by an application node, and the present disclosure provides an application node that is adapted to perform any or all of the steps of the above discussed methods. The application node may comprise a physical node such as a computing device, server etc., or may comprise a virtual node. A virtual node may comprise any logical entity, such as a Virtualised Network Function (VNF) which may itself be running in a cloud, edge cloud or fog deployment.

Figure 5 is a block diagram illustrating an example application node 500 which may implement the method 100 and/or 300, as illustrated in Figures 1 and 3a to 3c, according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 550. Referring to Figure 5, the application node 500 comprises a processor or processing circuitry 502, and may comprise a memory 504 and interfaces 506. The processing circuitry 502 is operable to perform some or all of the steps of the method 100 and/or 300 as discussed above with reference to Figures 1 and 3a to 3c. The memory 504 may contain instructions executable by the processing circuitry 502 such that the application node 500 is operable to perform some or all of the steps of the method 100 and/or 300, as illustrated in Figures 1 and 3a to 3c. The instructions may also include instructions for executing one or more telecommunications and/or data communications protocols. The instructions may be stored in the form of the computer program 550. In some examples, the processor or processing circuitry 502 may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 502 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), etc. The memory 504 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive, etc.

As discussed above, the methods 200 and 400 may be performed by an infrastructure node, and the present disclosure provides an infrastructure node that is adapted to perform any or all of the steps of the above discussed methods. The infrastructure node may comprise a physical node such as a computing device, server etc., or may comprise a virtual node. A virtual node may comprise any logical entity, such as a Virtualised Network Function (VNF) which may itself be running in a cloud, edge cloud or fog deployment.

Figure 6 is a block diagram illustrating an example infrastructure node 600 which may implement the method 200 and/or 400, as illustrated in Figures 2 and 4a to 4c, according to examples of the present disclosure, for example on receipt of suitable instructions from a computer program 650. Referring to Figure 6, the infrastructure node 600 comprises a processor or processing circuitry 602, and may comprise a memory 604 and interfaces 606. The processing circuitry 602 is operable to perform some or all of the steps of the method 200 and/or 400 as discussed above with reference to Figures 2 and 4a to 4c. The memory 604 may contain instructions executable by the processing circuitry 602 such that the infrastructure node 600 is operable to perform some or all of the steps of the method 200 and/or 400, as illustrated in Figures 2 and 4a to 4c. The instructions may also include instructions for executing one or more telecommunications and/or data communications protocols. The instructions may be stored in the form of the computer program 650. In some examples, the processor or processing circuitry 602 may include one or more microprocessors or microcontrollers, as well as other digital hardware, which may include digital signal processors (DSPs), special-purpose digital logic, etc. The processor or processing circuitry 602 may be implemented by any type of integrated circuit, such as an Application Specific Integrated Circuit (ASIC), Field Programmable Gate Array (FPGA), etc. The memory 604 may include one or several types of memory suitable for the processor, such as read-only memory (ROM), randomaccess memory, cache memory, flash memory devices, optical storage devices, solid state disk, hard disk drive, etc.

Figure 7 illustrates functional modules in another example of application node 700 which may execute examples of the methods 100 and/or 300 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the modules illustrated in Figure 7 are functional modules, and may be realised in any appropriate combination of hardware and/or software. The modules may comprise one or more processors and may be integrated to any degree.

Referring to Figure 7, the application node 700 is for managing provision of an application service, wherein the service is deployed on a cloud infrastructure. The application node comprises an Application Behaviour Aware Agent (ABAA) 702, the ABAA 702 comprising a Behaviour Monitor 710 and an Alert Generator 712. The Behaviour Monitor 710 is for receiving, from a user device of a user of the service, information about an expected future use of the service by the user. The Alert Generator 712 is for obtaining a probability parameter associated with at least one of the user or the service, wherein the probability parameter indicates a likelihood that the received expected future use of the service by the user will be executed. The application node 700 further comprises an Application Agent 704 for assessing the obtained probability parameter against an action criterion and, if the obtained probability parameter fulfils the action criterion, performing at least one of (i) sending a message to an infrastructure node of the cloud infrastructure on which the service is deployed, the message requesting a change in the operational deployment of the service on the cloud infrastructure based on the expected future use of the service by the user, or (ii) determining, based on the expected future use of the service by the user, an operational change in provision of the service to the user that may be executed independently of the cloud infrastructure, and executing the determined change. The application node 700 may further comprise interfaces 706, which may be operable to facilitate communication with an infrastructure node, and/or with other communication network nodes, over suitable communication channels.

Figure 8 illustrates functional modules in another example of infrastructure node 800 which may execute examples of the methods 200 and/or 400 of the present disclosure, for example according to computer readable instructions received from a computer program. It will be understood that the modules illustrated in Figure 8 are functional modules, and may be realised in any appropriate combination of hardware and/or software. The modules may comprise one or more processors and may be integrated to any degree.

Referring to Figure 8, the infrastructure node 800 is for managing deployment of an application service, wherein the service is deployed on a cloud infrastructure. The infrastructure node comprises an Infrastructure Behaviour Aware Agent (I BAA) 802. The I BAA 802 comprises a Behaviour Monitor 806 and a Behaviour Interpreter 808. The Behaviour Monitor 806 is for receiving, from an application node, a message requesting a change in the operational deployment of the service on the cloud infrastructure based on an expected future use of the service by a user. The Behaviour Interpreter 808 is for mapping the expected future use of the service by a user to a behaviour-based requirement of the application, and for initiating updating of the operational deployment of the service on the cloud infrastructure such that the behaviour-based requirement of the application is met. The infrastructure node 800 may further comprise interfaces 804, which may be operable to facilitate communication with an application node, and/or with other communication network nodes, over suitable communication channels.

Figures 1 to 4c discussed above provide an overview of methods which may be performed according to different examples of the present disclosure. These methods may be performed by an application node and an infrastructure node, as illustrated in Figures 5 to 8. The methods facilitate a “behaviour aware” management of application service deployment on a cloud infrastructure, sharing information about expected future use of services between application provider and infrastructure provider layers. In this manner, effective operational decisions for the cloud infrastructure may be made dynamically, taking account of evolution in the cloud environment and of evolving use patterns and requirements amongst users of application services hosted on the cloud infrastructure. There now follows a detailed discussion of how different process steps illustrated in Figures 1 to 4c and discussed above may be implemented. The functionality and implementation detail described below is discussed with reference to the functional modules of Figures 7 and 8. However, it will be appreciated that the functionality described below may also be implemented in the nodes of Figures 5 and 6, performing examples of the methods 100, 200, 300 and/or 400, substantially as described above.

Implementation Architecture

An overview of a proposed architecture 900 for implementing the methods and nodes of the present disclosure is illustrated in Figure 9. The proposed architecture 900 is presented in two layers: the “Application Provider layer” 910 and the “Infrastructure Provider layer” 920. The application provider layer 910 includes an application node 911 operable to perform methods 100, 300 according to the present disclosure. The infrastructure provider layer includes an infrastructure node 921 operable to perform methods 200, 400 according to the present disclosure. In the example architecture of Figure 9, each of the application and infrastructure nodes 911 , 921 is implemented as a plurality of logical components. Each of the application and infrastructure nodes comprises a Behaviour Aware Agent 912, 922. Each of the application and infrastructure nodes also comprises at least part of a legacy logical element. The application node 911 encompasses at least a part of an Application Agent 916, which is enhanced with functionality supporting the full stack behaviour aware methods 100, 300 as discussed below. The infrastructure node 921 encompasses at least a part of an Application Key Indicators Monitor 926, which is enhanced with functionality supporting the full stack behaviour aware methods 200, 400 as discussed below.

In the following discussion, “Placement Operation” is presented as an example of an operation relating to the deployment of an application service on a cloud infrastructure, which operation is used to update the operational deployment of the service in accordance with the methods disclosed herein.

Table 1 below presents details about intercommunication between the different logical components of the architecture of Figure 9, the descriptions in Table 1 relating to the labels appearing in Figure 9. There then follows a discussion of the functionality provided by the illustrated components in the example architecture 900.

Table 1 Application Provider Layer Components

The application provider layer 910 provides the application that is deployed over the cloud infrastructure and is used by the users. The application provider layer 910 includes an “Application Behaviour-Aware Agent” (ABAA) 912 and an Application Agent 916. The Application Behaviour-Aware Agent 912 monitors the behaviour of a user and changes over time in that behaviour. When a change in user behaviour (actual or anticipated) occurs, the ABAA generates an alert and saves this data into a repository. The Application Agent 916 provides the user’s SLA requirements and conducts a signalling procedure with the Infrastructure Provider layer to negotiate the use of the infrastructure and exchange relevant information (for example the SLA requirements and behaviour information) to deploy the application. The ABAA 912 comprises a User Behaviour Monitor 913, an Alert Generator 914 and a User Behaviour Repository 915.

The User Behaviour Monitor 913 monitors the behaviour of application service users. Whenever the User Behaviour Monitor 913 receives new expected behavioural information from users (step 310 of method 300), it notifies the Alert Generator 914.

The User Behaviour Repository 915 stores the behavioural patterns of individual users, or of groups of users, based on the behavioural data received by the User Behaviour Monitor 913. The User Behaviour Repository 915 also includes the probability parameter of the user/group of users/service. The probability parameter may be expressed as a percentage and indicates the certainty level that the user will perform the given behaviour. The probability parameter is retrieved by the Alert Generator 914 and provided to the Application Agent 916, which uses the probability parameter when deciding whether or not to trigger changes at the Infrastructure Provider layer as a consequence of notified expected behaviour.

The Alert Generator 914 receives a notification about new behaviours of one or more users from the User Behaviour Monitor 913. The Alert Generator 914 then checks the User Behaviour Repository 915 to determine whether the user or the group of users, and/or the particular notified expected behaviour, exist in the repository (step 320a of method 300). When the user, group of users, and/or combination of user/group of users and expected behaviour, is found in the repository, the Alert Generator 914 also identifies its probability parameter (step 320f). The Alert Generator 914 then generates an alert and sends it to the Application Agent 916. This alert includes the new behaviour of the user along with the probability parameter for the user (when found).

The Application Agent 916 negotiates the use of the cloud infrastructure to deploy the application. The Application Agent 916 provides the structure, the requirements, and the constraints of the application to the Operation Engine (for example a Placement Engine) in the Infrastructure Provider layer. The Application Agent 916 also receives an alert from the Alert Generator 914 about a new user behaviour and its probability parameter when found. The Application Agent 916 then filters the alerts to retain only those alerts characterised with a probability parameter that meets a specific threshold given by an Application Analyst (steps 130, 140 of method 300). This is an example of the action criterion discussed above. The Application Analyst may for example be a person who is managing the application. The Application Agent 916 also decides the appropriate actions to handle user behaviours with probability parameters lower than the given threshold (step 340). The Application Agent 916 could for example decide to trigger a change on the Infrastructure Provider layer in order to adjust their operations accordingly, or to make no change to the current operation. When the Application Agent 916 decides to notify the Infrastructure Provider, it sends a request to the Behaviour Monitor & Aggregator (in the IBAA of the Infrastructure Provider layer) to update the deployment/placement plan according to the application behaviour-aware changes (generated from the new user behaviour) (step 350).

The structure of an application can be described by a graph with nodes and edges. The nodes of the graph represent the application components and edges between the nodes represent the connections between the application components. An example of an application graph with six nodes (e?, e2, 63, e , e , es, and eg) and seven edges between the nodes (n?, n2, n3, r>4, ns, and ns is shown in Figure 10.

The requirements of an application may be represented by the requirements of the nodes and edges. The nodes’ (i.e., application components) requirements can be described by, for example, the resource requirements (e.g., CPU, memory, storage) of the application and or specific application components, and by Quality of Service (QoS) requirements. The links’ (i.e., relationships between the application components) requirements can be described by bandwidth usage requirements, QoS requirements, etc. The constraints of an application can be described by, for example, the delay threshold tolerated by users, and nodes/links affinity, or anti-affinity constraints.

It will be appreciated that, as discussed above, if the infrastructure node, including the Infrastructure Behaviour-Aware Agent (IBAA) is absent from the Infrastructure Provider layer, the Application Agent can still use the new user behaviour. For instance, when a new user behaviour is received from the Alert Generator, the Application Agent may decide to enhance its application to provide a better experience to users, by making changes that can be implemented in the Application Provider layer, and/or by interacting with legacy components in the Infrastructure Provider layer (steps 360, 370). Considering a gaming application, these enhancements might include placing the game map closer to the users, so shortening content loading time, changing the colours of the environment, providing visual or audio effects, increasing/decreasing the difficulty of the game, etc. Such enhancements, based on the anticipated service use provided by the user, may for example adapt the game playing experience to the resources that will be available for the received expected future use, so improving the user’s overall gaming experience. In one example, if extensive use of the gaming application by a large number of users is anticipated at a particular location, potentially placing a high load on the cloud and communication network resources delivering the gaming service, the Application Agent may adapt the gaming environment to reduce resource requirements and ensure consistent gaming experience for all users.

Infrastructure Provider Layer Components

The Infrastructure Provider Layer provides the hardware and software resources, including computation, storage, and networking needed to deploy, manage, and execute applications. The Infrastructure Provider Layer 920 includes an Infrastructure Behaviour-Aware Agent (IBAA) 922 and legacy components of Infrastructure Provider layers. The IBAA 922 receives behaviour-aware data from different Application Providers, interprets this data into behaviour-aware application requirements, and revises the deployment plan of the applications when appropriate. The legacy components provide the typical orchestration and management functions for the execution of the application over the infrastructure resources, in addition, in the case of the Application Key Indicators Monitor 926, to supporting the functioning of the IBAA 922. The IBAA 922 comprises a Behaviour Monitor & Aggregator 923, a Behaviour Interpreter 924, and a Behaviour Requirement Repository 925. The Behaviour Monitor & Aggregator 923 collects the behavioural data of multiple applications from different Application Providers and passes them to the Behaviour Interpreter 924 (step 410 of method 400). The Behaviour Monitor & Aggregator 923 may also aggregate the received behavioural data from different Application Providers and present a combined behaviour to the Behaviour Interpreter (step 414). Behaviour aggregation can be efficient to avoid network traffic and also to manage applications with shared behaviour patterns. Examples of criteria for aggregation may include applications to be hosted at the same geographic location, applications with same users (if visible to the infrastructure provider), applications of the same type (i.e., memory-intensive, IO- intensive applications, delay-sensitive), and/or applications with the same device type of users.

The Behaviour Interpreter 924 translates applications’ behaviour-aware changes, received from the Behaviour Monitor and Aggregator 923 into behaviour-aware application requirements using the Behaviour Requirement Repository 925 (step 420 of method 400). The Behaviour Interpreter then requests the Operation Engine 927 to manage and deliver cloud services and infrastructure such that the users’ expectations are satisfied (step 430). For example, in the case of placement operation, the Behaviour Interpreter 924 asks the Operation Engine 927 to find the optimal deployment plan of the application(s) over the infrastructure resources such that both the application requirements (already provided and discussed above) and the behaviour-aware application requirements (newly generated on the basis of expected use information from the ABAA 912) are met.

Behaviour-aware application requirements may include, for example, the need for more resources at a specific time, the need for lower latency at a specific time, the need to reduce the waiting time for some applications, improve the resources utilization, etc.

The Behaviour Requirements Repository 925 stores relevant facts about applications’ behaviour-aware changes and their associated application requirements, along with a success rate of each entry (step 420e). The success rate is the percentage of success among a number of attempts when applying a specific behaviour-aware application requirement with respect to a specific behaviour. The Application-Key Indicators Monitor 926 monitors the key indicators of the application(s) deployed over the infrastructure nodes (e.g., performance, energy utilization) and updates the Behaviour Requirements Repository with the success rate of the deployment plan implemented with respect to the behaviour-aware changes (steps 440, 450). The success rate may be the percentage improvement of key indicators of an application (i.e. , performance) following implementation of operational deployment changes to fulfil the application behaviour aware requirements. The success rate highlights the translations from behaviour information to behaviour aware requirements which have resulted in improved application performance, so that the translations with high success rates may be prioritised when the same application behaviour-aware change is seen again.

The Infrastructure Repository 928 stores graph-like data of the cloud infrastructure, using a graph structure with nodes and edges to represent and store data. The nodes represent the infrastructure nodes along with their description such as capacity, cost, etc., and the edges represent the network links along with their description such as properties such as bandwidth capacity, cost, etc.

The Operation Engine 927 is responsible for managing the cloud infrastructure and executing its operations including placement, resource allocation, scheduling, etc. As mentioned above, one example of an Operation Engine is a “Placement Engine”, which is responsible for finding the optimal deployment plan for an application over the infrastructure resources. The Placement Engine runs a placement algorithm, which receives as input the application’s requirements and constraints (described above) and generates a deployment plan such that the application’s SLA is satisfied. This component also receives the behaviour-aware application requirements from the Behaviour Interpreter 924 and accordingly modifies or generates a new deployment plan.

It will be appreciated that, as discussed above, if the Application Behaviour-Aware Agent 912 is absent from the Application Provider layer, the Infrastructure Behaviour-aware Agent 922 can still use information provided by the Application Agent, such as application behaviour, to fulfil application requirements. One example would be that a gaming application foresees that it might need fewer instances in the next morning. It can send this estimation/prediction to the Infrastructure Behaviour-aware Agent. Figure 11 is a sequence diagram illustrating steps that may be carried out by the logical components of the example architecture 900 in performing examples of the methods 300, 400. The steps of the sequence diagram in Figure 11 are discussed below:

1. A User provides details about their expected behaviour scenario/context for a used application through an interface provided by the Application Provider to the user.

2. The User Behaviour Monitor 913, which is responsible for monitoring the input given by the user, detects the change on the input user behaviour and then notifies the Alert Generator 914 about the new user behaviour.

3. The Alert Generator 914 checks the User Behaviour Repository 915 to determine whether the new input user behaviour has been notified in the past or not.

4. When no previous corresponding user behaviour is found, the Alert Generator 914 is notified.

5. The Alert Generator 914 requests the User Behaviour Repository 915 to add the new user behaviour to the list of previous behaviours triggered for the application in question.

6. When previous corresponding user behaviour is found for the input user behaviour, the Alert Generator 914 obtains the probability parameter for the input user.

7. The Alert Generator 914 sends a notification to the Application Agent 915 about the new detected user behaviour according to the obtained probability parameter for the input user.

8. The Application Agent 915 sends an update request to the I BAA 922 in the Infrastructure Provider layer 920 to adjust the deployment plan accordingly. The request data is encapsulated with the data related to new changes in the application behaviour of the application in question.

9. The Behaviour Monitor & Aggregator 923 first checks whether the Application Agent has selected the option to aggregate its behaviour.

10. The Behaviour Monitor and Aggregator 923 then sends either the input behaviour data or the aggregated behavioural data to the Behaviour Interpreter 924.

11. The Behaviour Interpreter 924 checks the Behaviour Requirements Repository 925 for previous translations of behavioural data into application requirements, in order to translate the application behaviour-aware changes into behaviour-aware application requirements. 12. The Behaviour Interpreter 924 sends a new request to the Operation Engine 927 (Placement Engine in the present use case example) to update the placement operation plan in accordance with the new behaviour-aware application requirements.

13. The Operation Engine 927 (Placement Engine) generates the new operation plan and sends updates about the updated deployment plan for monitoring purposes to the Application-Key Indicators Monitor 926.

14. The Application-Key Indicators Monitor 926 updates the Behaviour Repository 925 about the performance of the application with respect to the updated deployment plan.

Example Use Case: Gaming in the Edge Cloud

Figure 12 illustrates an example scenario in which a user is accessing a gaming application that is deployed on an edge cloud infrastructure.

In the illustrated example, a game player “Alex”, who is travelling in a car, inputs his behaviour information “/ will arrive at C at around 11am” to the application provider layer via the User Behaviour Monitor 913. The information may be input via a dedicated interface provided in or via the application. The Alert Generator 914 alerts a new user behaviour to the Application Agent 916, after first checking the User Behaviour Repository 915 for a probability parameter. Upon receiving the alert, the Application Agent 916 at the Application Provider is able to make a decision that proactively places a game map at the base station near C in advance, i.e. before Alex actually arrives at C at around 11am. This will significantly improve Alex’s gaming experience with minimum map loading time. It is also possible that at the time the decision is taken there is no resource allocated at C for the Application Provider. In this case, the Application Provider may include a corresponding resource request as part of the behaviour information sent to the Infrastructure Provider, so that resources can be allocated for the Application Provider prior to placing the map at C for Alex. If the Application Provider is aggregating input from all end-users on-the-fly, the Application Provider may send behaviour information “I need more computing instances to serve 800 players at 11 :30am” input to the Infrastructure Provider. This information will be received at the Behaviour Monitor & Aggregator 923 within the Infrastructure Behaviour-Aware Agent 922. After grouping and aggregating data from other Application Agents, the information is passed to the Behaviour Interpreter 924, stored in the Behaviour Repository 925, and translated into behaviour-based application requirements. Upon receiving the behaviour-based application requirements, the Operations Engine 927 in the Infrastructure Provider layer 920 is able to perform resource allocation in advance. As a result, the SLA of the application can be preserved. The Application-Key Indicators Monitor 926 monitors key indicators of the application and provides the success rate to the Behaviour Repository 925.

It will be appreciated that gaming in the edge cloud is merely one example use case which may benefit from the methods and architectural components presented herein. Other example use cases may include a connected vehicle cloud, smart cities, industrial applications such as smart factories, goods transportation, etc. In all such use cases, improvements in terms of data accuracy, precision, timeliness, optimal decision making, and general improvement of user experience may be possible through the use of methods and architectural components presented herein.

Examples of the present disclosure thus propose a full-stack behaviour-aware architecture that facilitates the sharing of behavioural data between the providers of cloud infrastructure and the providers of applications deployed on such infrastructure, so as to support improved operational deployment decisions in a dynamic manner, as events occur in the cloud environment. In the application provider layer, an interface may be provided that allows end-users to input their expected behaviour to the application provider. Changes in user behaviour are notified and stored together with an indication of the likelihood that provided expected behaviour will be executed. In the infrastructure provider layer, an interface may be provided that allows application providers to input behaviours to the infrastructure provider. Different behaviour-aware data relating to different applications, which may be from different domains, is analysed and may be aggregated. This data is then translated to behaviour-aware application requirements which will satisfy the notified changes in the user behaviour. These requirements are then notified to an operations engine to initiate operational deployment changes that will meet the requirements. Data about application behaviour changes and their associated application behaviour-aware requirements are stored to facilitate future translations. In the application layer, the behaviour data can also be used to enhance the application so as to provide a better experience to the users. For example, in a gaming application, a game map may be placed closer to users, so shortening content loading time, environment colours may be changed, visual or audio effects may be provided or augmented, and game difficulty may be increased or decreased, thus adapting the gaming experience to anticipated available resources and so improving overall user experience. The feedback and updating of probability parameters and success measures allows for continual learning and the development of an extensive knowledge base about user behaviour and associated requirements, which can be used to ensure that new behaviours are quickly translated into requirements for implementation in the cloud infrastructure, offering dynamic infrastructure management for fast changing environments.

The example nodes and architecture may be implemented and used within any distributed or centralised cloud system. The architecture can be implemented in a single module or can be distributed through different nodes in different interconnected modules.

The methods of the present disclosure may be implemented in hardware, or as software modules running on one or more processors. The methods may also be carried out according to the instructions of a computer program, and the present disclosure also provides a computer readable medium having stored thereon a program for carrying out any of the methods described herein. A computer program embodying the disclosure may be stored on a computer readable medium, or it could, for example, be in the form of a signal such as a downloadable data signal provided from an Internet website, or it could be in any other form.

It should be noted that the above-mentioned examples illustrate rather than limit the disclosure, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims or numbered embodiments. The word “comprising” does not exclude the presence of elements or steps other than those listed in a claim or embodiment, “a” or “an” does not exclude a plurality, and a single processor or other unit may fulfil the functions of several units recited in the claims or numbered embodiments. Any reference signs in the claims or numbered embodiments shall not be construed so as to limit their scope.