Auto-scaling data plane

Abstract

A method for adjusting the number of virtual machines in a data plane is provided. A plurality of virtual machines in the data plane each having a data plane proxy are provisioned. The plurality of virtual machines provide data routing for an operation pod of a first pod number as a first number in a deployment plane associated with the data plane. The status of the deployment plane is monitored. The status reflects that the deployment plane has a second pod number different from the first pod number of the operation pod. The first pod number of the operation pod is compared with the second pod number. Based on the comparison, the number of virtual machines in the data plane is adjusted.

Description

Technical Field

[0001] Embodiments generally relate to distributed computing environments. More particularly, although not limited thereto, it relates to provisioning a data plane proxy for a deployment plane based on changing data throughput requirements related to the deployment plane.

Background Art

[0002] (Claim of Priority) This patent application claims the benefit of priority of U.S. Application Serial No. 17 / 809,653, filed on June 29, 2022, which is hereby incorporated by reference in its entirety.

[0003] Cloud computing systems are becoming increasingly popular as a way to provide computer-implemented resources. Service providers are enabled to provide services to various end-users based on the needs of the various end-users. Virtual machines that execute data plane proxies are used to ensure that traffic is properly routed to each of the various end-users.

[0004] Typically, when an end user requests resources from a service provider, virtual machines resident in the data plane are assigned to assist with routing. Further elaborating, the end user is enabled to use application instances such as Apache Kafka (registered trademark), Kafka (registered trademark) Structured Query Language (KSQL), Schema Registry, Connect, etc. The application services are implemented in pods in the deployment plane. In the data plane, virtual machines are provisioned based on the number of pods implementing the application services. The virtual machines can be used to assist with routing the traffic of various pods in the deployment plane. In many cases, the number of virtual machines assigned to various pods is fixed at deployment time.

Prior Art Documents

Patent Documents

[0005]

Patent Document 1

Summary of the Invention

Problems to be Solved by the Invention

[0006] There is a need to provide an improved auto-scaling data plane.

Means for Solving the Problems

[0007] The various accompanying drawings merely illustrate exemplary embodiments of the present disclosure and should not be considered as limiting its scope.

Brief Description of the Drawings

[0008]

Figure 1

Figure 2

Figure 3A

Figure 3B

Figure 4

Figure 5

[0009] The following description includes systems, methods, techniques, instruction sequences, and computing machine program products that embody exemplary embodiments of the present disclosure. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide an understanding of various embodiments of the inventive subject matter. It will be apparent, however, to one skilled in the art that embodiments of the inventive subject matter may be practiced without these specific details. In general, well-known instruction examples, protocols, structures, and techniques are not necessarily shown in detail.

[0010] As described above, the number of virtual machines assigned (allocated) to various pods is fixed at the time of deployment. However, after the virtual machines are provisioned, the needs of the end user may change. To explain further, the end user may require fewer pods in the deployment plane to meet their needs, or may require more pods in the deployment plane to meet their needs. Nevertheless, the number of virtual machines allocated in the data plane is fixed. Therefore, if the end user implements fewer pods after the virtual machines are provisioned, there is a risk of "over-provisioning" where the number of virtual machines allocated to the deployment planes with pods is too high. If the user's needs increase after provisioning and the end user implements more pods, there is a risk of "under-provisioning" where sufficient virtual machines are not allocated to the deployment planes with pods.

[0011] Before the service provider receives the request, the deployment plane can be allocated to the data plane. Here, a fixed number of virtual machines are allocated to the deployment plane based on the historical data related to the deployment plane. To further explain, the deployment plane may conventionally have a throughput requirement of 10 gigabits per second (Gbps). Therefore, in the data plane related to the deployment plane, two virtual machines that can each support 5 Gbps are required. For this reason, regardless of the requirements of the end user, for example, even if the end user only needs a throughput of 50 megabits per second (Mbps), two virtual machines will be allocated to the deployment plane. In this case as well, there is a risk of over-provisioning. Furthermore, if the end user's throughput requirement is 20 Gbps and usually four virtual machines are required, there are only two virtual machines in the data plane allocated to the deployment plane related to the end user's pod. Therefore, under-provisioning occurs.

[0012] Therefore, what is needed is a method of scaling the data plane in response to changes in the needs of the end user after the deployment of the data plane proxy. Embodiments relate to a system and method for dynamically adjusting the number of virtual machines in a data plane that routes traffic for pods within a deployment plane. First, a first number of virtual machines can be provisioned for the deployment plane based on a first number of operational pods in the deployment plane that are implemented. The number of operational pods in the deployment plane can be changed based on the needs of the end user implementing the pods. Thus, in an embodiment, after provisioning, the status of the deployment plane is monitored. In some examples, the status can be monitored during a first period. The status can be related to the actual number of operational pods in the deployment plane. Thus, depending on the status of the deployment plane, it can be revealed that operational pods of a second number of pods different from the first number of pods are operational in the deployment plane.

[0013] The first number of operational pods in the deployment plane is compared with a second number of operational pods in the deployment plane. In an example, the first number of operational pods can be related to the number of pods that the end user initially indicated as being needed. In some further examples, the first number of pods can be made to be the number of pods used when determining the number of virtual machines to initially provision. Based on the comparison, the number of virtual machines operating in the data plane is adjusted. This document refers to dynamically changing the number of virtual machines. As described above, the virtual machines exist in the data plane. Thus, while the virtual machines exist in the data plane, the number of active virtual machines changes. Thus, the data plane changes. Thus, in an example, dynamically changing the number of virtual machines is also related to dynamically changing the data plane.

[0014] In an example, the number of second pods of the operation pod can be made less than the number of first pods of the operation pod. Accordingly, the number of virtual machines in the data plane can be dynamically decreased after the initial provisioning. In a further example, the number of second pods of the operation pod can be made greater than the number of first pods of the operation pod. Accordingly, the number of virtual machines in the data plane can be dynamically increased after the initial provisioning.

[0015] In a further embodiment, after the number of virtual machines is adjusted after a first time period, monitoring of the status of the deployment plane continues during a second time period. The status may reveal that pods with a third pod number, which may be different from the second pod number, are made operable in the deployment plane. The number of second pods of the operation pod in the deployment plane is compared with the number of third pods of the operation pod in the deployment plane. Based on the comparison, the number of virtual machines operating in the data plane is adjusted.

[0016] The embodiments improve the functionality of computing devices. As will be described below, the embodiments determine whether the computing requirements of multiple (a large number of) computing devices, such as pods, exceed the ability of another computing device, such as a machine corresponding to a virtual machine, to provide those computing requirements. As will be detailed below, a pod may have specific bandwidth requirements for properly executing the application instances operating thereon. The embodiments ensure that sufficient computing resources are provided to the pod by a virtual machine implementing a physical computing device to enable proper functionality of the pod. Thus, without the embodiments defined herein, there is a risk that the computing pod will not function properly. Therefore, the functionality of computing devices such as the aforementioned pod is improved.

[0017] Referring now to the figures, and more particularly to FIG. 1, there is shown a computing environment 100 in which an embodiment is operable. The computing environment 100 can include a virtual private cloud 102. Data can be provided from the virtual private cloud 102 to clusters 104 and 106 within a deployment plane 107. Examples of the virtual private cloud 102 can include Amazon Web Services® (AWS®), IBM Cloud®, Google Cloud Platform, Microsoft Azure, and the like.

[0018] In an example, a data plane 108 facilitates routing of data from the virtual private cloud 102 to each of the clusters 104 and 106. The data plane 108 can employ virtual machines 110A, 110B, 112A, and 112B (referred to herein as virtual machines 110 and 112) that have data plane proxies 114A, 114B, 116A, and 116B (referred to herein as data plane proxies 114 and 116). The data plane proxies 114 and 116 are enabled to mediate and control network communication between the virtual private cloud 102 and the clusters 104 and 106. The data plane proxies 114 and 116 are enabled to execute on the virtual machines 110 and 112. The virtual machines 110 and 112 are enabled to provide functions associated with a physical computer based on a computer architecture. Thus, in an example, the virtual machines 110 and 112 are enabled to correspond to a physical computer such that the data plane can also correspond to the physical computer in a context where the data plane improves the performance of a computing device.

[0019] Virtual machines 110A and 110B are associated with availability zone 118. Further, virtual machines 112A and 112B are associated with availability zone 120. Availability zones 118 and 120 can correspond to virtual machines such as virtual machines 110 and 112 that are available to assist with data routing to clusters, such as routing data from virtual private cloud 102 to clusters 104 and 106. In the example, availability zones 118 and 120 and associated virtual machines 110 and 112 are first provisioned to clusters 104 and 106. Thus, in an example where virtual machines 110A and 110B are provisioned to cluster 104 as indicated at 122, virtual machines 110A and 110B are enabled to route traffic corresponding to data from virtual private cloud 102 to cluster 104. Virtual machines 110A and 110B are enabled to ensure that the traffic arrives at an appropriate destination, such as a pod associated with cluster 104. In some examples, the pod associated with cluster 104 is a stateful device. Thus, if unauthorized data is routed to the pod associated with cluster 104, the pod may be unable to process the data. Routing can be based on server name indication information (SNI) extracted from connection setup packets used during the setup of communication links with virtual private cloud 102. Similarly, as described at 124, in an instance where virtual machines 112A and 112B are provisioned to cluster 106, virtual machines 112A and 112B are enabled to route traffic corresponding to data from virtual private cloud 102 to cluster 106. In some cases, similar to cluster 104, the pod associated with cluster 106 can be a stateful device. Thus, if incorrect data is routed to the pod associated with cluster 106, the pod may be unable to process the data.Routing can be based on server name indication information SNI extracted from connection setup packets used during the setup of communication links with the virtual private cloud 102.

[0020] Only two clusters 104 and 106 are shown in FIG. 1. However, in the embodiments, any number of available data planes having any number of virtual machines can be provisioned to the clusters, assuming any number of clusters. As shown with reference to FIG. 2, with respect to clusters 104 and 106, cluster 104 / 106 can comprise stateful sets 200 and 202. In one example, stateful set 200 is associated with pods 204A - 204D, and stateful set 202 can be associated with pods 206A - 206D. Stateful sets 200 and 202 are enabled to manage and maintain respective pods 204A - 204D and 206A - 206D. Pods 204A - 204D and 206A - 206D can be a group of one or more containers that can share storage resources along with network resources. Pods 204A - 204D and 206A - 206D can be any type of computing device as described herein. Each of pods 204A - 204D and 206A - 206D can comprise several components. Further elaborating, each of pods 204A - 204D and 206A - 206D can comprise an ordinal, a stable storage device, and a stable network ID. Further, each of pods 204A - 204D and 206A - 206D can represent an application instance capable of running an application within a physical cluster (104 / 106). Examples of application instances that each of pods 204A - 204D and 206A - 206D can run can include Apache Kafka (registered trademark), Kafka (registered trademark) Structured Query Language (KSQL), Schema Registry, Connect, and the like. In the example, each of pods 204A - 204D and 206A - 206D can have its own lifecycle and one of the following status (states), namely "waiting", "running", or "terminated".Furthermore, when all pods 204A - 204D are in the RUN state (running state), the stateful set 200 is fully available. Similarly, when all pods 206A - 206D are in the RUN state, the stateful set 202 is fully available.

[0021] Each of the stateful sets 200 and 202 can have labels added to each of the pods 204A - 204D and 206A - 206D associated with the stateful sets 200 and 202. In the example, the labels may enable a user associated with the stateful sets 200 and 202 to attach services to each of the pods 204A - 204D and 206A - 206D. Each of the stateful sets 200 and 202 may include an ordinal index that assigns ordinal numbers (originals) assigned to the pods 204A - 204D and 206A - 206D. Further, the stateful sets 200 and 202 can have hostnames, headless services, domains, and DNS subdomains associated with the stable network identities of the pods 204A - 204D and 206A - 206D. In the example, the cluster 104 / 106 can be enabled to implement Kubernetes object resource types to support an incremental change notification feed such as a watch application programming interface (API).

[0022] Returning attention to FIG. 1 and computing environment 100. Traffic control device (traffic controller) 126 can be made to reside (be resident, exist) in deployment plane 107. Note that in some examples, traffic control device 126 can also exist in data plane 108. Traffic control device 126 is made able to communicate with each of clusters 104 and 106. Traffic control device 126 is also made able to communicate with cloud virtual machine API 128. Traffic control device 126 monitors the operational status of pods within deployment plane 107. Along with this, traffic control device 126 is made able to issue application programming interface (API) commands based on the operational status of pods within deployment plane 107. The API commands relate to adjusting the number of virtual machines 110 and 112 provisioned for deployment plane 107. In an example, traffic control device 126 can be made a Kubernetes controller that monitors the status of clusters 104 and 106. Kubernetes is a container management system that enables the deployment of web applications, batch jobs, and databases via a unified application programming interface (API). Traffic control device 126 is made able to listen for changes in clusters 104 and 106. An example of a change in one of clusters 104 and 106 can include the addition or deletion of any of pods 204A - 204D and 206A - 206D associated with one of clusters 104 and 106.

[0023] Furthermore, traffic control device 126 is made able to determine the expected traffic load. Traffic control device 126 is made able to determine the traffic load as a function of the number of pods apportioned for a service and the service type according to the following formula.

[0024] T = sum(N * S) ··· (1). Here, T corresponds to the traffic load requirement or the traffic capacity requirement. Further, N corresponds to the number of service pods. For example, when the cluster uses Apache Kafka (registered trademark), the cluster can have four pods that use Apache Kafka (registered trademark). In this example, N corresponds to four. S corresponds to the type of service utilized by the pod. Depending on the type of service, the required bandwidth is different. To further explain, Apache Kafka (registered trademark) has a high traffic load and requires even more network bandwidth. Therefore, for each pod using Apache Kafka (registered trademark), the requirement for network bandwidth becomes high. Based on the high requirement for network bandwidth, the virtual machine needs to allocate more resources to one pod. Therefore, for the pods using Apache Kafka (registered trademark), the demand for network bandwidth for each pod becomes high. Thus, the virtual machine may be provisioned for three pods.

[0025] However, other services may have a large computational load (computationally intensive) while requiring little bandwidth. To further explain, KSQL has a large computational load while requiring little traffic. Therefore, each pod using KSQL has a low requirement for network bandwidth. Based on the low requirement for network bandwidth, the virtual machine needs to allocate (devote) fewer resources to a single pod. Here, in the case of Apache Kafka (registered trademark), the same virtual machine can only support three pods. In contrast to Apache Kafka (registered trademark), since the virtual machine has a low requirement for network bandwidth, it can be provisioned for ten pods.

[0026] In the example, the traffic control device 126 calculates that when the virtual machine requirements of a cluster having pods added or removed change due to a change in the traffic load. Then the traffic control device 126 is enabled to issue an instruction via the cloud virtual machine API 128. The traffic control device 126 can issue an instruction based on the status of clusters 104 and 106 and the calculated predicted traffic load. The instruction issued by the traffic control device 126 enables the dynamic adjustment of the number of virtual machines such as virtual machines 110 and 112 provisioned in clusters 104 and 106. Referring to FIGS. 3A and 3B, an example of a method for adjusting the number of virtual machines in the data plane that routes the traffic of pods in the deployment plane is shown.

[0027] Refer now to FIG. 3A and method 300. First, in operation 302, a plurality of virtual machines are provisioned for a deployment plane having operational pods as the first number of pods as the first number. As described above, the virtual machines are enabled to route traffic corresponding to data from a source such as the virtual private cloud 102 to an endpoint such as the cluster 104. The routing can be based on server name indication information SNI. The server name indication information SNI has been extracted from the connection setup packet used during the setup of the communication link with the virtual private cloud 102. During operation 302, the type of service utilized by the pods of the cluster is determined. As used herein, the term "operational pod" or "plurality of operational pods" can refer to a pod or plurality of pods that actively utilize services, such as pods 204A-204D and 206A-206D. For example, pod 204A is enabled to utilize KSQL with data from the virtual private cloud 102. Thus, pod 204A can be considered an operational pod. Further, pod 204D may remain offline. That is, pod 204D does not utilize any type of application instance. Here, pod 204D can be considered "non-operational". Further, the pod is part of the deployment plane. Thus, the operational pods can be considered the operational pods that the deployment plane has such that the number of operational pods corresponds to the first number of pods (the first number).

[0028] As an example of a method 300 referred to herein as "the illustration" (description), during operation 302, as shown with reference to FIG. 1, virtual machines 110A and 110B can be provisioned to cluster 104. In the figure, end users associated with pods within cluster 104 desire to use application instances of Apache Kafka (registered trademark) in pods 204A - 204C, 206A, and 206B. The end users wish to use pods 204A - 204C, 206A, and 206B in combination with traffic received from AWS (registered trademark) that has already been received via virtual private cloud 102. Thus, pods 204A - 204C, 206A, and 206B can be in an online state. Thus, since pods 204A - 204C, 206A, and 206B are implemented, they can be regarded as operating pods.

[0029] In the figure, each of pods 204A - 204C, 206A, and 206B has a data throughput requirement of 25 Gbps, so the total data throughput requirement is 125 Gbps. Further in the figure, each of virtual machines 110A and 110B is enabled to support a data throughput requirement of 100 Gbps. Thus, during operation 302, virtual machines 110A and 110B can be provisioned to cluster 104 to meet the 125 Gbps data throughput requirement, while the combined total data throughput of virtual machines 110A and 110B is 200 Gbps. Further, pods 204A - 204C, 206A, 206B are associated with cluster 104 which is part of deployment plane 107. Since there are five operating pods in deployment plane 107, in the example shown, the first pod number (the first number) of the operating pods in deployment plane 107 is "5".

[0030] Return to FIG. 3A and method 300. After virtual machines 110A and 110B are first provisioned during operation 302, method 300 performs operation 304. During operation 304, method 300 monitors the status of the deployment plane. In the example, the status may reflect that the deployment plane currently has a second pod count (second number) of the operation pods. The second pod count may be different from the first pod count of the operation pods. The operation pod count may change such that the first pod count (first number) of the operation pods and the second pod count (second number) of the operation pods are different for various reasons. Further elaborating, after provisioning, the data throughput requirements for the end user may change. Thus, the data throughput requirements may increase or decrease. If the end user's data throughput requirements increase, the end user is enabled to add more operation pods to the deployment plane. If the end user's data throughput requirements decrease, the end user is enabled to remove operation pods from the deployment plane. Alternatively, after provisioning, the end user may be engaged in the process of configuring the pods that will be operated in a deployment plane where no pods are yet in operation. Since no pods are yet in operation in the deployment plane, there are no data throughput requirements for the deployment plane, such as the need to provision virtual machines for the deployment plane. Regardless of whether operation pods have been added to or removed from the deployment plane, in the example, a Kubernetes configuration controller, such as traffic control device 126, is enabled to listen for a count of the number of pods used by each service during operation 304.

[0031] After monitoring the status of the deployment plane during operation 304, method 300 performs operation 306. Operation 306 compares the number of the first pods of the action pods in which the virtual machines are provisioned with the number of the second pods determined during operation 304. In an embodiment, based on the comparison, a determination may be made as to whether the number of virtual machines provisioned in the deployment plane should be adjusted during operation 308.

[0032] In some embodiments, the number of action pods in the deployment plane may be changed. However, the number of virtual machines provisioned for the deployment may not necessarily be changed. For example, a single virtual machine has been made capable of supporting a data throughput of 100 Gbps. The number of the first pods in the deployment plane, which is "4", has a total throughput requirement of 100 Gbps since each has a data throughput requirement of 25 Gbps. During operation 304, if the status reflects that "3" pods are made operational in the deployment plane, the data throughput requirement drops to 75 Gbps. Here, a single virtual machine has been made capable of providing a throughput of 75 Gbps. That is, 75 Gbps is less than the 100 Gbps capacity of the virtual machine. Therefore, a determination may be made that the number of virtual machines provisioned in the deployment plane should not be adjusted during operation 308.

[0033] As another example, again, assume that a single virtual machine is capable of supporting a data throughput of 100 Gbps, and each of the operating pods in the deployment plane with the first pod number (which is "4") has a data throughput requirement of 25 Gbps. During operation 304, the status can be made to reflect that five pods are operable (operational) in the deployment plane. Thus, the second pod number as the number of operating pods in the deployment plane has increased from "4" to "5". Further, the fifth operating pod has a data throughput requirement of 25 Gbps. Thus, the virtual machine provisioned in the data plane must be able to support a data throughput of 125 Gbps. However, one virtual machine with a data throughput of 100 Gbps is allocated to the deployment plane. Therefore, it is determined that the number of virtual machines provisioned in the deployment plane needs to be adjusted. A second virtual machine with a throughput of at least 25 Gbps is provisioned in the deployment plane with five operating pods which is the second pod number.

[0034] As yet another example, a single virtual machine is enabled to support a data throughput of 100 Gbps, and the scenario is limited to one where each of the "4" operational pods in the deployment plane, which has a data throughput requirement of 25 Gbps. During operation 304, the status reflects that there are no operational pods in the deployment plane. This can occur when the end user has not yet started the deployment of the pods because they are still preparing the pods for deployment. Here, the data throughput via the data plane without operational pods is nil. Therefore, the number of virtual machines provisioned in the deployment plane should be adjusted. Since there are no operational pods in the deployment plane, a decision can be made that virtual machines should not be provisioned in the deployment plane.

[0035] Returning to the figure, during operation 304, the traffic control device 126 can listen for the count of operational pods to monitor the status of the deployment plane 107. During operation 304, the traffic control device 126 determines that there are no operational pods within the cluster 104 by listening for the count. In the figure, an end user implementing application instances of Apache Kafka (registered trademark) with pods 204A - 204C, 206A, and 206B is configuring these pods for the implementation of the application instances of Apache Kafka (registered trademark). Therefore, none of the pods 204A - 204C, 206A, and 206B are operating. In the figure, the number of the second pod of operational pods in the deployment plane 107 is "zero".

[0036] As shown, in operation 306, traffic control device 126 compares the first pod number, which is "5", with the second pod number, which is "0". Based on this comparison, traffic control device 126 recognizes that there is no need to provision virtual machines to deployment plane 107. Traffic control device 126 determines that the number of virtual machines to be provisioned to deployment plane 107 should be adjusted during operation 308.

[0037] Returning to FIG. 3A and method 300, after operation 308, method 300 performs operation 310. The number of virtual machines can be adjusted based on the comparison between the first pod number and the second pod number. In some embodiments as described above, the second pod number can be greater than the first pod number. Further, considering the scenario where the total data throughput requirement increases from 100 Gbps to 125 Gbps and a single virtual machine has a data throughput (overall) capacity of 100 Gbps, the more operation pods there are, the more additional virtual machines are required. The number of virtual machines to be provisioned can be adjusted so that additional virtual machines are provisioned to the deployment plane having additional operation pods.

[0038] Also, in some embodiments as described above, the number of second pods can be made less than the number of first pods. A smaller number of operational pods may require fewer virtual machines. For example, consider the scenario where the total data throughput requirement decreases from 125 Gbps to 100 Gbps, and one virtual machine has a data throughput capacity of 100 Gbps. Two virtual machines are provisioned in the deployment plane. In this case, it is possible to remove one of the virtual machines from the deployment plane. In particular, one virtual machine can provide a data throughput of 100 Gbps. Thus, the number of virtual machines provisioned in the deployment plane can be adjusted so that one virtual machine can be provisioned in the deployment plane.

[0039] Returning to the figure, as described above, during operation 308, the traffic control device 126 determines that it is necessary to adjust the number of virtual machines provisioned in the deployment plane 107. More specifically, the traffic control device 126 determines that none of the pods 204A - 204C, 206A, and 206B are operating (running). Therefore, the traffic control device 126 decides in operation 308 that the number of virtual machines provisioned in the deployment plane 107 should be adjusted. During operation 310, in the illustrated example, the traffic control device 126 is able to issue an instruction (indication) to the cloud virtual machine API 128 indicating that the virtual machine should be removed since it is being provisioned to the cluster 104. Thus, during operation 310, the virtual machine 110A is removed so that it is no longer provisioned to the cluster 104.

[0040] Returning attention to FIG. 3A and method 300, upon completion of operation 310, method 300 is enabled to perform operation 312. In operation 312, the status of the deployment plane is monitored. In an example, the status may reflect that the deployment plane currently has a third pod count. The third pod count may be different from the second pod count. The operating pod count can vary for various reasons as described above with reference to operation 304 such that the second pod count is different from the third pod count.

[0041] After monitoring the status of the deployment plane during operation 312, method 300 performs operation 314. Operation 314 compares the second pod count of the operating pod in which the virtual machine was provisioned with the third pod count of the operating pod determined during operation 312. In an example, based on the comparison, a determination can be made as to whether the number of virtual machines provisioned to the deployment plane should be adjusted during operation 316.

[0042] In some embodiments, the number of operating pods within the deployment plane can be changed. On the other hand, the number of virtual machines provisioned to the deployment may not necessarily be changed. For example, a single virtual machine may be enabled to support a data throughput of 100 Gbps. The operating pods with a second pod count within the deployment plane can each have a data throughput requirement of 25 Gbps and thus can have a total throughput requirement of 100 Gbps. During operation 312, if the status reflects that "3" pods are enabled to operate in the deployment plane, the data throughput requirement drops to 75 Gbps. Here, a single virtual machine has the ability to provide a throughput of 75 Gbps. That is, 75 Gbps is less than the 100 Gbps capacity of the virtual machine. Thus, during operation 316, it is enabled to determine that the number of virtual machines provisioned to the deployment plane should not be adjusted.

[0043] As another example, again, a single virtual machine is enabled to support a data throughput of 100 Gbps, and the scenario is limited to one where the number of operating pods in the second pod number in the "4" deployment planes each have a data throughput requirement of 25 Gbps. During operation 312, the status can be made to reflect that "5" pods are operable (operational) in the deployment plane. Thus, the number of third pods in the deployment plane increased from "4" to "5". Further, the fifth operating pod has a data throughput requirement of 25 Gbps. Thus, the provisioned virtual machine in the data plane needs to be able to support a data throughput of 125 Gbps. However, in the deployment plane, one virtual machine having a data throughput of 100 Gbps is allocated. For this reason, the number of virtual machines provisioned in the deployment plane is adjusted. It can be determined that a second virtual machine having a throughput of at least 25 Gbps needs to be provisioned in the deployment plane having "5" operating pods as the number of third pods.

[0044] As yet another example, a single virtual machine is enabled to support a data throughput of 100 Gbps, and the scenario remains the same where the operating pods in the second pod number (which is 4) in the deployment plane each have a data throughput requirement of 25 Gbps. During operation 312, the status reflects that there are no operating pods (no pods) in the deployment plane. This can occur when the end user has not yet started the deployment of the pods because they are still preparing the pods for deployment. Here, the data throughput via the data plane with no operating pods is none. Thus, the number of virtual machines provisioned in the deployment plane should be adjusted. Since there are no operating pods in the deployment plane, a decision can be made that no virtual machines should be provisioned in the deployment plane.

[0045] Returning to the figure, during operation 312, the traffic control device 126 is enabled to listen for the count of the operation pods to monitor the state of the deployment plane 107. During operation 312, the traffic controller determines that pods 204A - 204C and 206A are operation pods within cluster 104 by listening for the count. In the figure, the end user implementing pods in cluster 104 wishes to run Apache Kafka (registered trademark) application instances on pods 204A - 204C and 206A. Accordingly, pods 204A - 204C and 206A are made operational. While listening for the count here, the traffic control device 126 determines that pods 204A - 204C and 206A are made operational. Pods 204A - 204C and 206A are enabled to correspond to the third pod count in operation 314. The third pod count is "4" in the illustration.

[0046] Adhering to the illustration, in operation 316, the traffic control device 126 compares the third pod count of the operation pods, which is "4", with the second pod count, which is "0". Since no virtual machines are provisioned in the deployment plane 107 (for example, "zero" operation pods require "zero" virtual machines), based on the comparison, the traffic control device 126 recognizes that virtual machines should be provisioned in the deployment plane 107. During operation 316, it is determined that the number of virtual machines to be provisioned in the deployment plane 107 should be adjusted. More specifically, each of pods 204A - 204C and 206A is running an Apache Kafka (registered trademark) application instance that requires 25 Gbps of data throughput for each of pods 204A - 204C and 206A. Accordingly, the deployment plane 107 has a total data throughput requirement of 100 Gbps.

[0047] Returning to FIG. 3B and method 300, after operation 316, method 300 performs operation 318. The number of virtual machines can be adjusted based on a comparison between the number of second pods and the number of third pods of the operation pods. In some cases as described above, the number of third pods of the operation pods can be greater than the number of second pods. Further, as the total data throughput requirement increases from 100 Gbps to 125 Gbps, more operation pods may require additional virtual machines, such as in the above scenario where a single virtual machine has a data throughput capacity of 100 Gbps. In this case, the number of virtual machines to be provisioned can be adjusted so that additional virtual machines are provisioned to the deployment plane having the additional operation pods.

[0048] Also, in some embodiments as described above, the number of third pods can be made less than the number of second pods. When a smaller number of operation pods require fewer virtual machines, for example, when the total data throughput requirement decreases from 125 Gbps to 100 Gbps. In the above scenario where two virtual machines are provisioned to the deployment plane and one virtual machine has a data throughput capacity of 100 Gbps, one of the virtual machines can be removed from the deployment plane. In particular, one virtual machine can provide a data throughput of 100 Gbps. Thus, the number of virtual machines provisioned to the deployment plane can be adjusted so that one virtual machine can be provisioned to the deployment plane.

[0049] Returning to the figure, as described above, during operation 316, the traffic control device 126 determined that it was necessary to adjust the number of virtual machines provisioned in the deployment plane 107. More specifically, the traffic control device 126 determined that pods 204A-204C and 206A were operable. Accordingly, the traffic control device 126 determined in operation 316 that the number of virtual machines provisioned in the deployment plane 107 should be adjusted. In particular, each of pods 204A-204C and 206A runs an application instance of Apache Kafka (registered trademark). Since each of pods 204A-204C and 206A requires a data throughput of 25 Gbps, the total data throughput is 100 Gbps. In the figure, each of virtual machines 110A and 110B is enabled to provide a total data throughput of 100 Gbps. Thus, during operation 318, the number of virtual machines is adjusted from zero virtual machines to one virtual machine based on a comparison of the number of second operating pods and the number of third operating pods.

[0050] During operation 318, as shown in the figure, the traffic control device 126 is enabled to issue an instruction to the cloud virtual machine API 128. Here, the instruction indicates that virtual machine 110A should be provisioned in cluster 104. Accordingly, during operation 318, virtual machine 110A is provisioned in cluster 104. After completion of operation 318, method 300 is completed.

[0051] Returning attention to operation 308. Operation 308 relates to determining whether the number of virtual machines should be adjusted based on a comparison between the number of first pods and the number of second pods. If it has been determined that the number of virtual machines should be adjusted, method 300 executes operation 310. However, if method 300 determines during operation 308 that the number of virtual machines should not be adjusted, method 300 executes operation 312.

[0052] Returning to operation 316. Operation 316 relates to determining whether to adjust the number of virtual machines based on a comparison between the number of second pods and the number of third pods. During operation 316, if a decision is made that the number of virtual machines should not be adjusted, method 300 is complete.

[0053] Method 300 describes monitoring the status of the deployment plane twice during operations 304 and 312. However, note that the status of the deployment plane can be monitored only once. That is, operations 312 - 318 can be removed so that method 300 only performs operations 302 - 310. Here, if a decision is made during operation 308 that the number of virtual machines should not be completed, method 300 is complete.

[0054] Furthermore, method 300 describes monitoring the status of the deployment plane twice during operations 304 and 312. However, note that the status of the deployment plane can be monitored any number of times. Additionally, the example assumes that instead of method 300 ending after the completion of operation 318, method 300 is a continuous loop in which operations 302 - 318 or operations 304 - 318 are continuously executed.

[0055] Any of the machines, databases, or apparatuses shown in FIGS. 1 and 2 can be implemented on a general-purpose computer that has been modified (e.g., configured or programmed) by software to be a special-purpose computer for performing the functions described herein for that machine, database, or apparatus. For example, a computer system capable of performing any one or more of the methodologies described herein is described below with respect to FIGS. 4 and 5. As used herein, a "database" is a data storage resource and is capable of storing data structured as a text file, table, spreadsheet, relational database (e.g., an object-relational database), triple store, hierarchical data store, or any suitable combination thereof. Further, any two or more of the machines, databases, or devices illustrated in FIG. 1 may be combined into a single machine, database, or device, or the functions described herein for any single machine, database, or device may be subdivided among a plurality of machines, databases, or devices. In the example, the communication links between the elements of the computing environment 100 are implemented via one or more data communication networks. These data communication networks are capable of utilizing any wired or wireless communication protocol and any type of communication medium. In some embodiments, the data communication network is a combination of two or more data communication networks (or sub-networks) coupled to each other.

[0056] Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. A module can be either a software module (e.g., code embodied on a machine-readable medium) or a hardware module. A “hardware module” is a tangible unit capable of performing certain operations and configured or arranged in a particular physical manner. In various exemplary embodiments, one or more computer systems (e.g., a stand-alone computer system, a client computer system, or a server computer system), or one or more hardware modules of a computer system (e.g., a processor or a group of processors), can be configured by software (e.g., an application or an application portion) as a hardware module that operates to perform certain operations as described herein.

[0057] In some embodiments, the hardware module can be implemented in mechanical, electronic, or any suitable combination thereof. For example, the hardware module can comprise dedicated circuitry or logic permanently configured to perform certain operations. For example, the hardware module can be a dedicated processor such as an FPGA (Field-Programmable Gate Array) or an ASIC (Application-Specific Integrated Circuit). The hardware module can also comprise programmable logic or circuitry temporarily configured by software to perform certain operations. For example, the hardware module can comprise software executed by a general-purpose processor or other programmable processor. Once configured by such software, the hardware module becomes a particular machine (or a particular component of a machine) uniquely adapted to perform the configured functions and is no longer a general-purpose processor. It will be appreciated that the decision to implement the hardware module mechanically, in dedicated and permanently configured circuitry, or in temporarily configured circuitry (e.g., configured by software) can be made based on cost and time considerations.

[0058] Accordingly, the phrase "hardware module" should be understood to encompass a tangible entity that is physically configured to operate in a particular manner described herein or to perform a particular operation, a permanently configured entity (e.g., hardwired), or a temporarily configured entity (e.g., a programmed entity). As used herein, "hardware implementation module" refers to a hardware module. Considering embodiments in which a hardware module is temporarily configured (e.g., programmed), each of the hardware modules need not be configured or instantiated at any one instance in time. For example, if a hardware module consists of a general-purpose processor configured by software to become a special-purpose processor, the general-purpose processor may be configured at different times as each a different special-purpose processor (e.g., consisting of a different hardware module). The software may accordingly configure a particular processor or processors to, for example, configure a particular hardware module at one instance in time and a different hardware module at another instance in time.

[0059] The hardware module provides information to other hardware modules and is enabled to receive information from other hardware modules. Thus, the described hardware modules can be considered communicatively coupled. When multiple hardware modules are present simultaneously, communication can be achieved by signal transmission between two or more hardware modules or between two or more hardware modules (e.g., via appropriate circuits and buses). In embodiments where multiple hardware modules are configured or instantiated at different times, communication between such hardware modules can be achieved, for example, through the storage and retrieval of information in a memory structure accessed by the multiple hardware modules. For example, one hardware module is enabled to execute an operation and store the output of the operation in a communicatively coupled memory device. Subsequently, a further hardware module is enabled to access the memory device at a later time and retrieve and process the stored output. The hardware module can also initiate communication with an input device or an output device and is enabled to operate on a resource (e.g., a collection of information).

[0060] The various operations of the exemplary methods described herein can be at least partially enabled by one or more processors that are temporarily configured (e.g., by software) to perform the relevant operations or are permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors constitute processor-implemented modules that operate to perform one or more of the operations or functions described herein. As used herein, "processor-implemented module" refers to a hardware module implemented using one or more processors.

[0061] Similarly, the methods described herein may be at least partially processor-implemented, and a particular processor or processors are an example of hardware. For example, at least some of the operations of the method may be enabled to be performed by one or more processors or processor-implemented modules. Further, one or more processors may operate to support the execution of relevant operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as an example of a machine equipped with a processor), and these operations may be made accessible via a network (e.g., the Internet) through one or more appropriate interfaces (e.g., an application program interface (API)).

[0062] The execution of certain operations may exist not only within a single machine but also be distributed among processors already arranged across multiple machines. In some exemplary embodiments, the processor or processor-implemented modules may be enabled to be arranged in a single geographical location (e.g., a home environment, an office environment, or within a server farm). In other exemplary embodiments, the processor or processor-implemented modules are distributed across multiple geographical locations.

[0063] The modules, methods, applications, etc. described in connection with FIGS. 1-3B are implemented in the context of a machine and related software architecture in some embodiments. The following sections describe representative software architectures and machine (e.g., hardware) architectures suitable for use with the disclosed embodiments.

[0064] Software architecture is used in combination with hardware architecture to create devices and machines tailored to specific purposes. For example, a specific hardware architecture and a specific software architecture are combined to create mobile devices such as mobile phones and tablet devices. By slightly changing the hardware and software architectures, smart devices used in the "Internet of Things" may be created. In yet another combination, server computers used within cloud computing architectures are born. Those skilled in the art are enabled to facilitate understanding of how to implement the subject matter of the present invention in contexts different from the disclosure contained herein, and thus not all combinations of such software and hardware architectures are presented herein.

[0065] The described implementations of the subject matter can, as illustrated by way of example below, singly or in combination, comprise one or more features. Example (embodiment, instance) 1 is a method for dynamically adjusting the number of virtual machines as the number of virtual machines within a data plane. The method comprises the step of provisioning a plurality of the virtual machines within the data plane. The plurality of the virtual machines have a data plane proxy. The plurality of the virtual machines provide data routing for a first number of operational pods (operable pods, operational pods, deployable pods) as a first pod number within a deployment plane associated with the data plane. The method comprises the step of monitoring the status of the deployment plane. The status reflecting the deployment plane has a second pod number different from the first pod number of the operational pods. The method comprises the step of comparing the first pod number of the operational pods with the second pod number of the operational pods. The method comprises the step of dynamically adjusting the number of virtual machines within the data plane based on the result of the comparison between the first pod number and the second pod number of the operational pods.

[0066] Example 2. The deployment plane is equipped with a traffic control device. The traffic control device is configured to monitor the status of the deployment plane and compare the first pod count of the operating pods with the second pod count of the operating pods, using the method described in Example 1.

[0067] Example 3. The traffic control device is configured to issue a virtual machine API to a cloud-based virtual machine application programming interface (API) based on a comparison between the first pod count and the second pod count of the operating pods, using the method described in Example 1 or 2.

[0068] Example 4. The second pod count of the operating pods is less than the first pod count of the operating pods. The virtual machine API reduces the number of virtual machines in the data plane. using the method described in any one of Examples 1 to 3.

[0069] Example 5. The second pod count of the operating pods is zero. The virtual machine API reduces the number of virtual machines in the data plane to zero. using the method described in any one of Examples 1 to 4.

[0070] Example 6. The second pod count of the operating pods is greater than the first pod count of the operating pods. The virtual machine API increases the number of virtual machines in the data plane. using the method described in any one of Examples 1 to 5.

[0071] Example 7. The method according to any one of Examples 1 to 6. The method includes a step of monitoring a second status of a deployment plane after dynamically adjusting the number of virtual machines in the data plane. The second status reflecting the deployment plane has a third pod number different from the second pod number of the operation pod. The method includes a step of comparing the second pod number of the operation pod with the third pod number of the operation pod, and dynamically adjusting the number of virtual machines in the data plane based on the comparison between the second pod number of the operation pod and the third pod number of the operation pod so that the number of virtual machines is adjusted for the second time (second time) after provisioning.

[0072] Example 8. A system, the system includes at least one processor and at least one memory including instructions. When executed by at least one of the processors, the instructions are configured to cause at least one of the processors to perform an operation. The operation includes a step of provisioning a plurality of virtual machines to a data plane. The plurality of virtual machines have a data plane proxy. The plurality of virtual machines provide data routing for an operation pod having a first pod number as a first number in a deployment plane associated with the data plane. The operation includes a step of monitoring a status of the deployment plane. The status reflecting the deployment plane has a second pod number different from the first pod number of the operation pod. The operation includes a step of comparing the first pod number of the operation pod with the second pod number of the operation pod, and dynamically adjusting the number of virtual machines in the data plane based on a result of the comparison between the first pod number of the operation pod and the second pod number of the operation pod.

[0073] Example 9. The deployment plane includes a traffic control device. The traffic control device is configured to monitor the status of the deployment plane and compare the first pod number of the operation pod with the second pod number of the operation pod. The system described in Example 8.

[0074] Example 10. The traffic control device is configured to issue a virtual machine application programming interface (API) to a cloud-based virtual machine API based on a comparison between a first pod number of the operation pod and a second pod number of the operation pod. The system described in Example 8 or 9.

[0075] Example 11. The second pod number of the operation pod is less than the first pod number of the operation pod. The virtual machine API reduces the number of virtual machines in the data plane. The system described in any one of Examples 8 to 10.

[0076] Example 12. The second pod number of the operation pod is greater than the first pod number of the operation pod. The virtual machine API increases the number of virtual machines in the data plane. The system described in any one of Examples 8 to 11.

[0077] Example 13. The system is the one described in any one of Examples 8 to 12. The instruction causes the device to execute an operation. The operation includes a step of monitoring a second status of the deployment plane after dynamically adjusting the number of virtual machines in the data plane. The second status reflecting the deployment plane has a third pod number different from the second pod number of the operation pod. The operation includes a step of comparing the second pod number of the operation pod with the third pod number of the operation pod, and a step of dynamically adjusting the number of virtual machines in the data plane based on a comparison between the second pod number of the operation pod and the third pod number of the operation pod so that the number of virtual machines is adjusted for the second time after provisioning.

[0078] Example 14. A non-transitory machine-readable medium in which instructions are embodied on a non-transitory machine-readable medium. When the instructions are executed by a processor of a machine, they cause operations to be performed. The operations include the following steps. The operations include provisioning a plurality of virtual machines in a data plane. The plurality of virtual machines have a data plane proxy. The plurality of virtual machines provide data routing for a first number of operational pods, as a first number, within a deployment plane associated with the data plane. The operations include monitoring the status of the deployment plane. The status reflecting the deployment plane has a second number of pods different from the first number of operational pods. The operations include comparing the first number of operational pods with the second number of operational pods and dynamically adjusting the number of virtual machines within the data plane based on the result of the comparison between the first number of operational pods and the second number of operational pods.

[0079] Example 15. The deployment plane includes a traffic control device. The traffic control device is configured to monitor the status of the deployment plane and compare the first number of operational pods with the second number of operational pods. The non-transitory machine-readable medium according to Example 14.

[0080] Example 16. The traffic control device is configured to issue a virtual machine API to a cloud-based virtual machine application programming interface (API) based on a comparison between the first number of operational pods and the second number of operational pods. The non-transitory machine-readable medium according to Example 14 or 15.

[0081] Example 17. The second number of operational pods is less than the first number of operational pods. The virtual machine API reduces the number of virtual machines within the data plane. The non-transitory machine-readable medium according to any one of Examples 14 to 16.

[0082] Example 18. The number of second pods of the operation pod is zero. The virtual machine API reduces the number of virtual machines in the data plane to zero. The non-transitory machine-readable medium according to any one of Examples 14 to 17.

[0083] Example 19. The number of second pods of the operation pod is greater than the number of first pods of the operation pod. The virtual machine API increases the number of virtual machines in the data plane. The non-transitory machine-readable medium according to any one of Examples 14 to 18.

[0084] Example 20. It is the non-transitory machine-readable medium according to any one of Examples 14 to 19. The operation further includes a step of monitoring the second status of the deployment plane after dynamically adjusting the number of virtual machines in the data plane. The second status reflecting the deployment plane has a third pod number different from the number of second pods of the operation pod. The operation further includes a step of comparing the number of second pods of the operation pod with the number of third pods of the operation pod. The operation dynamically adjusts the number of virtual machines in the data plane based on a comparison between the number of second pods of the operation pod and the number of third pods of the operation pod such that the number of virtual machines is adjusted for the second time after provisioning.

[0085] FIG. 4 is a block diagram (400) showing a software architecture 402, which can be installed on any one or more of the devices described above. FIG. 4 is merely a non-limiting example of a software architecture, and it will be understood that many other architectures may be implemented to facilitate the functions described herein. The software architecture 402 may be implemented by hardware such as the machine 500 of FIG. 5, which includes a processor 502, memories (504 and 506), and I / O components (510-514). In this example, the software architecture 402 can be conceptualized as a stack of layers where each layer can provide a specific function. For example, the software architecture 402 includes layers such as an operating system 404, a library 406, a framework 408, and an application 410. In operation, the application 410, according to some implementations, calls an application programming interface (API) call (412) through the software stack and receives a message 414 in response to the API call 412.

[0086] In various implementations, the operating system 404 manages hardware resources and provides common services. The operating system 404 includes, for example, a kernel 420, services 422, and drivers 424. The kernel 420 functions as an abstraction layer between the hardware and other software layers in some implementations. For example, the kernel 420 provides, among other functions, memory management, processor management (e.g., scheduling), component management, networking, and security configuration. The services 422 are enabled to provide other common services to other software layers. The drivers 424 may be responsible for controlling or interfacing with the underlying hardware. For example, the drivers 424 can include a display driver, a camera driver, a Bluetooth® driver, a flash memory driver, a serial communication driver (e.g., a Universal Serial Bus (USB) driver), a Wi-Fi® driver, an audio driver, a power management driver, and the like.

[0087] In some implementations, library 406 provides a low-level common infrastructure that can be utilized by application 410. Library 406 can include a system library 430 (e.g., the C standard library) that provides functions such as memory allocation functions, string manipulation functions, mathematical functions, etc. Further, library 406 can include a media library (e.g., a library that supports the presentation and manipulation of various media formats such as Moving Picture Experts Group-4 (MPEG4), Advanced Video Coding (H.264 or AVC), Moving Picture Experts Group Layer-3 (MP3), Advanced Audio Coding (AAC), Adaptive Multi-Rate (AMR) audio codec, Joint Photographic Experts Group (JPEG or JPG), or Portable Network Graphics (PNG)), a graphics library (e.g., the OpenGL framework used for 2D and 3D rendering in a graphic context on a display), a database library (e.g., SQLite that provides various relational database functions), a web library (e.g., WebKit that provides web browsing functions), etc. Library 406 can also include a wide variety of other libraries 434 to provide many other APIs to application 410.

[0088] According to some implementations, framework 408 provides a high-level common infrastructure that can be utilized by application 410. For example, framework 408 provides various graphic user interface (GUI) functions, high-level resource management, high-level location services, etc. Framework 408 may provide a broad spectrum of other APIs that can be utilized by application 410, some of which may be specific to a particular operating system or platform.

[0089] In one example, the application 410 has a wide variety of other applications such as a home application 450, a contacts application 452, a browser application 454, an e - book reader application 456, a location application 458, a media application 460, a messaging application 462, a game application 464, and a third - party application 466. According to some examples, the application 410 is a program that executes functions defined by the program. One or more of the application 410 structured in various ways, such as an object - oriented programming language (e.g., Objective - C, Java®, or C++) or a procedural programming language (e.g., C or assembly language), can be created by adopting various programming languages. In a specific example, the third - party application 466 (e.g., an application developed using an Android® or iOS® software development kit (SDK) by an entity other than the vendor of a specific platform) may be mobile software that runs on a mobile operating system such as iOS®, Android®, Windows® Phone, or other mobile operating systems. In this example, the third - party application 466 is enabled to call an API call 412 provided by the mobile operating system (e.g., the operating system 404) to facilitate the functions described herein.

[0090] Certain embodiments are described herein as including logic or a number of components, modules, or mechanisms. A module can comprise either a software module (e.g., code embodied in (1) a non-transitory machine-readable medium or (2) a transmission signal) or a hardware-implemented module. A hardware-implemented module is a tangible unit capable of performing certain operations and is configured or arranged in a particular manner. In an example, one or more computer systems (e.g., a stand-alone, client, or server computer system) or one or more processors can be configured by software (e.g., an application or an application portion) as a hardware-implemented module that operates to perform certain operations as described herein.

[0091] In various examples, a hardware-implemented module may be implemented mechanically or electronically. For example, a hardware-implemented module can include dedicated circuitry or logic that is permanently configured (e.g., as a dedicated processor such as a field programmable gate array (FPGA) or an application specific integrated circuit (ASIC)) to perform certain operations. A hardware-implemented module can also include programmable logic or circuitry that is temporarily configured by software to perform certain operations (e.g., included within a general purpose processor or other programmable processor). It will be appreciated that the decision to implement a hardware-implemented module mechanically in a dedicated and permanently configured circuit or in a temporarily configured circuit (e.g., configured by software) may be made based on cost and time considerations.

[0092] Accordingly, the term "hardware implementation module" should be understood to include tangible entities that are physically constructed, permanently configured (e.g., hardwired), or configured temporarily (temporally) or transitively (transitorily) (e.g., programmed) to operate in a particular manner described herein and / or to perform particular operations. Considering an example where a hardware implementation module is configured temporarily (e.g., programmed), each of the hardware implementation modules need not be configured or instantiated at any one instance in time. For example, if a hardware implementation module comprises a general-purpose processor configured using software, the general-purpose processor may be configured as a different hardware implementation module at different times. Accordingly, software is enabled to configure the processor, for example, to configure a particular hardware implementation module at one instance in time and a different hardware implementation module at a different instance in time.

[0093] The hardware implementation modules are enabled to provide information to other hardware implementation modules or receive information from other hardware implementation modules. Thus, the described hardware implementation modules can be regarded as communicatively coupled. When multiple such hardware implementation modules exist simultaneously, communication can be achieved through signal transmission (e.g., via appropriate circuits and buses) connecting the hardware implementation modules. In an example where multiple hardware implementation modules are configured or instantiated at different times, communication between such hardware implementation modules may be achieved, for example, through storage and retrieval of information in a memory structure accessible to the multiple hardware implementation modules. For example, a certain hardware implementation module is enabled to perform a certain operation and store the output of the operation in a communicatively coupled memory device. Subsequently, a further hardware implementation module is enabled to access the memory device at a later time and retrieve and process the stored output. The hardware implementation modules are also enabled to initiate communication with input devices or output devices and operate on resources (e.g., a collection of information).

[0094] The various operations of the exemplary methods described herein may be at least partially executed by one or more processors temporarily configured (e.g., by software) to perform the relevant operations or permanently configured to perform the relevant operations. Whether temporarily or permanently configured, such processors are enabled to configure processor implementation modules that operate to perform one or more operations or functions. The modules referred to herein may, in some examples, include processor implementation modules.

[0095] Similarly, the methods described herein may be at least partially processor-implemented. For example, at least some of the operations of the method may be performed by one or more processors or processor-implemented modules. Execution of particular operations may be distributed among one or more processors, or may be located within a single machine as well as across multiple machines. In some examples, one or more processors may be located in a single location (e.g., within a home environment, an office environment, or as a server farm), while in other examples, the processors may be distributed across a number of locations.

[0096] One or more processors may also be enabled to operate to support the execution of relevant operations in a "cloud computing" environment or as "software as a service" (SaaS). For example, at least some of the operations may be performed by a group of computers (as examples of machines equipped with processors), and these operations may be made accessible via a network (e.g., the Internet) through one or more suitable interfaces (e.g., application program interfaces (APIs)).

[0097] Embodiments may be implemented in digital electronic circuitry, or in computer hardware, firmware, software, or in combinations thereof. Embodiments may be implemented using a computer program product, i.e., a computer program tangibly embodied in an information carrier, e.g., in a machine-readable medium, for execution by, or to control the operation of, a data processing apparatus, e.g., a programmable processor, a computer, or multiple computers.

[0098] A computer program can be described in any form of programming language, including compiled or interpreted languages, and can be deployed in any form, either as a stand-alone program or as a module, subroutine, or other unit suitable for use in a computing environment. The computer program can be executed on one computer, on multiple computers, at one site, or distributed and executed on multiple sites, and can be deployed to be interconnected by a communication network.

[0099] A computing system can include a client and a server. The client and the server are generally remote from each other and usually interact via a communication network. The relationship between the client and the server is created by computer programs executed on each computer and they have a client-server relationship with each other. In an example of deploying a programmable computing system, it will be understood that it is necessary to consider both the hardware architecture and the software architecture. Specifically, it will be understood that the choice of implementing a particular function in either permanently configured hardware (e.g., ASIC), temporarily configured hardware (e.g., a combination of software and a programmable processor), or a combination of permanently configured hardware and temporarily configured hardware can be a design choice. Below, various examples show the hardware (e.g., machine) and software architectures that can be deployed.

[0100] FIG. 5 is a block diagram of a machine (apparatus) capable of executing instructions for causing a machine to execute any one or more of the methodologies discussed herein. In one example, the machine may be any of the devices described above. Alternatively, the machine may operate as a stand-alone device or may be connected (e.g., networked) to other machines. In a networked deployment, the machine may operate in the capacity of a server or a client machine in a server-client network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. The machine may be a personal computer (PC), a tablet PC, a set-top box (STB), a personal digital assistant (PDA), a cellular telephone, a web appliance, a network router, a switch, a bridge, or any machine capable of executing instructions (sequential or otherwise) that specify actions to be taken by that machine. Further, although only a single machine is illustrated, the term “machine” shall also be taken to include any collection of machines that individually or jointly execute a set (or multiple sets) of instructions to perform any one or more of the methodologies discussed herein.

[0101] Machine 500, which may be a computer system, includes a processor 502 (e.g., a central processing unit (CPU), a graphics processing unit (GPU), or both), main memory 504, and static memory 506, which communicate with each other via bus 508. Machine 500 may further include a video display unit 510 (e.g., a liquid crystal display (LCD) or a cathode ray tube (CRT)). Machine 500 may also include an alphanumeric input device 512 (e.g., a keyboard), a user interface (UI) navigation device (cursor control device) 514 (e.g., a mouse), a disk drive unit 516, a signal generation device 518 (e.g., a speaker), and a network interface device 520.

[0102] The disk drive unit 516 includes a machine-readable medium 522 in which one or more sets of instructions and data structures (e.g., software) 524 are stored, which are implemented or utilized by any one or more of the methodologies or functions described herein. The instructions 524 may also be present, in whole or at least in part, in the main memory 504 and / or in the processor 502 during its execution by the machine 500, and the main memory 504 and the processor 502 also constitute a machine-readable medium. The instructions 524 may also be present in the static memory 506.

[0103] Although the machine-readable medium 522 is exemplarily shown as a single medium, the term "machine-readable medium" can include a single medium or multiple media (e.g., a centralized or distributed database, and / or associated caches and servers) that store one or more instructions or data instructions (524). Also, the term "machine-readable medium" is enabled to store, encode, or carry instructions 524 that cause a machine to execute any one or more of the methodologies of the present invention, or to be utilized by such instructions 524, or to store, encode, or carry data structures related to such instructions 524, and is assumed to include any tangible medium. The term "machine-readable medium" accordingly includes, but is not limited to, solid-state memory, optical media, and magnetic media. Specific examples of machine-readable media include, by way of example, semiconductor memory devices such as erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory devices, non-volatile memory including internal hard disks and removable disks, magneto-optical disks, and CD-ROM and DVD-ROM disks.

[0104] Command 524 may further be transmitted or received via communication network 526 using a transmission medium. Command 524 may be transmitted using network interface device 520 and any one of a number of well-known transfer protocols (e.g., HTTP). Examples of communication networks include local area networks (“LANs”), wide area networks (“WANs”), the Internet, cellular phone networks, plain old telephone service (POTS) networks, and wireless data networks (e.g., Wi-Fi® and Wi-Max networks). The term “transmission medium” is intended to include any intangible medium that is capable of storing, encoding, or carrying command 524 for execution by a machine, as well as digital or analog communication signals, or other intangible media for facilitating communication of such software.

[0105] Although the embodiments have been described with reference to specific examples, it will be apparent that various modifications and changes can be made to these embodiments without departing from the broad spirit and scope of the invention. Accordingly, the specification and drawings are to be regarded in an illustrative rather than a restrictive sense. The accompanying drawings, which form a part of this specification, illustrate specific examples in which the subject matter may be practiced for purposes of illustration and not of limitation. The illustrated embodiments are described in sufficient detail to enable those skilled in the art to practice the teachings disclosed herein. Other embodiments are utilized and can be derived therefrom without departing from the scope of this disclosure so that structural and logical substitutions and changes can be made. Accordingly, this detailed description should not be construed in a limiting sense, and the scope of the various embodiments is defined only by the appended claims, along with the full scope of equivalents to which such claims are entitled.

[0106] Such embodiments of the subject matter of the present invention may, for convenience only, be referred to individually and / or collectively herein by the term "the present invention," and there is no intention to voluntarily limit the scope of this application to any single invention or inventive concept if more than one invention is in fact disclosed. Accordingly, while specific embodiments have been illustrated and described herein, it should be understood that any arrangement calculated to achieve the same purpose may be substituted for the specific embodiments shown. This disclosure is intended to cover any adaptations or variations of the various embodiments. Combinations of the above embodiments, as well as other embodiments not specifically described herein, will be apparent to those of ordinary skill in the art upon review of the above description.

[0107] The abstract of the disclosure is provided in accordance with 37 C.F.R. § 1.72(b), which requires an abstract that will enable the reader to quickly ascertain the nature of the technical disclosure. This abstract is submitted with the understanding that it will not be used to limit or interpret the scope or meaning of the claims. Further, as will be apparent from the foregoing detailed description, various features are grouped together in one embodiment for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the embodiments set forth in the claims require more features than are expressly recited in each claim. Rather, as the following claims reflect, the inventive subject matter lies in less than all of the features of a single disclosed embodiment. Accordingly, the following claims are hereby incorporated herein in their entirety, with each claim standing on its own as a separate embodiment.

[0108] <Executable Instructions and Machine-Readable Media> Various memories and / or storage devices are enabled to store one or more sets of instructions and data structures (e.g., software) that are implemented by, or utilized by, any one or more of the methodologies or functions described herein. When these instructions are executed by one or more processors, they cause various operations for implementing the disclosed embodiments.

[0109] As used herein, the terms "machine storage medium", "device storage medium", and "computer storage medium" mean the same and may be used interchangeably in the present disclosure. These terms refer to single or multiple storage devices and / or media (e.g., centralized or distributed databases, and / or associated caches and servers) that store executable instructions and / or data. Thus, the term includes, but is not limited to, solid state memory, as well as optical and magnetic media, including memory internal or external to a processor. Specific examples of machine storage media, computer storage media, and / or device storage media include, for example, semiconductor memory devices such as erasable programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), FPGA, flash memory devices, magnetic disks such as internal hard disks and removable disks, magneto-optical disks, non-volatile memories such as CD-ROM and DVD-ROM disks. The terms "machine storage medium", "computer storage medium", and "device storage medium" specifically exclude carrier waves, modulated data signals, and other media. At least some of these media are covered by the term "signal medium" described below.

[0110] <Transmission medium> In various examples, one or more portions of a network, such as a network-based system, may be an ad hoc network, an intranet, an extranet, a VPN, a LAN, a WLAN, a WAN, a WWAN, a MAN, the Internet, a portion of the Internet, a portion of the PSTN, a POTS (plain old telephone service) network, a cellular telephone network, a wireless network, a Wi-Fi (registered trademark) network, another type of network, or a combination of two or more such networks. Further to explain, the network or a portion of the network may include a wireless or cellular network, and the connection may be a code division multiple access (CDMA) connection, a global system for mobile communications (GSM (registered trademark)) connection for mobile communications, or another type of cellular or wireless connection. In this example, the coupling may implement any of various types of data transfer technologies, such as single carrier radio transmission technology (1xRTT), EVDO (Evolution-Data Optimized) technology, GPRS (General Packet Radio Service) technology, EDGE (Enhanced Data rates for GSM (registered trademark) Evolution) technology, 3G of the 3rd Generation Partnership Project (3GPP (registered trademark)), a 4th generation wireless (4G) network, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) network, etc., a 4th generation wireless (4G) network that is enabled to implement any of various types of data transfer technologies, Universal Mobile Telecommunications System (UMTS), High Speed Packet Access (HSPA), Worldwide Interoperability for Microwave Access (WiMAX), Long Term Evolution (LTE) standard, those defined by various other standardization bodies, other long-distance protocols, other data transfer technologies.

[0111] Commands may be transmitted or received over a network by using a transmission medium via a network interface device and by using any one of a number of well-known transfer protocols (e.g., Hypertext Transfer Protocol (HTTP)). Similarly, commands may be transmitted or received using a transmission medium via a coupling to a device (e.g., a peer-to-peer coupling). The terms “transmission medium” and “signal medium” mean the same thing and may be used interchangeably in this disclosure. The terms “transmission medium” and “signal medium” are not only meant to include any intangible medium capable of storing, encoding, or carrying instructions for machine execution, but also include digital or analog communication signals, or other intangible media for facilitating such software communication. Thus, the terms “transmission medium” and “signal medium” are meant to include any form of modulated data signal, carrier wave, etc. A “modulated data signal” means a signal having one or more of its characteristics set or changed in such a manner as to encode information in the signal.

[0112] <Computer-readable medium> The terms “machine-readable medium,” “computer-readable medium,” and “device-readable medium” mean the same thing and may be used interchangeably in this disclosure. These terms are defined to include both machine storage media and transmission media. Thus, this term includes both storage devices / media and carrier waves / modulated data signals.

Claims

1. A method for dynamically adjusting the number of virtual machines as the number of virtual machines in a data plane, wherein the method is A step of provisioning a plurality of virtual machines in the data plane, wherein the plurality of virtual machines have a data plane proxy, and the plurality of virtual machines provide data routing for a first number of operational pods as a first number in a deployment plane associated with the data plane, A step of monitoring the status of the deployment plane, wherein the status reflects a change in the number of operational pods operating within the deployment plane from the first number of pods to the second number of pods, and the second number of pods is different from the first number of pods. In order to determine the change in the number of operational pods of the operational pods operating within the aforementioned deployment plane, the process involves comparing the first number of operational pods with the second number of operational pods, A step of dynamically adjusting the number of virtual machines in the data plane based on the change in the number of operational pods operating within the deployment plane, wherein the number of virtual machines in the data plane changes in accordance with the value of the number of operational pods operating within the deployment plane, such that the number of virtual machines in the data plane decreases when the number of operational pods decreases, while the number of virtual machines in the data plane increases when the number of operational pods increases. A method that includes [the following features].

2. The aforementioned deployment plane is equipped with a traffic control device, The traffic control device is configured to monitor the status of the deployment plane and to compare the number of first pods with the number of second pods. The method according to claim 1.

3. The traffic control device is configured to issue a virtual machine application programming interface (API) to a cloud-based virtual machine API based on a comparison between the number of first pods in the operational pod and the number of second pods in the operational pod. The method according to claim 2.

4. The number of the second pods in the operating pod is zero. The virtual machine API reduces the number of virtual machines in the data plane to zero. The method according to claim 3.

5. The above method further, A step of monitoring the second status of the deployment plane after dynamically adjusting the number of virtual machines in the data plane, wherein the second status reflecting the deployment plane has a third number of pods that is different from the second number of operational pods, A step of comparing the number of second pods in the operating pod with the number of third pods in the operating pod, A step of dynamically adjusting the number of virtual machines in the data plane based on a comparison between the number of second pods in the operational pod and the number of third pods in the operational pod, so that the number of virtual machines is adjusted a second time after provisioning. The method according to claim 1, comprising:

6. A system, wherein the system is At least one processor, A memory containing instructions, The system is equipped with such that, when the instruction is executed by at least one of the processors, it causes at least one of the processors to perform an operation, and the operation is A step of provisioning multiple virtual machines into a data plane, wherein the multiple virtual machines have a data plane proxy, and the multiple virtual machines provide data routing for a first number of operational pods as a first number in a deployment plane associated with the data plane, A step of monitoring the status of the deployment plane, wherein the status reflects a change in the number of operational pods operating within the deployment plane from the first number of pods to the second number of pods, and the second number of pods is different from the first number of operational pods. In order to determine the change in the number of operational pods operating within the deployment plane, the process involves comparing the number of first operational pods with the number of second operational pods. A step of dynamically adjusting the number of virtual machines in the data plane based on the change in the number of operational pods operating in the deployment plane, wherein the number of virtual machines in the data plane changes in accordance with the value of the number of operational pods operating in the deployment plane, such that the number of virtual machines in the data plane decreases when the number of operational pods decreases, and increases when the number of operational pods increases. A system equipped with these features.

7. The aforementioned deployment plane is equipped with a traffic control device, The traffic control device is configured to monitor the status of the deployment plane and to compare the number of first pods in the operational pod with the number of second pods in the operational pod. The system according to claim 6.

8. The traffic control device is configured to issue a virtual machine application programming interface (API) to a cloud-based virtual machine API based on a comparison between the number of first pods and the number of second pods in the operational pod. The system according to claim 7.

9. The aforementioned instruction causes the device to perform an action, and the action is, A step of monitoring the second status of the deployment plane after dynamically adjusting the number of virtual machines in the data plane, wherein the second status reflecting the deployment plane has a third number of pods that is different from the second number of operational pods, A step of comparing the number of second pods in the operating pod with the number of third pods in the operating pod, A step of dynamically adjusting the number of virtual machines in the data plane based on a comparison between the number of second pods and the number of third pods in the operational pod, so that the number of virtual machines is adjusted a second time after provisioning, The system according to claim 6, comprising:

10. A computer program that is executed by a processor provided by a computer and is configured to cause the processor to perform an operation, wherein the operation is: A step of provisioning multiple virtual machines into a data plane, wherein the multiple virtual machines have a data plane proxy, and the multiple virtual machines provide data routing for a first number of operational pods as a first number in a deployment plane associated with the data plane, A step of monitoring the status of the deployment plane, wherein the status reflects a change in the number of operational pods operating within the deployment plane from the first number of pods to the second number of pods, and the second number of pods is different from the first number of pods. In order to determine the change in the number of operational pods of the operational pods operating within the aforementioned deployment plane, the process involves comparing the first number of operational pods with the second number of operational pods, A step of dynamically adjusting the number of virtual machines in the data plane based on the change in the number of operational pods operating within the deployment plane, wherein the number of virtual machines in the data plane changes in accordance with the value of the number of operational pods operating within the deployment plane, such that the number of virtual machines in the data plane decreases when the number of operational pods decreases, while the number of virtual machines in the data plane increases when the number of operational pods increases. A computer program that possesses these features.

11. The aforementioned deployment plane is equipped with a traffic control device, The traffic control device is configured to monitor the status of the deployment plane and to compare the number of first pods in the operational pod with the number of second pods in the operational pod. The computer program according to claim 10.

12. The traffic control device is configured to issue a virtual machine application programming interface (API) to a cloud-based virtual machine API based on a comparison between the number of first pods in the operational pod and the number of second pods in the operational pod. The computer program according to claim 11.

13. The number of the second pods in the operating pod is zero. The virtual machine API reduces the number of virtual machines in the data plane to zero. The computer program according to claim 12.

14. The aforementioned operation further, The steps include: dynamically adjusting the number of virtual machines in the data plane, and then monitoring the second status of the deployment plane, wherein the second status, which reflects the deployment plane, has a third number of pods that is different from the second number of operational pods; A step of comparing the number of second pods in the operating pod with the number of third pods in the operating pod, A step of dynamically adjusting the number of virtual machines in the data plane based on a comparison between the number of second pods and the number of third pods in the operational pod, so that the number of virtual machines is adjusted a second time after provisioning, The computer program according to claim 10, comprising:

Images