Container deployment based on environment requirements

Abstract

A method for distributing microservice containers for services across multiple computing environments may include receiving a service built from multiple containerized microservices to be deployed in a container platform. The container platform may include multiple computing environments. The method may also include receiving deployment criteria for deploying the service in the container platform; accessing characteristics of the multiple computing environments; and deploying the multiple containerized microservices across the multiple computing environments based on the deployment criteria and the characteristics of the multiple computing environments.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Provisional Application No. 62 / 566,351, filed on September 30, 2017, which is incorporated herein by reference. This application is also related to the following commonly assigned applications filed on the same date as this application, each of which is also incorporated herein by reference:

[0003] U.S. Patent Application No. __ / __, __, filed on September __, 2018, entitled “API REGISTRY IN A CONTAINER PLATFORM FOR AUTOMATICALLY GENERATING CLIENT CODE LIBRARIES” (Attorney Docket No. 088325-1090745);

[0004] U.S. Patent Application No. __ / __, __, filed on September __, 2018, entitled “API REGISTRY IN A CONTAINER PLATFORM PROVIDING PROPERTY-BASED API FUNCTIONALITY” (Attorney Docket No. 088325-1090746);

[0005] U.S. Patent Application No. __ / __, __, filed on September __, 2018, entitled “DYNAMIC NODEREBALANCING BETWEEN CONTAINER PLATFORMS” (Attorney Docket No. 088325-1090747);

[0006] U.S. Patent Application No. __ / __, __, filed on September __, 2018, entitled “REAL-TIME DEBUGGING INSTANCES IN A DEPLOYED CONTAINER PLATFORM” (Attorney Docket No. 088325-1090753); Background Art

[0007] In general, any form of container represents a standardized way of packaging and interacting with information. Containers can be isolated from each other and can be used in parallel without the risk of cross contamination. In the modern software world, the word "container" has a specific meaning. Software containers, such as A container is a software construct that logically encapsulates and defines a piece of software. The most common types of software to be encapsulated in a container are applications, services, or microservices. Modern containers also include all the software support required for the application / service to operate, such as an operating system, libraries, storage volumes, configuration files, application binaries, and other parts of the technology stack that will be found in a typical computing environment. This container environment can then be used to create multiple containers, each running its own service in any environment. Containers can be deployed in production data centers, on-premises data centers, cloud computing platforms, and more without any changes. Spinning up a container on the cloud is the same as spinning up a container on a local workstation.

[0008] Modern service-oriented architectures and cloud computing platforms break down large tasks into many small, specific tasks. Containers can be instantiated to focus on individual specific tasks, and then multiple containers can work together to implement complex applications. This can be called a microservice architecture, and each container can use different versions of programming languages ​​and libraries that can be upgraded independently. The isolated nature of the processes within the containers allows them to be upgraded or replaced with little work or risk compared to changes that would be made to the larger, more monolithic architecture. Although virtual machines can be used to run container platforms, container platforms are much more efficient than traditional virtual machines in running this microservice architecture. Summary of the invention

[0009] In some embodiments, a method for allocating microservice containers for services across multiple computing environments may include receiving a service built from multiple containerized microservices to be deployed in a container platform. The container platform may include multiple computing environments. The method may also include receiving deployment criteria for deploying the service in the container platform; accessing characteristics of the multiple computing environments; and deploying the multiple containerized microservices across the multiple computing environments based on the deployment criteria and the characteristics of the multiple computing environments.

[0010] In some embodiments, a non-transitory computer-readable medium may include instructions that, when executed by one or more processors, cause the one or more processors to perform operations including receiving a service built from a plurality of containerized microservices to be deployed in a container platform. The container platform may include a plurality of computing environments. The operations may also include receiving deployment criteria for deploying services in the container platform; accessing characteristics of the plurality of computing environments; and deploying the plurality of containerized microservices across the plurality of computing environments based on the deployment criteria and the characteristics of the plurality of computing environments.

[0011] In some embodiments, a system may include one or more processors and one or more memory devices including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations including receiving a service built from a plurality of containerized microservices to be deployed in a container platform. The container platform may include a plurality of computing environments. The operations may also include deployment criteria for deploying services in the container platform; accessing characteristics of the plurality of computing environments; and deploying the plurality of containerized microservices across the plurality of computing environments based on the deployment criteria and the characteristics of the plurality of computing environments.

[0012] In any embodiment, any one or all of the following features may be included in any combination and without limitation. Multiple computing environments may include cloud computing environments. Multiple computing environments may include on-premises computing environments. At least one of the multiple containerized microservices may include multiple containers in a single container pod. At least one of the multiple containerized microservices may include a single container that includes multiple microservices in a single container pod. Deployment criteria may include an indication that service deployment should be optimized for security. Deployment criteria may include an indication that service deployment should be optimized for availability. Deployment criteria may include an indication that service deployment should be optimized for cost. Deployment criteria may include an indication that service deployment should be optimized for latency. Deployment criteria may include an indication that service deployment should be optimized for co-location of containerized microservices. Each of the multiple containerized microservices may include attributes corresponding to the deployment criteria. The values ​​of the microservice attributes may match the characteristics of the multiple computing environments. Multiple containerized microservices may be deployed by a container platform scheduler. Multiple containerized microservices may be deployed by an API registrar. The API registrar may be deployed as a service encapsulated in a container in a container environment. The API registry can be available for services under development in an integrated development environment (IDE) and services already deployed in a container environment. The API registry can map service endpoints for multiple container pods to one or more API functions. The API registry can automatically generate a client library for calling a service to call the service. BRIEF DESCRIPTION OF THE DRAWINGS

[0013] A further understanding of the nature and advantages of the present invention may be achieved by reference to the remainder of this specification and the drawings, wherein like reference numerals are used throughout the several drawings to refer to like parts. In some cases, a sub-label is associated with a reference numeral to denote one of a plurality of similar parts. When reference is made to a reference numeral without specifying an existing sub-label, it is intended to refer to all such plurality of similar parts.

[0014] Figure 1The software structure and logical arrangement of a development and runtime environment for services in a container platform according to some embodiments are illustrated.

[0015] Figure 2 A special purpose computer hardware system specifically designed to run the embodiments described herein is illustrated.

[0016] Figure 3 Illustrated is a data organization that may be specific to a container platform used by some of the embodiments described herein.

[0017] Figure 4 Illustrated is an API registrar that may be deployed to an IDE and a production / runtime environment according to some embodiments.

[0018] Figure 5 Deployment of an API registrar for use with a container platform at runtime is illustrated in accordance with some embodiments.

[0019] Fig. 6A A flow chart of a method for deploying an API registrar according to some embodiments is illustrated.

[0020] Figure 6B The diagram illustrates the use of Fig. 6A The software structure of the container platform when deploying the API registrar is shown in the flowchart.

[0021] Fig. 7A Illustrated is a flow diagram of a method for registering a service with an API registrar according to some embodiments.

[0022] Figure 7B A hardware / software diagram illustrating steps for registering an API with an API registrar according to some embodiments.

[0023] Figure 8 Illustrated are examples of a graphical interface and a command line interface for browsing and selecting an API to register with an API registrar according to some embodiments.

[0024] Fig. 9 Illustrated is a flow diagram of a method for using services registered with an API registrar and their corresponding functions according to some embodiments.

[0025] Fig.10 Illustrate how the API Registrar may receive selections through the graphical interface of the CreateUser() function.

[0026] Fig.11 Illustrated is an example of a client library automatically generated for a service by an API registrar in accordance with some embodiments.

[0027] Fig.12An embodiment of a client library that accommodates dynamic binding between service endpoints and API functions is illustrated in accordance with some embodiments.

[0028] Fig.13 An embodiment of a client library that can marshal additional data to complete an input data set for a service call is illustrated in accordance with some embodiments.

[0029] Fig.14 Illustrated is a client library that can handle retries when calling a service according to some embodiments.

[0030] Fig.15A A method of providing API properties to an API registrar according to some embodiments is illustrated.

[0031] Fig. 15B A hardware / software diagram illustrating how a service may provide API properties to an API registrar according to some embodiments.

[0032] Fig.16 Illustrated is a hardware / software diagram in which an API registrar uses features to deploy services with high availability according to some embodiments.

[0033] Fig.17 Illustrated is a hardware / software diagram that illustrates the feature of enforcing end-to-end encryption through an API registrar in accordance with some embodiments.

[0034] Fig.18 Illustrated are features of an API registrar for implementing usage logging for service 1808 in accordance with some embodiments.

[0035] Fig.19 Illustrated is a hardware / software diagram that may enforce characteristics of an authentication protocol on a service in accordance with some embodiments.

[0036] Fig. 20 Illustrated is a hardware / software schematic for enabling features of runtime instantiation of services in accordance with some embodiments.

[0037] Fig.21 Illustrated is a hardware / software schematic that implements the features of rate limiting functionality for a service in accordance with some embodiments.

[0038] Fig. 22 Illustrated is an example of a service built from multiple microservices in accordance with some embodiments.

[0039] Fig.23 A deployment environment for services according to some embodiments is illustrated.

[0040] Fig.24 A flow diagram of a method for optimizing service deployment across multiple computing environments is illustrated in accordance with some embodiments.

[0041] Fig.25 A diagram illustrating service standards and environment / microservice properties according to some embodiments.

[0042] Fig.26 Illustrated is an example of a service deployment optimized to minimize operating costs in accordance with some embodiments.

[0043] Fig. 27 Illustrated is an example of service deployment optimized for service availability in accordance with some embodiments.

[0044] Fig.28 An example of a service deployment optimized for security concerns according to some embodiments is illustrated.

[0045] Fig.29 Illustrated is an example of a service deployment optimized for processing speed in accordance with some embodiments.

[0046] Fig.30 An example of a service deployment that is optimized simultaneously according to multiple criteria is illustrated in accordance with some embodiments.

[0047] Fig.31 A simplified block diagram of a distributed system for implementing some of the embodiments is illustrated.

[0048] Fig.32 Illustrated is a simplified block diagram of components of a system environment by which services provided by components of an embodiment system may be provided as cloud services.

[0049] Fig.33 An exemplary computer system is illustrated in which various embodiments may be implemented. DETAILED DESCRIPTION

[0050] Described herein is an embodiment of an application programming interface (API) registrar, which is part of an integrated development environment (IDE) that allows developers to register services during development and make those services available to other services during and after deployment. The API registrar can be deployed as part of an orchestrated container platform, thereby operating as a containerized application on the container platform. As services or microservices are developed and deployed to containers on the container platform, the API registrar can perform a discovery process for locating available endpoints (e.g., IP addresses and port numbers) corresponding to available services within the container platform. The API registrar can also accept uploads of API definition files, which can be used to convert the original service endpoints into API functions available through the API registrar. The API registrar can dynamically bind the discovered endpoints to API functions, which can be kept up to date and available to other services in the container platform. This provides a stable endpoint that other services can call statically, and the API registrar manages any changes in the binding between API functions in the service endpoint. This also simplifies the process of using services in the container platform. Instead of writing code for HTTP calls, new services can access registered services using only API interfaces.

[0051] In some embodiments, the IDE can provide developers with a navigation / browsing interface to locate services available in the container platform and registered with the API registrar. When the API registrar creates a call to an existing service for a new service being developed, the API registrar can automatically generate a collection of client libraries including all necessary functions for interacting with the registered services. For example, some embodiments can generate object classes including member functions corresponding to API calls. During development, new services can simply instantiate these objects and / or use their member functions to call the corresponding API. The code in the client library manages the direct connection between the endpoint of the calling service and the registered service, and can include code for handling all functions necessary for such interaction. For example, the automatically generated client library may include: code for packaging and formatting parameters from the API call into an HTTP call to the service endpoint, code for collating data to complete the parameter set for the call, code for packaging information into compatible packets (JSON, XML, etc.), code for receiving and parsing result packets, code for handling retries and error conditions, etc. From the perspective of calling the service, the code for handling all such functions is automatically generated by the API registrar, and the details of the service call are thus abstracted and encapsulated into the client library object. All that is required to call a service is to execute a member function of the client library object created by the API registrar.

[0052] In some embodiments, the API registrar may also accept uploads of a feature set that can define the runtime execution of the registered service. This feature set can be uploaded together with the API definition file during development. These features can define runtime features, such as end-to-end encryption, usage / logging requirements, user authentication, on-demand service instantiation, multiple service deployment instances for high availability, rate / usage restrictions, and other runtime features. The API registrar can ensure that these features are met by interacting with the container environment during development, during deployment, and during runtime. During development, the automatically generated client library for calling the service may include the code required to execute these features, such as encryption code, usage logging code, and / or interaction with the user authentication service. When deploying registered services, the API registrar may instruct the container platform to instantiate multiple instances of the service and / or other load balancing modules to ensure that the service has high reliability during runtime. During runtime, when the service is called, the API registrar can enable the service to be instantiated for on-demand instantiation, limit the number of API calls that can be made to adjust usage, and perform other runtime functions.

[0053] Figure 1 The software structure and logical arrangement of the development and runtime environment for services in the container platform according to some embodiments are illustrated. These environments may include an IDE 102, which may be used to develop services and microservices to be deployed on the container platform. An IDE is a software suite that incorporates and provides all the basic tools that service developers can use to write and test new services. The IDE 102 may include a source code editor 106 with a graphical user interface (GUI), code completion functions, and a navigation / browsing interface, which allows developers to write, navigate, integrate, and visualize the source code writing process. The IDE 102 may also include a debugger 110, which includes a variable interface, an immediate variable interface, an expression evaluation interface, a memory content interface, breakpoint visualization and functions, and other debugging functions. The IDE 102 may also include a compiler and / or interpreter 108 for compiling and running compiled machine code or interpreted byte code. The compiler / interpreter 108 may include a build tool that allows developers to use / generate another makefile (make file) that builds an automated construct. Some embodiments of the IDE 102 may include a code library 112 that includes common code functions, objects, interfaces, and / or other structures that may be linked into a service being developed and reused across multiple developments.

[0054] Services can be developed within the IDE 102 and thoroughly tested until they are ready for deployment. The services can then be deployed to the production / deployment environment 104. The production / development environment 104 can include many different hardware and / or software structures, including dedicated hardware, virtual machines, and containerized platforms. Prior to the present disclosure, when the service 114 was deployed to the production / deployment environment 104, the service 114 would no longer have runtime access to many of the tools used in the IDE 102. Any functionality required for the service 114 to run in the production / development environment 104 needs to be packaged from the code base 112 and deployed to the production / deployment environment 104 with the service 114. In addition, typically the service 114 will be deployed without any functionality of the debugger 110 or a copy of the source code from the source code editor 106. In essence, the service 114 will be deployed to the production / deployment environment 104 with all the functionality required for runtime operation, but will be stripped of information that is only used during development.

[0055] Figure 2 The diagram illustrates a dedicated computer hardware system specifically designed to run the embodiments described herein. For example, the service 114 can be deployed into an Infrastructure as a Service (IaaS) cloud computing environment 202. This is a form of cloud computing that provides virtualized or shared computing resources over a network. The IaaS cloud computing environment 202 can also include other cloud computing environments that are arranged as Software as a Service (SaaS) and / or Platform as a Service (PaaS) architectures, or be coupled with other cloud computing environments. In such an environment, a cloud provider can host an infrastructure of hardware and / or software components that traditionally exist in an on-premises data center. Such hardware can include servers, storage devices, networking hardware, disk arrays, software libraries, and virtualization utilities (such as a hypervisor layer). The IaaS environment 202 can be provided by commercial sources (such as or other publicly available cloud platforms). The IaaS environment 202 can also be deployed as a private cloud using a private infrastructure of hardware and software.

[0056] Regardless of the type of cloud environment, the service 114 can be deployed on a variety of different types of hardware / software systems. For example, the service 114 can be deployed on dedicated hardware 206. The dedicated hardware 206 can include hardware resources specifically assigned to the service 114, such as servers, disks, operating systems, software packages, etc. For example, a specific server can be assigned to handle traffic flowing into and out of the service 114.

[0057] In another example, the service 114 can be deployed to hardware / software that operates as one or more virtual machines 208. A virtual machine is a simulation of a computer system that provides the functionality of dedicated computer hardware 206. However, instead of being dedicated to a specific function, the physical hardware can be shared by multiple different virtual machines. Each virtual machine can provide all the functionality required for execution, including a complete operating system. This allows virtual machines with different operating systems to run on the same physical hardware and allows multiple services to share a single hardware.

[0058] In another example, the service 114 can be deployed to a container platform 210. The container platform differs from the virtual machine 208 in several important ways. First, the container platform 210 packages the individual services into containers, as shown below. Figure 3 Each container shares the host operating system kernel, and they also share binaries, libraries, and other read-only components. This makes containers very lightweight - often only a few megabytes in size. In addition, lightweight containers are very efficient, starting in just seconds, while booting a virtual machine takes minutes. Containers also reduce management overhead by sharing an operating system and other libraries that can be maintained together for the entire collection of containers in the container platform 210. Although containers share the same operating system, they provide an isolated platform because the operating system provides virtual memory support for isolation. Container technology can include Containers, Linux Open Container Initiative (OCI), CoeOS, Mesos, etc. These containers can be deployed to a container orchestration platform, which may be referred to herein as a "container platform" 210. The container platform manages the automated placement, coordination, and management of deployed software containers. The container platform 210 can provide service discovery, load balancing, health checks, multiple deployments, etc. The container platform 210 can be implemented by any publicly available container platform (such as Kubernetes) that runs containers organized in nodes and pods.

[0059] Regardless of the platform 206, 208, 210 on which the service 114 is deployed, each of the platforms 206, 208, 210 can provide service endpoints 212, 214, 216 that provide public access for calling the service 114. Generally speaking, these endpoints can be accessed through HTTP calls and are associated with IP addresses and port numbers. By connecting to the correct IP address and port number, other services can call services deployed to any one of the platforms 206, 208, 210 when they are publicly available. Each service (such as service 114) can include its own proprietary format and data requirements for calling the service. Similarly, each service can return results that are specific to the service 114 in terms of format and data type. In addition to service-specific requirements, a specific deployment platform 206, 208, 210 can also include additional requirements for interacting with the service 114, such as programming languages, data packet formats (JSON, XML, etc.) that need to be met in order to interact correctly with the service, etc.

[0060] While the above examples allow the service 114 to be deployed to any of the platforms 206, 208, 210, the embodiments described herein are specifically designed for the above-described container platform 210. Thus, embodiments specifically documented as being to be deployed in a "container platform" can be distinguished from other embodiments specifically documented as being to be deployed in a virtual machine platform, deployed on a server or dedicated hardware platform, or generally deployed in an IaaS environment.

[0061] Figure 3The diagram illustrates the data organization of the container platform 210 that may be specific to some of the embodiments described herein. In general, any deployment of services to the container platform will be deployed to the pods 304, 306. The pod is an abstraction that represents a set of one or more application containers (such as Docker or rkt). The pod may also include some shared resources that are generally available to all containers in the pod. For example, the pod 304 includes a container 310 and a container 312. The pod 304 also includes shared resources 308. Resources may include storage volumes or other information about how the container is run or connected within the pod 304. The pod 304 may model a dedicated logical host containing relatively tightly coupled different service containers 310, 312. For example, a service 326 in a container 310 may utilize a resource 308 and call a service 320 in a container 312. Service 320 may also call service 322, which in turn calls service 324, each of which is deployed to container 312. The output of service 324 may be provided to a network IP address and port 318, which is another common resource shared by the pod 304. Thus, services 320, 322, 324, 326 all work together with shared resources 308 to provide a single service that can be accessed by services running in other containers via IP address and port number 318. The service can also be accessed via IP address and port 318 by computer systems external to the container platform, such as workstations, laptops, smart phones, or other computing devices that are not part of the container platform or IaaS environment.

[0062] In the simplest deployment, each container can include a single service, and each cabin can include a single container that encapsulates the service. For example, cabin 306 includes only a single container 314 with a single service 328. The single service can be accessed through the IP address and port number 316 of cabin 306. Typically, when a service is deployed to a container platform, containers and cabins are instantiated to maintain the service. Many different cabins can be deployed to container nodes 302. In general, cabins run within nodes. A node represents a worker machine (virtual or physical) in a container platform. Each node is managed by a "master device", which automatically handles scheduling cabins within each node. Each node can run a process responsible for communication between the master device and the node and for managing the cabins in the container on the machine represented by the node. Each node can also include a container runtime responsible for pulling container images from a registrar, unpacking the container, and running the service.

[0063] Figure 4An API registrar 404 is illustrated that can be deployed to an IDE 102 and a production / runtime environment 104 according to some embodiments. As described above, there is a technical problem in that when a service 114 is deployed from an IDE 102 to a production / deployment environment 104, the service 114 loses runtime access to information that is only available in the IDE 102. The API registrar 404 is accessible by the service 114 when the API registrar 404 is deployed and operated during runtime in the production / development environment 104. By registering services with the API registrar 404 during development and providing API definitions and / or API properties to the API registrar 404, the API registrar 404 overcomes the previous technical problem of isolation of development functionality from runtime functionality. The information defining the API can be used by new services being developed in the IDE 102 as well as services that have been deployed to the production / deployment environment 104. After completing this registration process, the service 114 can operate using a client library that accesses the API registrar 404 during runtime to ensure that the API functions are correctly bound to the current IP address and port number of the corresponding service. API Registry 404 represents new data structures and processing units specifically designed to address these technical issues.

[0064] Another technical problem that exists in the prior art is the implementation of service features when deploying service features to the production / development environment 104. For example, if a service with high availability is to be deployed, then the developer will need to build a container deployment file that specifically instantiates multiple instances of the service in the container platform and balances the business in a way that the service is always available. Service developers do not always have this expertise, and they often cannot manage the deployment of their services. As described below, the API registrar 404 allows the service to simply select features (such as high availability), which can then be automatically implemented by the API registrar 404. This technical solution is feasible because the API registrar 404 eliminates the barriers between the IDE 102 and the production / deployment environment 104.

[0065] Figure 5The deployment of an API registrar 404 used with a container platform 210 at runtime according to some embodiments is illustrated. One of the technical solutions and improvements to the prior art provided by the API registrar 404 is to maintain a stable endpoint for service calls, as well as simplified and automatic code generation for accessing service calls. Prior to the present disclosure, calls between services were point-to-point connections, such as HTTP calls to IP addresses and port numbers. As services are updated, replaced, relocated, and redeployed in the container platform 210, IP addresses and port numbers may change frequently. This requires that all services that call the updated service must update their IP addresses and port numbers in the actual code that calls the service. The API registrar 404 solves this technical problem by providing dynamic binding between the IP address and port number of the service and the API function available through the API registrar. The client library automatically generated by the API registrar 404 may include access to the API registrar 404 to retrieve and / or verify the current IP address and port number for a particular service. Therefore, the first service connected to the second service only needs to perform client library generation once to provide a stable connection to the second service during its life cycle.

[0066] Another technical problem that API registrar 404 solves is the automatic generation of client libraries. Before the disclosure, the first service accessed the second service and required developers to write custom codes for accessing the second service. Because this code may change over time, the incompatibility between the first service and the second service may increase, which requires that the two services be updated. API registrar 404 solves this technical problem by uploading the API definition file for automatically generating the client library for calling services. Therefore, the service can specifically specify how the calling code in any other service should operate, thereby ensuring compatibility. These client libraries have also greatly simplified and encapsulated the code for calling services. As described below, the complex HTTP call using IP address and port number can be replaced with a simple member function call specific to the language (for example, Java, C#, etc.) of the calling service. This allows the calling service to select an API function from API registrar 404, and the code for implementing the function can be downloaded to the calling service as a client library.

[0067] Fig. 6AA flowchart of a method for deploying an API registrar 404 according to some embodiments is illustrated. The method may include deploying an API registrar service to a container environment (601). The API registrar may be implemented as a service operating in a container environment within a container. Therefore, after the service is deployed to the container environment, the API registrar may be actively run so that it can be accessed at runtime. The API registrar may also be linked to the above-mentioned existing IDE. The method may also include discovering ports for available services in the container platform (603). When the service is deployed to the container platform, the API registrar may initiate a discovery process that sequentially traverses each service deployed to the container platform. For each service, the API registrar may detect and record an IP address and port number. A list of IP addresses and port numbers discovered by this process may be stored in a data structure, such as in a table associated with the API registrar. Each IP address and port number may also be stored with the name of the service or other identifiers that uniquely identify the service on the container platform. Fig. 6A These initial steps, shown in the flowchart in , provide a starting point for the API Registry to begin operating in the runtime environment of the container platform and to be available to services being developed in the IDE.

[0068] Figure 6B The diagram illustrates the use of Fig. 6A The software structure of the container platform 210 when the API registrar is deployed according to the flowchart in FIG. As described above, the API registrar 404 can be deployed to the container 620 in the container platform 210. The container 620 can operate in one or more pods and in a node, as described above in Figure 3 . The API registrar 404 can be made dedicated to any of the other containers in the container platform 210. In some embodiments, the API registrar 404 can also be made publicly available to other devices that are not part of the container platform 210. As a containerized service, the API registrar 404 can have an IP address and port number that can be used for other services. However, the IP address and port number of the API registrar 404 will only be used by code automatically generated in the client library, so some embodiments do not need to publish the IP address and port number of the API registrar 404. Instead, the client library in the IDE itself can maintain an up-to-date list of the IP address and port number of the API registrar 404 so that it can be contacted during development, deployment, and runtime of other services.

[0069] After the API registrar 404 is deployed to the container 620, the API registrar 404 can perform a discovery process. The discovery process can use the directory list of nodes in the container platform to identify the cabin that implements the service using the IP address and port number. The API registrar 404 can then access a unique identifier (such as the number or name of each available service) and store the identifier with each IP address and port number in the container platform 210. This discovery process can be performed periodically to detect new services added to the container platform 210, and to identify existing services removed from the container platform 210. As described below, this discovery process can also be used to detect when the IP address and port number of an existing service change. For example, the API registrar 404 can discover services with endpoints 602, 604, 606, 608. In the process described below, the API registrar 404 can bind each of these endpoints 602, 604, 606, 608 to an API function registered with the API registrar 404. At some point after this initial discovery, the IP address and / or port number of endpoint 602 may change when the service associated with endpoint 602 is replaced, updated, or revised. API registrar 404 may detect such changes to endpoint 602 and update the bindings to the existing API functions provided by API registrar 44.

[0070] Similarly, API registrar 404 can use a discovery process to detect when an endpoint is no longer available and then remove the API function associated with the service. In some embodiments, when a service has been registered with API registrar 404, but the corresponding API function is not currently bound to a valid endpoint, API registrar 404 can provide a virtual (mock) response to any service that calls the corresponding API function. For example, if an API has been registered for a service corresponding to endpoint 604, but endpoint 604 is not currently available, then API registrar 404 can intercept calls to endpoint 604 and provide default or dummy data as a response. This allows the service that calls the service associated with endpoint 604 to maintain functionality and / or continue the design process without "disconnecting" from this particular service. Virtual / test data scenarios will be described in more detail below.

[0071] Fig. 7AA flow diagram of a method for registering a service with an API registrar 404 according to some embodiments is illustrated. The method may include receiving an upload of an API definition (701). The API definition may be provided in the form of a data packet, a file, or a link to an information repository. The API definition may include any information that may be used to identify and define an API function that should be bound to an endpoint associated with a service. For example, some embodiments of an API definition may include the following data: a service name or other unique identifier; a function name corresponding to a service endpoint and call; data inputs required to call the service and corresponding descriptions and data types; result data formats and data types; current IP addresses and / or port numbers; documentation describing the functionality of the API function to be associated with the endpoint; default or dummy data values ​​that should be returned during virtual / test scenarios; and any other information that may be used by the API registrar 404 to translate HTTP requests received by the endpoint into API function calls using class data objects by a client library.

[0072] The method may also include creating corresponding API functions (703) based on the uploaded API definition. These API functions may be automatically generated based on the API definition. Each endpoint of the service may be associated with a plurality of different API functions. For example, an endpoint implementing a RESTful interface may receive HTTP calls to POST, GET, PUT, and DELETE functions at the same IP address and port number. For example, this may result in different API functions. For example, if the interface represents a list of users, then this list may correspond to at least four different API functions, such as GetUser(), AddUser(), RemoveUser(), and UpdateUser(). In addition, each API function may include a plurality of different parameter lists, such as UpdateUser(id), UpdateUser(name), UpdateUser(firstname, lastname), etc. These API functions may be generated and made available to other services through an API registrar. As will be described in more detail below, it should be noted that services are not required to call these functions through an API registrar. Instead, these functions may be used to browse in an API registrar, and when selected, an API registrar may generate a client library that implements these functions in a calling service.

[0073] The method may additionally include creating bindings in the API registrar between corresponding endpoints of the API function and the service (705). Based on the above discovery process and the registration process of step 701, the API registrar can now create dynamic bindings between the endpoints of the service in the container platform and the API functions created by the API registrar. In the data structure formed when the available endpoints and services are discovered above, the API registrar can now store the corresponding function or set of functions for each endpoint. As described above, this binding can be continuously updated when the discovery process determines when a service is updated, moved, replaced, or added to the container platform. This allows the client library created in calling the service to first check the API registrar to verify or receive the current IP address and port number for the service.

[0074] Figure 7B A hardware / software schematic diagram of the steps for registering an API with an API registrar 404 according to some embodiments is illustrated. As described above, the API registrar 404 can be instantiated and run in a container 620 in a container platform 210. Even if the container platform 210 represents a production / deployment environment, the API registrar 404 can still be accessed by the IDE 102 for developing services. Therefore, the IDE 102 can provide a mechanism for uploading an API definition file 702 to the API registrar 404. Specifically, the user interface of the IDE 102 can include a window or interface that allows developers to define and / or fill in fields for the API definition file 702. Such information described above can include function names, parameter lists, data types, field lengths, object class definitions, IP addresses and port numbers, service names or other unique identifiers, etc. Such information can be uploaded to the API registrar 404 and linked to a specific IP address and port number of the endpoint 602 in a dynamic binding manner. Finally, the API registrar 404 can generate one or more API functions 704 that can be used through the API registrar 404.

[0075] After registering a service with the API registrar 404 and generating one or more API functions, the API registrar can make these functions available to developers as they design services. Figure 8 An example of a graphical interface 802 and a command line interface 804 for browsing and selecting an API registered with an API registrar 804 according to some embodiments is illustrated. When programming and developing new services for a container platform, developers can access the graphical interface 802 to browse and select API functions that can be used in their services. This graphical interface 802 is merely an example and is not meant to limit the type of graphical interface that can be used to browse and select API functions.

[0076] In this embodiment, IDE 102 can summon graphical interface 802 to provide a list of APIs registered with the API registrar. In this embodiment, APIs are classified based on endpoints. For example, an endpoint corresponding to a service can provide a RESTful interface (e.g., "UserStorage") for storing user records. Graphical interface 802 can display all API functions available through the selected endpoint (e.g., "CreateUser", "DeleteUser", "UpdateUser", etc.). In the case where a service provides multiple endpoints, other embodiments can group functions based on the entire service. Graphical interface 802 can receive a selection of one or more API functions to be used when calling a service. The API registrar can then provide documentation explaining how to use the API functions, including required parameters and return values. It will be understood by those of ordinary skill in the art that command line interface 804 can provide similar information to graphical interface 802 and can receive similar input.

[0077] Figure 8 The interfaces 802, 804 shown in FIG. 8 provide a number of technical advantages. First, these interfaces 802, 804 provide an up-to-date list of all APIs registered with the API registry. This corresponds to a list of all services currently available in the container platform. Service developers can retrieve and display this information in real time, rather than having to look up documentation, contact service developers, and / or perform other inefficient tasks to locate a list of available services. In addition, as services are updated, the API definition files can be updated in a corresponding manner. This update can then be used to create a new API definition file. Figure 8 to provide the latest availability information for each API function.

[0078] Fig. 9 A flow chart of a method for using services registered with an API registrar and their corresponding functions according to some embodiments is illustrated. The method may include providing a list of registered APIs (901). This step may be omitted if the desired service is already known. However, in general, the above Figure 8 The method may also include receiving a selection of an API function (901). The API registrar may receive this selection from a developer of the service. For example, the developer may decide to use the CreateUser() function described above to update a database of user records. Fig.10 It illustrates how the API registrar may receive selections 1002 through the graphical interface 802 for the CreateUser() function. Other embodiments may receive selections through a command line interface or through other input methods provided by an IDE.

[0079] Return to reference Fig. 9 Once the selection of the API function is received, the API registrar can generate one or more client libraries for the calling service (905). Generating the client library can provide the calling service with a service endpoint that is dynamically bound to the API function. Specifically, the IDE can generate a collection of class objects in the IDE that encapsulate the functionality required to interface directly with the service endpoint in the container platform. In some embodiments, the client library can include an object class that can be instantiated or used to call member functions of the code required to implement communication with the service. Examples of these client libraries will be described in more detail below.

[0080] The method may additionally include providing test data (907). When a service is registered with an API registrar, it does not need to be complete. Instead, the service may indicate to the API registrar that it is not yet ready to provide a function response to the calling service. In some embodiments, the API definition file uploaded to the API registrar may include specifications for the type of information that should be returned before the service functions. When the calling service calls the API function, the client library generated by the API registrar may route the request to the API registrar instead of the service endpoint. The API registrar may then provide a response using a dummy value, a null value, or a default value. Alternatively, the code within the client library itself may generate default data to be returned to the calling service.

[0081] It should be recognized that Fig. 9 The specific steps shown in provide specific methods for using the API registrar according to various embodiments of the present invention. According to alternative embodiments, other sequences of steps may also be performed. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, Fig. 9 The various steps shown in the may include multiple sub-steps, which may be performed in various orders suitable for the various steps. In addition, additional steps may be added or removed depending on the specific application. Those of ordinary skill in the art will recognize many variations, modifications, and alternatives.

[0082] Fig.11 An example of a client library automatically generated for a service by an API registrar according to some embodiments is illustrated. This client library 1102 may correspond to a service that stores user records. This client library 1102 and corresponding classes and services are provided by way of example only and are not meant to be limiting. As described above, each API function and service may specify how the client library should be generated by an API definition file uploaded to the API registrar. Therefore, the principles described below with respect to the "User" service may be applied to other services.

[0083] To represent the "User" service, the API registrar can generate a class for User. When a calling service requests the API registrar to generate a client library, the calling service can specify the programming language used by the calling service. For example, if the calling service is written in Java in an IDE, the API registrar can generate a class library in the Java programming language. Alternatively, if the calling service is written in C#, the API registrar can generate a class library in the C# programming language. The User class can be generated to have member functions corresponding to different operations that can be performed through the service endpoint. These member functions can be static, so that they do not require an instantiated instance of the User class, or they can be used with an instantiated User object.

[0084] In this example, the User service can use a RESTful interface to edit each user record stored by the service. For example, the API registrar can generate a CreateUser() function to implement a POST call to the User service. One of the functions that the class library can perform is to parse, filter and format the data provided to the API function as a parameter to be directly sent to the service as a data packet. In this example, the CreateUser() function can accept parameters that are formatted for the convenience of calling the service. For example, the calling service can store strings of the user's first name and the user's last name respectively. However, the POST command may require a string of cascades of the first name and last name together. In order to adapt to a user-friendly parameter set, the client library 1102 can perform a setup operation that formats the data received as a parameter of the function into a format compatible with the service endpoint. This can include generating header information, changing the format of certain data fields, cascading data fields, requesting additional data from other sources, performing calculations or data transformations, etc. This can also include packaging the reformatted parameters into formats such as JSON, XML, etc.

[0085] Once the parameters are correctly formatted into a package for the service endpoint, the client library 1102 can also handle POST calls to the service. When the client library is generated, the IP address and port number of the service can be inserted into the CreateUser() function to be used in the HTTP request to the service. Note that the details of the HTTP request are encapsulated in the CreateUser() function. When developers calling the service want to use the POST function available through the service instead of writing code in the library 1102 themselves, they can instead select the "User" service from the API registrar. The API registrar will then automatically generate a client library 1102 that includes the User class. Then, to use the POST function, the service developer can simply use the User.CreateUser("John", "Smith", 2112) function to add user John Smith to the service.

[0086] Fig.12 An embodiment of a client library 1202 that accommodates dynamic binding between service endpoints and API functions according to some embodiments is illustrated. In this example, when the API registrar generates the client library 1202, the CreateUser() function may include code 1204 that dynamically retrieves the IP address and port number of the service. When the call service 114 operates in a production / deployment environment 104 (such as a container platform), the call service 114 may use the GetIPPort() function to send a request to the API registrar 404 at runtime. The API registrar 404 may access its internal table, which is consistently updated to maintain the latest binding between the API function and the service endpoint. The API registrar 404 may then return the current IP address and port number to the call service 114. The client library 1202 may then insert the IP address and port number into the HTTP POST code that connects to the service. Because the API registrar 404 may be accessed by any call service in the container platform at runtime, there is no need to update or patch these services when the IP address or port number of the called service changes. Instead, the API registrar 404 may provide the latest information each time the service is called. In some embodiments, assuming that the service endpoint does not change frequently in a production environment, the GetIPPort() function may only need to call the API registrar 404 once an hour, once a day, once a week, etc. to minimize the number of function calls made for the service 114 outside the container.

[0087] Fig.13An embodiment of a client library 1302 according to some embodiments is illustrated, which can collate additional data to complete an input data set for a service call. In order to simplify the use of the client library 1302, the client library 1302 can minimize the number of parameters required by the service developer. The additional data required for the service call can be retrieved from other sources, and therefore can be omitted from the parameter list. Alternatively, the client library 1302 can retrieve these additional parameters directly from these other sources. For example, creating a new user can include specifying a user role for the user. Instead of requiring the service developer to provide a user role as one of the parameters, the client library 1302 can instead include code 1304 that automatically retrieves the user's role from some other source. In this example, the user role can be retrieved from a database, from another service in the container platform, or from another class that stores the user role in the calling service. In any of these cases, the code 1304 can automatically retrieve the user role and package it as part of the input data of the HTTP POST command sent to the service.

[0088] In addition to arranging and formatting the data for inputting into the service, the client library 1302 can also parse and return the data received from the service and handle error conditions. In this example, the POST command can return the data packet to the Result variable. The service can often return the data packet including more information than the information required for calling the service. Therefore, the client library 1302 can parse the data fields in the Result variable, and extract and format the data from the Result variable, and package the data from the Result variable into a more usable and desired format for the User class. In this example, code 1306 can extract fields from the Result variable, and use them to create a new User object returned from the API function. In another example using the GET command, each API function can be generated in the User class, and these API functions extract different fields from the Result variable from the GET command. For example, the User class can provide GetFirstName (id) function, GetLastName (id) function, GetRole (id) function, etc. Each of these functions can include very similar code, while returning different fields from the Result variable.

[0089] In addition to parsing the results, the client library 1302 can also generate code 1308 to handle error conditions associated with using the service. In this example, the code 1308 can test the status field in the Result variable to determine whether the POST command was successful. If the command is successful, the CreateUser() function can return a new User object. In the event that the Post command fails, the function can instead return an empty object and / or retry the call to the service.

[0090] Fig.14 1402 is illustrated that can handle retries when calling a service according to some embodiments. Fig.13 As in the example of , the client library 1402 uses the status in the Result variable populated by the POST HTTP call to determine whether the call is successful. When the result is unsuccessful, the client library 1402 can continue to retry until the call is successful. Some embodiments can use a counter or other mechanism to limit the number of retries or add a waiting time between retries.

[0091] As described above, some embodiments may also upload a set of API properties along with the API definition to an API registrar. Fig.15A A method of providing API characteristics to an API registrar according to some embodiments is illustrated. The method may include receiving an upload of an API definition (1501). The method may also include receiving an upload of an API characteristic (1503). The upload of the characteristic may be part of the same transmission as the upload of the API definition. In some embodiments, the API characteristic may be part of the API definition. In some embodiments, the API characteristic may be one or more flags or predefined data fields that are checked to indicate that the characteristic should be set by the API registrar. In some embodiments, the API characteristic need not conform to any pre-structured format, but may instead be represented by instruction code that causes the API registrar to implement the following features (such as authentication, encryption, etc.). The API characteristics may be stored with the API definition for each service.

[0092] The method may additionally include creating an API binding between the service and the API (1505). This operation may be performed as described in detail above. In addition, the method may include using the API feature to perform one or more operations associated with the service (1507). The API feature may be used at different stages during the life cycle of the service. Generally speaking, this can be described as using the API feature to implement a function associated with the feature during service deployment, when generating a client library for the service, and / or when calling the service. Examples of each of these functions will be described in more detail below.

[0093] It should be recognized that Fig.15A The specific steps shown in provide specific methods for providing API features to an API registrar according to various embodiments of the present invention. According to alternative embodiments, other sequences of steps may also be performed. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, Fig.15A The various steps shown in the may include multiple sub-steps, which may be performed in various orders suitable for the various steps. In addition, additional steps may be added or removed depending on the specific application. Those of ordinary skill in the art will recognize many variations, modifications, and alternatives.

[0094] Fig. 15B A hardware / software diagram illustrating how a service may provide API properties to an API registrar according to some embodiments. When developing a service in IDE 102, a service developer may provide an API definition file 1502 and one or more properties 1504 to API registrar 404. Because API registrar 404 is accessible in both IDE 102 and container platforms at runtime, API registrar 404 may store properties 1504 and use them to affect how services are deployed, called, and / or used to generate client libraries during development and runtime scenarios.

[0095] Fig.16 A hardware / software schematic diagram is illustrated according to some embodiments, in which an API registrar uses features to deploy services with high availability. In addition to the API definition file 1505 for a particular service, the API registrar 404 may also receive a feature 1602 indicating that the service should be deployed to be very resilient or with high availability. This feature 1602 may be received as a set of instructions executed by the API registrar 404 to deploy the service with high availability. This option allows developers to define what "high availability" means for this service. For example, feature 1602 may include instructions that cause the API registrar 404 to deploy multiple instances 602, 604 of a service to the container platform 210. By executing these instructions, the API registrar 404 does not need to make any decisions or determinations on its own, but may instead simply execute the deployment code provided as part of feature 1602.

[0096] The characteristic 1602 may also be received as a flag or setting that indicates to the API registrar 404 an option to execute existing instructions for deploying a service with high availability at the API registrar 404. With this option, the API registrar 404 need not receive any code to be executed as the characteristic 1602. Instead, the API registrar 404 may recognize the high availability characteristic 1602 and execute code maintained in the API registrar 404 to deploy multiple instances 602, 604 of a service. This allows the API registrar 404 to define what "high availability" means for the deployment of any service registered with the API registrar 404.

[0097] Because the API registrar 404 is connected to the runtime environment of the container platform 210, the API registrar 404 can interact with the container platform 210 to deploy instances 602, 604 that determine the runtime availability of the service. Fig.16 The two instances 602, 604 of the service shown in FIG. 5 are provided as an example only and are not meant to be limiting. A high availability service may include more than two redundant instances of a service deployed to a container platform.

[0098] Some embodiments may include code in the API registrar 404 that may be executed by default. If feature 602 includes only a simple indication that high availability is desired, then the API registrar 404 may execute its own code. If feature 602 includes deployment code for deploying a service, then the API registrar 404 may execute the code of feature 1602 instead. In some cases, feature 1602 may include only the portion of the code required to deploy a service with high availability. The API registrar 404 may execute the portion of the code provided by feature 1602 and then use the code at the API registrar 404 to execute any code not provided by feature 1602. This allows developers to override existing definitions of how features (such as high availability) are executed at the API registrar 404, while still allowing the API registrar 404 to provide a unified definition for executing features that can be used by registered services.

[0099] In some embodiments, the high availability feature may also enable the container platform 210 to deploy a load balancing service 606 that distributes requests to multiple instances 602, 604 of the service. The endpoints of the load balancing service 606 may be registered with the API registrar 404 and available to other services. Alternatively or additionally, each of the multiple instances of the service 602, 604 may be registered with the API registrar 404 as a service endpoint.

[0100] In each of the examples described below, you can apply Fig.16The same principles discussed above. For example, any of the features described below can be accompanied by code that can be received by the API registrar 404 and used to override code that would otherwise be executed by the API registrar 404. Prior to the present disclosure, there was no method for creating uniform defaults for executing features while allowing service developers to override those features when needed. Therefore, the API registrar 404 solves the technical problem by allowing code at the API registrar 404 to be executed by default, while still allowing that code to be overridden by features 1602 received from developers.

[0101] Fig.17 A hardware / software schematic diagram of a feature for enforcing end-to-end encryption through an API registrar according to some embodiments is illustrated. Along with the API definition file 1505, the API registrar 404 can receive a feature 1704 that indicates end-to-end encryption for calling a service 1708 or includes code that generates end-to-end encryption for calling a service 1708. During development, the service 1708 can include its own decryption / encryption code 1710 that causes packets received by the service 1708 to be decrypted and packets returned by the service 1708 to be encrypted. Prior to this disclosure, developers would need to provide specifications that indicate that users of the service 1708 need to provide encryption to be compatible with the service 1708. This embodiment solves the technical problem by allowing the service 1708 to indicate how the client library is generated in calling the service 1706, which ensures compatibility with the encryption of the service 1708.

[0102] In some embodiments, the developer of service 1708 need not include encryption / decryption code 1710 in service 1708. Instead, feature 1704 may simply instruct API registrar 404 to enforce end-to-end encryption for service 1708. When service 1708 is deployed to container platform 210, API registrar 404 may cause encryption / decryption code 1710 to be inserted into service 1708 when service 1708 is deployed. This allows developers to select between different encryption schemes based on feature 1704 and / or allows API registrar 404 to select a preferred encryption scheme as the default scheme.

[0103] End-to-end encryption requires not only that the encryption / decryption code 1710 be inserted into the service 1708 when the service is deployed or during development, but also that the calling service 1706 also includes compatible encryption / decryption code. As described above, when the calling service 1706 needs to use the service 1708, the API registrar 404 can generate one or more client libraries 1702, which fully implement the code required to interact with the service 1708 in a simple and efficient manner. When generating this client library 1702, the API registrar 404 can analyze the characteristics 1704 to determine the encryption scheme used by the service 1708. Then, based on the characteristics 1704, the API registrar 404 can cause compatible encryption / decryption code to be added to the client library 1702 for calling the service 1706. Therefore, when the calling service 1706 sends a request to the service 1708, the information can be encrypted at the calling service 1706 and decrypted once received by the service 1708. Similarly, service 1708 can encrypt the response before sending it to calling service 1706, which can then decrypt the response before passing it outside of client library 1702. This makes the entire encryption process completely transparent to the developer calling service 1706. Feature 1704 can ensure that API registrar 404 has generated encryption / decryption code in client library 1702 for compatibility and implementation of the end-to-end encryption feature, rather than requiring a compatible encryption / decryption scheme to be implemented when calling service 1706.

[0104] Fig.18 The diagram illustrates a feature 1804 for enabling an API registrar to implement usage logging for a service 1808 according to some embodiments. Prior to the present disclosure, in order to monitor and log the frequency, source, success rate, etc. of requests to a service, the service itself had to log such information. Alternatively, the container environment must monitor the service and log its usage information. Logging information at the service 1808 itself is very inefficient and slows down the throughput of each request handled by the service. Similarly, the overhead of requiring the container platform to monitor and log all calls to a particular service also introduces significant overhead to the scheduling and orchestration of container services. This embodiment solves this technical problem by inserting code directly into the client library of the service used to call the service 1808. This allows logging and monitoring of the usage of the service 1808 without affecting the performance of the service 1808 at all in terms of memory usage or CPU usage.

[0105] In addition to the API definition file 1505, the API registrar 404 may also receive a property 1804 indicating usage logging 1804 or including code that implements usage logging 1804. When a developer calling a service 1806 desires to submit a request to a service 1808, the API registrar 404 may automatically generate a client library 1802 that includes code for logging activities associated with the service 1808. As described above, such code may be generated based on default code maintained and executed by the API registrar 404, or may be generated by code received using the property 1804 and executed by the API registrar 404.

[0106] Code for logging activity in client library 1802 may include a counter that increments each time service 1808 is called, a function that causes activity to be logged to a log file when service 1808 is called, and other functions that monitor and record characteristics of requests sent to service 1808 and responses received from service 1808. Depending on the particular embodiment, such code may monitor many different types of characteristics associated with requests made to service 1808. For example, some embodiments may log the total number of calls made to service 1808. Some embodiments may log the success rate of responses received from service 1808. Some embodiments may log the type of data sent in a request to service 1808. Some embodiments may log the time of day or other external information when service 1808 is called. Some embodiments may log input and output packets to / from service 1808 that can be used to debug service 1808. Some embodiments may log any or all of these characteristics in any combination without limitation.

[0107] Fig.19 A hardware / software schematic of feature 1904 that may enforce an authentication protocol on a service 1908 according to some embodiments is illustrated. Some services may require authentication of a user's identity and require the user to be authorized to use the service before responding to a request. Prior to the present disclosure, there were technical issues with performing the authentication and authorization process at the service 1908 itself. This adds overhead in terms of memory usage and CPU usage for each call received by the service 1908, and increases latency to the service when responding. This in turn reduces throughput and limits the number of requests that the service 1908 can handle during any given time interval. These embodiments address this technical issue by moving the authentication / authorization code to a client library 1902 that is automatically generated by the API registrar 1404.

[0108] When the calling service 1906 wants to use the service 1908, the API registrar 404 can generate a client library 1902 including code for performing authorization and / or authentication. In some embodiments, this can include contacting an external authentication / authorization service 1920 that specifically verifies the identity of the user and / or determines whether the user is authorized to use the service 1908. The external authentication / authorization service 1920 can include an access manager, a lightweight directory access protocol (LDAP) manager, an access control list (ACL), a network authentication protocol manager, etc. Then, when the authentication / authorization process is successful, the code in the client library 1902 can send the call to the service 1908.

[0109] By offloading authentication / authorization enforcement to the API registrar 404 and client library 1902, such code can be completely eliminated from the service 1908. Because interaction with external authentication / authorization services 1920 often comes with significant delays, such delays can be removed from the service 1908 to increase throughput. In addition, rather than hard-coding authentication / authorization enforcement into the service 1908, developers of the service 1908 can simply select a predefined authentication / authorization scheme using the feature 1904 sent to the API registrar 404 instead. The API registrar 404 can maintain a predefined list of authorization / authentication with accompanying implementation code for the client library 1902. This also prevents the calling service 1906 from sending a request that cannot be authorized and / or authenticated to the service 1908. Instead, if the authentication and / or authorization routine is unsuccessful, the call can be terminated at the client library 1902. This ensures that the service 1908 only receives authenticated and / or authorized requests.

[0110] Another technical improvement provided by API registrar 404 is the ability to upgrade any functionality provided by feature 1904 without changing any code of any registered service. For example, because the authentication / authorization code has been offloaded to client library 1902 generated by API registrar 1404, client library 1902 can be updated to change the authentication / authorization scheme. No code in calling service 1906 or service 1908 needs to be modified. Because the code is only changed in a single location, this greatly reduces the probability of code integration errors that would otherwise accompany distributed patches sent to each individual service.

[0111] Fig. 20A hardware / software schematic of feature 2004 for enabling runtime instantiation of services according to some embodiments is illustrated. Some services may be rarely used or only used within predefined time intervals. Therefore, deploying a service to a container platform does not necessarily always result in actually instantiating a service instance in a container that is immediately available. Containers can be instantiated and activated very quickly compared to virtual machines. Therefore, a service developer may expect that the service is instantiated only when the service is called. The service developer may also expect that the service is instantiated only within a predefined time interval. Similarly, a service developer can specify that a service instance should be deleted after a predefined time interval of inactivity.

[0112] In addition to receiving the API definition file 1505, the API registrar 404 may also receive properties 2004 that specify runtime instantiation or other instantiation parameters. For example, a property may include a specification of one or more time intervals after deployment that the service 2008 should be instantiated. In another example, a property may include an indication that the service 2008 should only be instantiated on demand. In another example, a property may specify a timeout interval after which the instantiated service 2008 should be deleted from the container platform.

[0113] When the calling service 2006 wants to use the service 2008, the API registrar 404 can generate code in the client library 2002 to handle the runtime instance of the service 2008. For example, the CreateInstance() function call in the client library 2002 can create a call to the API registrar 404. The API registrar can then interact with the container platform 210 to determine whether an operational instance of the service 2008 is available. If it is not available, the API registrar 404 can instruct the container platform 210 to instantiate an instance of the service 2008 in a container in the container platform 210. The container platform 210 can then return an endpoint (e.g., an IP address and port number) to the API registrar 404. The API registrar 404 can then create a binding between the endpoint and the API function call created in the client library 2002. The API registrar 404 can then return the endpoint to the client library 2002, which can be used to create a direct connection between the calling service 2006 and the newly instantiated service 2008.

[0114] For services that should only be instantiated during predefined time intervals, API registrar 404 can establish a table of instantiation and deletion times for certain services. Based on these stored instantiation / deletion times, API registrar 404 can instruct container platform 210 to instantiate or delete instances of service 2008. API registrar 404 can also specify multiple instances that should be instantiated during these predefined intervals. For example, from 5:00PM to 10:00PM, feature 2004 can specify that at least 10 instances of service 2008 are active on container platform 210. When this time interval occurs, API registrar 404 can instruct container platform 210 to create additional instances.

[0115] Fig.21 The hardware / software schematic diagram of feature 2104 for implementing the rate limiting function for service 2108 according to some embodiments is illustrated. Some services may need to limit the rate at which requests are received. Other services may need to limit requests from certain senders or types of services. Prior to the present disclosure, this function must be performed by the service itself by determining the source of each request, comparing the source with a whitelist / blacklist, and adjusting the rate at which it serves these requests. As with most of the above examples, placing this overhead in the service itself will increase the amount of memory and CPU power used by the service and limit the throughput of the service. These embodiments solve this technical problem by automatically generating rate limiting code in the client library generated by the API registrar. This allows the service to specify rate limits with the help of feature 2104 without requiring service 2108 to implement the function using all its associated overhead.

[0116] When calling service 2106 wants to send a request to service 2108, API registrar 404 can automatically generate client library 2102 including rate limiting code. When generating client library 2102, API registrar 404 can determine whether specific service 2106 should be subject to rate limiting. If not, client library 2102 can be generated as usual. If API registrar 404 determines that calling service 2106 should be subject to rate limiting (e.g., by comparing with whitelist / blacklist), then API registrar 404 can insert code that adds delay, adds counter and / or otherwise implements rate limiting function in client library 2102 to ensure that the calling service 2106 performs a predefined maximum number of requests in any given time interval according to a predefined rate. Such code can also implement a time window in which the rate limiting function will be active. This allows service 2108 to automatically implement rate limiting during high business intervals.

[0117] The microservice architecture can include multiple microservices that can be used to implement larger services. The microservice architecture uses software design techniques that focus on breaking down large tasks into many fine-grained individual tasks (called microservices). For each microservice, the corresponding microtask to be implemented is simple and the protocol is generally lightweight. This architecture evolved from the architectural style of service-oriented architecture (SOA), which designs large applications as a collection of small, loosely coupled services. The microservice architecture improves this concept by further refining each service into a collection of simple, complete and largely independent tasks that can be designed, developed, deployed and operated separately, or can be combined with other microservices to implement complex operations. One of the benefits of decomposing an application into microservices is the modularity of the resulting simple, easy-to-understand software design. Due to this modularity, microservice applications are easier to design, test and maintain, and have stronger resistance to obsolescence. Microservices can be developed in parallel by small autonomous teams and deployed independently. Microservices can also be continuously refactored and reorganized without changing their external behavior or their operation in a larger application or service framework.

[0118] As defined herein, microservices can be contrasted with conventional services or applications by the scope of processing encapsulated by microservices. Microservices often communicate on the network using technology-independent protocols (such as HTTP). Microservices can be independently deployed and generally share little information with other microservices outside their available interfaces. Compared with the overhead of SOA architecture, microservices can use simple messaging to replace enterprise service bus (ESB). As a replacement for shared components, microservices are intended to minimize sharing through bounded contexts, which couple microservice code and data as a single unit with minimal dependencies. Finally, the prefix "micro" in microservices refers to the small granularity of its internal operations. Microservices are generally single-purpose services that perform a single task as efficiently as possible. In general, services usually include much more business functions and are often implemented as complete subsystems.

[0119] For the purposes of this disclosure, microservices are also well suited for containerized environments. Note that containers and microservices are not the same concept; containers are software tools that are well suited for organizing and developing microservices. Containers package all software, runtimes, system tools, system libraries, settings, etc. together to allow microservices to be relatively isolated from other software in containers in the same environment, while providing everything needed to run microservices. This allows microservices to focus on their task execution rather than system interactions and overhead. In addition, container platform environments are particularly suitable for microservices. For example, container platforms can easily deploy and manage multiple containers of the same type and many different types of containers at the same time. In essence, container platforms can handle the allocation and deployment of containerized microservices to adapt to the available hardware in the platform.

[0120] Fig. 22 An example of a service built from multiple microservices according to some embodiments is illustrated. Top-level service 2216 can be used to implement a standard business process. Top-level service 2216 can include multiple microservices that implement a single discrete software step in a business process. Each microservice is a self-contained process, and service 2216 includes all microservices required to implement service 2216. In this embodiment, service 2216 can be distinguished from any microservice due to the fact that a microservice represents a single step that performs an overall service 2216 and the microservice is logically encapsulated in service 2216.

[0121] An example of such a top-level service 2216 may include a ProcessOrder() service for processing customer orders. The business process implemented by service 2216 may include multiple discrete steps, such as adjusting inventory, generating invoices, charging user accounts, creating shipping orders, updating ledgers, etc. Each of these discrete steps may be implemented by a microservice that builds service 2216. Each of these microservices may also be deployed to a container within a cabin represented by service 2216. For example, these microservices may include functions such as AdjustInventory(), CreateShipper(), Invoice(), ChargeAccount(), UpdateLedger(), EmailReceipt(), and CreateUserAccount(), which may be represented by microservices 2202, 2204, 2206, 2208, 2210, 2212, and 2214. Each of these microservices may call each other within service 2216. Service 2216 may be represented by a node or cabin in a container platform, and may also include endpoints 2218 available through HTTP calls to other services in the platform.

[0122] In some cases, a microservice can be built from a single process encapsulated in a single container. For example, Fig. 22 Microservices 2202, 2206, 2208, and 2212 in 2204 and 2214 may consist of a single service in a single container. However, other microservices may include a collection of functions encapsulated in a single container. For example, microservices 2204 and 2214 may include multiple functions in a single container. In addition, some microservices, such as microservice 2210, may include multiple functions in multiple containers encapsulated in a single microservice. Each of these microservice designs is included in the term "microservice" as used herein. In addition, each microservice may be encapsulated in a pod, such as Fig. 22 However, according to different embodiments, microservices may also be represented by containers and collected together in a pod or container node to form a service 2216.

[0123] Fig.23 The deployment environment for service 2216 according to some embodiments is illustrated. Some embodiments of the container platform 210 can utilize the container platform scheduler 2306 to scale and deploy a large number of containers across the container platform 210. When services are horizontally extended across multiple host systems within the container platform 210, the ability to manage each host system and abstract away the complexity of the underlying container platform will become advantageous. "Orchestration" is a broad term that refers to container scheduling, clusters of management nodes, and possible provisioning of additional hosts in a container environment. "Scheduling" in a container platform can refer to the ability to load a service onto a host system and establish how to run that particular container. Although scheduling specifically refers to the process of loading a service definition, it can also be responsible for other aspects of the operation of managing a cluster of nodes. Managing a cluster of nodes involves the process of controlling a group of computing hosts. This is closely tied to scheduling because the scheduler 2306 may need to access each node in the cluster in order to schedule the services defined above. However, the process of the scheduler 2306 that the embodiments described herein are most interested in involves host selection. In this sense, the task of the scheduler 2202 can be to automatically select a container environment on which a specific service built from multiple microservices is deployed and run.

[0124] In addition to the scheduler 2306, the container platform may also include an API registrar 404 as described in detail above. The API registrar 404 may receive the service 2216 from the development environment of the IDE and work with the scheduler 2306 to deploy the service 2216 into the container platform 210. As described above, the service 216 may be deployed based on one or more characteristics (such as accessibility, security, encryption, authentication, etc.) provided to the API registrar 404. These characteristics may determine additional code that is added to the calling service or the service 2216 itself when the service is deployed to the container platform. However, the above characteristics generally do not need to be related to the location of the service 2216 when it is deployed to the container platform.

[0125] Prior to the present disclosure, there were technical problems in the art with service-based deployment. Because services are meant to be self-contained functional blocks, the internal workings of the services are deployed together in a single computing environment in a pod / node. For example, when service 2216 is deployed to container platform 210, all microservices 2202, 2204, 2206, 2208, 2210, 2212, and 2214 will be deployed together in first environment 2302. Because it is assumed that microservices 2202, 2204, 2206, 2208, 2210, 2212, and 2214 operate together as logical and functional blocks, service 2216 will always be deployed to a single environment without splitting any of its internal components into other environments.

[0126] As used herein, the term "environment" may include a computing environment. Two different environments will be considered to be functionally and physically separated from each other. For example, a first environment may include a cloud platform that can receive containerized services and microservices. The second environment 2304 in the container platform may include an internally deployed environment that is physically and functionally separated from the cloud platform of the first environment 2302. The first environment 2302 and the second environment 2304 may be physically separated by a distance greater than 1 mile, and may be operated using separate and different processors, memory devices, network interfaces, and other computer hardware. The first environment 2302 and the second environment 2304 may be operated using different operating systems or different instances of the same type of operating system. In addition, the first environment 2302 and the second environment 2304 may have different characteristics considered by the embodiments described below. Specifically, these environments 2302, 2304 may have different operating characteristics associated with cost, availability, security, delay, and other general characteristics associated with the computing environment.

[0127] In a system operating prior to the present disclosure, because the service 2216 will be deployed to a single environment (such as the first environment 2302), the deployment of the service 2216 cannot be optimized to be deployed across separate physical environments (including the second environment 2304). Because these different environments 2302, 2304 have different characteristics, some of the microservices 2202, 2204, 2206, 2208, 2210, 2212, and 2214 may also have characteristics that enable some of these microservices to operate more efficiently on different environments. However, the services are not split between separate environments. In addition, there is no method or process for determining which microservices should be placed on which environments to optimize the overall performance of the service 2216. Ultimately, the service 2216 itself can be associated with a deployment standard (such as cost, availability, latency, security, location, etc.) indicating the desired characteristics of the service 2216 to be optimized during deployment. However, the container platform cannot identify, process, and optimize service deployment based on deployment attributes. This results in inefficient service operations, including increased latency, inefficient memory usage, and increased processing demands on the host environment (such as the first environment 2302).

[0128] The embodiments described herein address these and other technical issues and improve the overall functionality of the cloud platform 210 by receiving one or more criteria associated with the deployment of a service 2216, which specifies the operational aspects of the service 2216 that should be optimized by deployment. The scheduler 2306 and / or the API registrar 404 can access the properties associated with each of the multiple environments and determine how to best deploy the microservices that make up the service 2216 across any available environment to best meet the deployment criteria of the service 2216. This not only optimizes the operation of the service 2216 itself, but also optimizes the use of container platform resources. For example, a deployment standard for optimizing latency reduces the number of inter-environment calls between environments and minimizes latency in the service itself. Deployment standards that optimize security place microservices that have strict security requirements in the most secure environment, but allow microservices that are less stringent in security requirements to be placed on more efficient servers, thereby reducing the processing and resource overhead associated with security functions that do not require such microservices.

[0129] Fig.24 A flow chart of a method for optimizing service deployment across multiple computing environments according to some embodiments is illustrated. The method may include receiving a service including multiple containerized microservices (2401). The services in the microservices may be as described above in Figure 22-Figure 23. The service may be received by a scheduler, an orchestration platform, and / or an API registrar for deployment. The method may also include receiving deployment criteria for deploying services in multiple environments (2403). As described above, the multiple environments may be physically separate environments and have different operating characteristics. Therefore, the method may also include accessing the characteristics of the multiple environments (2405). The method may also include deploying multiple microservices across multiple environments based on the characteristics of the multiple environments and the deployment criteria of the services (2407). An example of how multiple microservices may be deployed across multiple environments is described in more detail below.

[0130] Fig.25 A diagram of service standards and environment / microservice attributes according to some embodiments is illustrated. Service 2216 may include multiple microservices as described above. In addition, service 2216 may be associated with one or more deployment standards 2502. In some embodiments, deployment standards 2502 may include a list of options that include different aspects of operating service 2216 that can be optimized through various deployment strategies in the container platform. For example, in Fig.25 In the example embodiment, criteria 2502 includes a list of check boxes for options that can be selected by a developer prior to deploying service 2216. The scheduler and / or API registrar can then access predetermined code sequences stored therein that can perform deployment of service 2216 according to the selected criteria 2502. In some embodiments, multiple selections in criteria 2502 can be selected, and the overall optimization process can optimize the deployment to balance one or more criteria 2502 that have been selected.

[0131] In addition to the overall criteria 2502 for services 2216, each microservice in services 2216 may also have one or more attributes 2510 that provide values ​​associated with each criterion 2502 specified for services 2216. The value associated with each of these attributes 2510 may characterize how the associated microservice should be evaluated according to the criteria 2502. For example, for a criterion that specifies that the deployment of service 2216 should be optimized for security issues, the security attribute of the microservice may include a value that characterizes the relative security requirements of the microservice compared to other microservices in services 2216. In another example, for a criterion that specifies that the deployment of service 2216 should be optimized for latency, the latency attribute of the microservice may characterize the execution latency of the associated microservice relative to other microservices in services 2216. In another example, for a criterion that specifies that the deployment of service 2216 should be optimized for colocation on the same computing environment, the value of the colocation attribute of the microservice may characterize the inter-service connection with other microservices, such as the number or identity of other services that call this microservice or are called by this microservice. In another example, for a criterion specifying that deployment of a service 2216 should be optimized for availability, the value of an availability attribute of a microservice can characterize the extent to which the microservice is exposed to front-end requests relative to back-end processing. In addition to these examples, any other criterion specifying how deployment of a service can be optimized can correspond to an attribute of each microservice in the service with associated values ​​characterizing how the microservice can be placed in various environments to optimize deployment according to the criterion.

[0132] As described above, the container platform may include multiple environments, such as a first environment 2302 and a second environment 2304. Note that the use of these two environments is provided only as an example and is not meant to be limiting. Other embodiments may include any type of computing environment with any number of hardware platforms extending beyond cloud deployment and on-premises deployment. Regardless of the number of environments, each environment may include a set of attributes 2504, 2506, with the attributes being accompanied by accompanying values ​​that characterize how the environment is related to the corresponding criteria for optimizing deployment. For example, for the criterion of minimizing cost, the corresponding cost attribute of the first environment 2302 may characterize the cost of deploying microservices to the first environment 2302 relative to deploying microservices to other environments. In another example, for the criterion of specifying the availability of maximized services, the corresponding availability attribute of the first environment 2302 may characterize the availability of the first environment 2302 relative to other environments in the container platform. Other similar examples may include attributes that characterize the latency of microservices operating on the environment, the security level of the environment, and any other operational characteristics of the computing environment.

[0133] The API registrar 404 and / or the scheduler 2306 may receive in the container platform the criteria 2502 for deploying the service 2216, the attributes 2510 of each microservice in the service 2216, and / or the attributes of each of the operating environments 2302, 2304, etc. Then, the scheduler 2304 and / or the API registrar 404 may match the microservice to the computing environment by matching the attributes specified by the criteria 2502. For example, for a criteria specifying security optimization, a microservice with a high security requirement value may be matched to an environment with a high security rating value, while a microservice with a low security requirement value may be matched to a computing environment with a lower security rating value. When multiple criteria 2502 are specified for optimization during deployment, the API registrar 404 and / or the container platform 2306 may rank each criterion 2502 and use a weighted combination of values ​​to minimize a cost formula, where a variable represents the location of each microservice to be deployed. The cost formula may be minimized to produce an optimized deployment mapping for each microservice in the service 2216, which specifies a selected computing environment for each microservice. A specific example of how this deployment optimization can be calculated in practice is described in detail below.

[0134] Fig.26 An example of service deployment optimized to minimize operating costs according to some embodiments is illustrated. When the scheduler 2306 and / or the API registrar deploys the service 2216, a cost criterion may be selected and the properties of each microservice may be analyzed. Next, the properties of each of the computing environments 2302 and 2304 may also be analyzed, and the deployment of the microservices across the computing environments 2302 and 2304 may be optimized accordingly. For example, when analyzing the properties of the microservices, it may be determined that the values ​​of the properties of the microservices 2214 and 2212 may specify low-cost values. This may indicate that these microservices 2214 and 2212 may have a small memory and / or processing footprint, which may cost less to deploy to the cloud platform of the first environment 2302. Note that other examples may use other metrics (such as the number of requests received, bandwidth requirements, etc.) to determine the cost. Because these services may cost relatively little to deploy to a cloud environment, the API registrar 404 and / or the scheduler 2306 may select the first environment 2302 for the microservices 2214 and 2212.

[0135] In contrast, the values ​​of the cost attributes of microservices 2210, 2206, 2202, 2208, and 2204 may indicate relatively high cost values ​​for deployment on a cloud platform. Therefore, API registrar 404 and / or scheduler 2306 may match these high cost values ​​with the attributes of a second environment 2304 corresponding to an on-premises computing platform. Second environment 2304 may have a high value for its cost attribute, indicating that a high-cost microservice should be deployed thereon.

[0136] After matching the microservices to the computing environment based on the property values ​​corresponding to the specified deployment criteria, the API registrar 404 and / or the scheduler 2306 can deploy the individual microservices to the selected computing environment and provide an endpoint 2218 for accessing the overall service. As described above, the API registrar 404 can provide a stable endpoint for the overall service by binding the endpoint to a set of one or more API functions defined by the API definition file uploaded to the API registrar 404. In an embodiment without the API registrar 404, the scheduler 2306 can deploy the microservices in a similar manner and provide the endpoint 2218 to be available for HTTP service calls.

[0137] Fig. 27 An example of service deployment optimized for service availability according to some embodiments is illustrated. Fig.26 As described in the example of , the API registrar 404 and / or the scheduler 2306 can receive one or more selected criteria for the deployment of the service, which specifies that the deployment should be optimized for the maximum availability of the service. The API registrar 404 and / or the scheduler 2306 can then match the values ​​of the attributes of the computing environments 2302, 2304 with the values ​​of the attributes in the microservices for the availability attributes in each. In this example, the microservice 2214 can implement a front-end interface with a relatively high availability value. This can match the internally deployed system of the second computing environment 2304, which can also have a high availability value indicating that the second environment 2304 is highly available.

[0138] In contrast, other microservices 2202, 2204, 2206, 2208, 2210, and 2212 may have relatively low attribute values ​​compared to microservice 2214, indicating that high availability of these microservices is not essential for the overall service to be highly available. This attribute value may match the second computing environment 2302 for the cloud platform that may not have as high an availability rating as the second environment 2304. The API registrar 404 and / or the scheduler 2306 may then deploy each of the microservices to their corresponding selected computing environments and provide endpoints 2218 for the overall service.

[0139] Fig.28An example of service deployment optimized for security issues according to some embodiments is illustrated. In this example, the API registrar 404 and / or the scheduler 2306 can receive microservices that define the overall service for deployment, together with the standard that specifies that the deployment should be optimized to match the security of the computing environment with the security requirements of each microservice. In order to achieve this deployment optimization, the API registrar 404 and / or the scheduler 2306 can match the value of the security attribute of each microservice with the corresponding security value rating of each of the computing environments 2302 and 2304. In this example, the first computing environment 2302 for the cloud platform can have a relatively high value rating for the security attribute, which indicates that the cloud platform can provide better security than other computing environments. Similarly, microservices 2202 and 2204 can also have relatively high value requirements for security attributes, indicating that they process sensitive data that require high security protection levels. The API registrar 404 and / or the scheduler 2306 can match these relatively high values ​​for security attributes and select the first computing environment 2302 for microservices 2202 and 2204.

[0140] Similarly, the security rating of the second computing environment 2304 for the internally deployed platform may be lower than the security rating of the first computing environment 2302. Therefore, if the value requirements of microservices 2206, 2208, 2210, 2212, and 2214 are relatively lower than the value requirements of microservices 2202, 2204, they may be matched with the second computing environment 2304. After making these determinations, the API registrar 404 and / or the scheduler 2306 may deploy each microservice to its selected computing environment and provide a stable endpoint 2218 for the overall service.

[0141] Fig.29 An example of a service deployment optimized for processing speed according to some embodiments is illustrated. The speed criteria may be similar to the latency criteria for a service. The API registrar 404 and / or the scheduler 2306 may receive microservices that define an overall service along with criteria that specify that the deployment should be optimized for processing speed. The speed attribute of the first computing environment 2302 may indicate that the first computing environment 2302 has fewer available computing resources than other environments in the container platform. Therefore, the first computing environment 2302 may match microservices 2202, 2204, and 2208 that have relatively low values ​​for their speed attributes, indicating that they do not require relatively large amounts of processing power to operate efficiently.

[0142] In addition, the API registrar 404 and / or the scheduler 2306 can determine that the speed attribute of the second computing environment 2304 is relatively high, indicating that the second computing environment 2304 has more available processing resources than other environments in the container platform. Therefore, the second computing environment 2304 can be matched with microservices 2206, 2210, 2212, and 2214 having speed attribute values ​​indicating that they require relatively large amounts of processing resources. Each microservice can then be deployed by the API registrar 404 and / or the scheduler 2306, and an endpoint 2218 can be provided for the overall service.

[0143] Fig.30 An example of a service deployment that is optimized simultaneously according to multiple criteria according to some embodiments is illustrated. In this example, the criteria accompanying the service may indicate that the deployment should be optimized to minimize calls made between different computing environments and maximize processing speed. Typically, minimizing microservice calls between computing environments will be best achieved by placing all microservices on a single computing environment. However, by specifying additional criteria, the deployment can also match the processing requirements of the microservices to the processing capabilities of the computing environment.

[0144] For example, by matching attribute values ​​as described above, the API registrar 404 and / or the scheduler 2306 can match the processing requirements of the microservices 2202, 2204, and 2208 with the processing capabilities of the first computing environment 2302. Similarly, the API registrar 404 and / or the scheduler 2306 can match the processing requirements of the microservices 2206, 2210, 2212, and 2214 with the processing capabilities of the second computing environment 2304. However, instead of deploying these microservices to the selected computing environment, further optimizations can be performed to co-locate microservices with service call patterns that can be grouped together. For example, microservices 2202, 2204, 2206, and 2208 all exchange multiple inter-service calls between each other. In order to minimize the number of cross-environment service calls, microservice 2206 can be moved from the second computing environment 2304 to the first computing environment 2302. This type of deployment balances the two deployment criteria of maximizing computing speed while minimizing cross-environment service calls. This example can also be slightly biased towards minimizing service calls across environments by giving this property a higher weight in the cost minimization function referenced above.

[0145] In the above example, optimization of microservice deployment has been performed during the initial deployment of the service to multiple computing environments. However, the same process used to optimize the initial deployment can be used to optimize subsequent deployments. For example, after the initial deployment, the criteria of the service can be changed by the developer, administrator, or an automated process running on the container platform. When this criteria changes, the same process described above can be performed again to match the values ​​of the environment and microservice properties to the new criteria selection. The microservices of the service can then be redeployed according to the new criteria.

[0146] Similarly, the values ​​of the attributes of the computing environment can change over time. For example, the first environment 2302 can receive a hardware upgrade that increases the amount of available processing resources. This can result in a corresponding increase in the attribute that characterizes the amount of computing resources available in the first environment 2302. The API registrar 404 and / or the scheduler 2306 can then determine whether the changed attribute corresponds to one of the criteria for service deployment. If the attribute does correspond to the deployment criteria, then the service can be redeployed for optimization based on the changed attribute value of the computing environment.

[0147] In addition to changing the property values ​​of the computing environment, the properties of the microservices in the service can also change over time. One of the advantages of using containerized microservices is that these microservices can be independently upgraded, replaced, and redeployed over time. If one or more microservices are upgraded for a service, new values ​​can be assigned to their corresponding properties if the performance or requirements of the microservices change after the upgrade / redeployment. As described above, the API registrar 404 and / or the scheduler 2306 can determine whether the property with the changed value corresponds to the deployment standard of the overall service. If so, the API registrar 404 and / or the scheduler 2306 can at least redeploy the affected microservices to optimize the deployment according to the changed property values.

[0148] In the above example, the attribute values ​​of the computing environment and the microservice are compared to each other in a relative manner. For example, if the first environment 2302 has a higher security rating value than the second environment 2304, then a microservice with a relatively higher security requirement than other microservices can be placed in the first environment 2302. The security requirements represented by the values ​​of the security attributes can be relatively compared between the microservices in the service, so that the microservice with higher requirements can be deployed to the first environment. This relative comparison can be performed by using an absolute threshold. For example, a predetermined threshold can be used to divide the values ​​of any attribute into various groups. In some embodiments, the microservices can be clustered into multiple groups corresponding to the number of computing environments. Fig.30For example, microservices 2202, 2204, 2206, 2208 can be clustered together by attribute values ​​to form a first group, while microservices 2210, 2212, and 2214 can be clustered together by attribute values ​​to form a second group. The clustering algorithm can find natural separations in the attribute values ​​to form these groups, and the number of groups can be less than or equal to the number of available computing environments. Each of these cluster groups can then be matched with a computing environment ranked by attribute value.

[0149] Each method described herein can be realized by a special-purpose computer system. Each step of these methods can be automatically performed by a computer system, and / or can be provided with input / output related to a user. For example, a user can provide input for each step in the method, and each of these inputs can be in response to a specific output requesting such input, wherein the output is generated by a computer system. Each input can be received in response to a corresponding request output. In addition, the input can be received from a user, received from another computer system as a data stream, retrieved from a memory location, retrieved through a network, requested from a web service, etc. Similarly, the output can be provided to a user, provided to another computer system as a data stream, stored in a memory location, sent through a network, provided to a web service, etc. In short, each step of the method described herein can be performed by a computer system, and can be related to a computer system and any number of inputs, outputs and / or requests from a computer system, which can be related to or may not be related to a user. Those steps that can be referred to as not involving a user are automatically performed by a computer system without human intervention. Therefore, it will be understood from this disclosure that each step of each method described herein can be modified to include input and output to and from a user, or can be completed automatically by a computer system without human intervention, with any determination made by a processor. In addition, some embodiments of each method described herein can be implemented as a set of instructions stored on a tangible, non-transitory storage medium to form a tangible software product.

[0150] Fig.31 A simplified diagram of a distributed system 3100 that can interact with any of the above-described embodiments is depicted. In the illustrated embodiment, the distributed system 3100 includes one or more client computing devices 3102, 3104, 3106, and 3108 that can be configured to execute and operate client applications, such as web browsers, proprietary clients (e.g., Oracle Forms), etc., over one or more networks 3110. A server 3112 can be communicatively coupled to remote client computing devices 3102, 3104, 3106, and 3108 via the network 3110.

[0151] In various embodiments, the server 3112 may be adapted to run one or more services or software applications provided by one or more components of the system. In some embodiments, these services may be provided as web-based services or cloud services, or provided to users of client computing devices 3102, 3104, 3106, and / or 3108 under a software as a service (SaaS) model. Users operating client computing devices 3102, 3104, 3106, and / or 3108 may in turn utilize one or more client applications to interact with the server 3112 to utilize the services provided by these components.

[0152] In the configuration depicted in the figure, software components 3118, 3120, and 3122 of system 3100 are shown as being implemented on server 3112. In other embodiments, one or more components of system 3100 and / or the services provided by these components may also be implemented by one or more of client computing devices 3102, 3104, 3106, and / or 3108. Then, a user operating the client computing device can use the services provided by these components using one or more client applications. These components may be implemented with hardware, firmware, software, or a combination thereof. It should be appreciated that various system configurations are possible, which may be different from distributed system 3100. The embodiment shown in the figure is therefore an example of a distributed system for implementing an embodiment system, and is not intended to be limiting.

[0153] Client computing devices 3102, 3104, 3106, and / or 3108 may be portable handheld devices (e.g., Cellular phone, computing tablets, personal digital assistants (PDAs), or wearable devices (e.g., Google head mounted display), running software such as Microsoft Windows and / or various mobile operating systems (such as iOS, Windows Phone, Android, BlackBerry 10, Palm OS, etc.), and enable Internet, email, short message service (SMS), or other communication protocols. The client computing device may be a general-purpose personal computer, including, for example, a computer running various versions of Microsoft Apple The client computing device may be a personal computer and / or laptop computer running a variety of commercially available or any workstation computer running any operating system of a UNIX-like operating system (including but not limited to various GNU / Linux operating systems, such as, for example, Google Chrome OS). Alternatively or additionally, client computing devices 3102, 3104, 3106, and 3108 may be any other electronic device capable of communicating over network(s) 3110, such as a thin client computer, an Internet-enabled gaming system (e.g., with or without A gesture input device such as a Microsoft Xbox game console) and / or a personal messaging device.

[0154] Although the exemplary distributed system 3100 is shown with four client computing devices, any number of client computing devices may be supported. Other devices (such as devices with sensors, etc.) may interact with the server 3112.

[0155] The network(s) 3110 in the distributed system 3100 may be any type of network familiar to those skilled in the art that may support data communications using any of a variety of commercially available protocols, including but not limited to TCP / IP (Transmission Control Protocol / Internet Protocol), SNA (Systems Network Architecture), IPX (Internetwork Packet Exchange), AppleTalk, and the like. Merely by way of example, the network(s) 3110 may be a local area network (LAN), such as a LAN based on Ethernet, Token Ring, and the like. The network(s) 3110 may be a wide area network and the Internet. It may include virtual networks, including but not limited to virtual private networks (VPNs), intranets, extranets, public switched telephone networks (PSTNs), infrared networks, wireless networks (e.g., in accordance with the Institute of Electrical and Electronics Engineers (IEEE) 802.11 protocol suite, and / or any other wireless protocol); and / or any combination of these and / or other networks.

[0156] Server 3112 may include one or more general-purpose computers, dedicated server computers (including, by way of example, PC (personal computer) servers, Servers, mid-size servers, mainframe computers, rack-mounted servers, etc.), server farms, server clusters, or any other suitable arrangement and / or combination. In various embodiments, server 3112 may be adapted to run one or more services or software applications described in the foregoing disclosure. For example, server 3112 may correspond to a server for performing the above-described processing according to an embodiment of the present disclosure.

[0157] Server 3112 may run an operating system including any of the operating systems discussed above, as well as any commercially available server operating system. Server 3112 may also run any of a variety of additional server applications and / or middle-tier applications, including HTTP (Hypertext Transfer Protocol) servers, FTP (File Transfer Protocol) servers, CGI (Common Gateway Interface) servers, Servers, database servers, etc. Exemplary database servers include, but are not limited to, those commercially available from Oracle, Microsoft, Sybase, IBM (International Business Machines), etc.

[0158] In some implementations, server 3112 may include one or more applications to analyze and integrate data feeds and / or event updates received from users of client computing devices 3102, 3104, 3106, and 3108. As examples, data feeds and / or event updates may include, but are not limited to: feed, Real-time updates and continuous data streams updated or received from one or more third-party information sources, which may include real-time events related to sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and business management applications), clickstream analysis tools, automobile traffic monitoring, etc. Server 3112 may also include one or more applications to display data feeds and / or real-time events via one or more display devices of client computing devices 3102, 3104, 3106, and 3108.

[0159] Distributed system 3100 may also include one or more databases 3114 and 3116. Databases 3114 and 3116 may reside in various locations. As an example, one or more of databases 3114 and 3116 may reside on a non-transient storage medium local to server 3112 (and / or residing in server 3112). Alternatively, databases 3114 and 3116 may be away from server 3112 and communicate with server 3112 via a network-based connection or a dedicated connection. In one set of embodiments, databases 3114 and 3116 may reside in a storage area network (SAN). Similarly, any necessary files for executing the functions that server 3112 has may be appropriately stored locally on server 3112 and / or stored remotely. In one set of embodiments, databases 3114 and 3116 may include a relational database suitable for storing, updating and retrieving data in response to commands in SQL format, such as a database provided by Oracle.

[0160] Fig.323200 by which services provided by one or more components of the embodiment system can be provided as cloud services. In the illustrated embodiment, the system environment 3200 includes one or more client computing devices 3204, 3206, and 3208 that can be used by a user to interact with a cloud infrastructure system 3202 that provides cloud services. The client computing device can be configured to operate a client application, such as a web browser, a proprietary client application (e.g., Oracle Forms), or some other application, that can be used by a user of the client computing device to interact with the cloud infrastructure system 3202 to use the services provided by the cloud infrastructure system 3202.

[0161] It should be appreciated that the cloud infrastructure system 3202 depicted in the figure may have other components in addition to the components depicted. In addition, the embodiment shown in the figure is only one example of a cloud infrastructure system that can be combined with embodiments of the present invention. In some other embodiments, the cloud infrastructure system 3202 may have more or fewer components than shown in the figure, may combine two or more components, or may have a different configuration or arrangement of components.

[0162] Client computing devices 3204 , 3206 , and 3208 may be similar devices to those described above with respect to 3102 , 3104 , 3106 , and 3108 .

[0163] Although the exemplary system environment 3200 is shown with three client computing devices, any number of client computing devices can be supported. Other devices such as devices with sensors and the like can interact with the cloud infrastructure system 3202.

[0164] Network(s) 3210 can facilitate data communication and exchange between clients 3204, 3206, and 3208 and cloud infrastructure system 3202. Each network can be any type of network familiar to those skilled in the art that can support data communication using any of a variety of commercially available protocols, including the protocols described above for network(s) 3110.

[0165] Cloud infrastructure system 3202 may include one or more computers and / or servers, which may include those described above with respect to server 3112 .

[0166] In certain embodiments, the services provided by the cloud infrastructure system may include many services available on demand to users of the cloud infrastructure system, such as online data storage and backup solutions, web-based email services, hosted office suites and document collaboration services, database processing, managed technical support services, etc. The services provided by the cloud infrastructure system can be dynamically scaled to meet the needs of users of the cloud infrastructure system. The specific instantiation of the services provided by the cloud infrastructure system is referred to as a "service instance" in this article. In general, any service available to users from a cloud service provider's system via a communication network (such as the Internet) is referred to as a "cloud service." Typically, in a public cloud environment, the servers and systems that make up the cloud service provider's system are different from the customer's own on-premises servers and systems. For example, a cloud service provider's system can host applications, and users can order and use applications on demand via a communication network such as the Internet.

[0167] In some examples, services in a computer network cloud infrastructure may include protected computer network access to storage devices, hosted databases, hosted web servers, software applications, or other services provided by a cloud provider to users, or as otherwise known in the art. For example, a service may include password-protected access to remote storage devices on the cloud over the Internet. As another example, a service may include a hosted relational database and scripting language middleware engine based on web services for private use by networked developers. As another example, a service may include access to an email software application hosted on a cloud provider's website.

[0168] In certain embodiments, the cloud infrastructure system 3202 may include a suite of application, middleware, and database service offerings delivered to customers in a self-service, subscription-based, elastically scalable, reliable, highly available, and secure manner. An example of such a cloud infrastructure system is the Oracle public cloud provided by the present assignee.

[0169] In various embodiments, the cloud infrastructure system 3202 may be adapted to automatically provision, manage, and track customer subscriptions to services provided by the cloud infrastructure system 3202. The cloud infrastructure system 3202 may provide cloud services via different deployment models. For example, services may be provided in accordance with a public cloud model, in which the cloud infrastructure system 3202 is owned by an organization that sells cloud services (e.g., owned by Oracle), and the services are available to the general public or businesses in different industries. As another example, services may be provided in accordance with a private cloud model, in which the cloud infrastructure system 3202 operates only for a single organization and may provide services to one or more entities within the organization. Cloud services may also be provided in accordance with a community cloud model, in which the cloud infrastructure system 3202 and the services provided by the cloud infrastructure system 3202 are shared by several organizations in a related community. Cloud services may also be provided in accordance with a hybrid cloud model, which is a combination of two or more different models.

[0170] In some embodiments, the services provided by cloud infrastructure system 3202 may include one or more services provided under a software as a service (SaaS) category, a platform as a service (PaaS) category, an infrastructure as a service (IaaS) category, or other service categories including hybrid services. A customer may subscribe to one or more services provided by cloud infrastructure system 3202 via a subscription order. Cloud infrastructure system 3202 then performs processing to provide the services in the customer's subscription order.

[0171] In some embodiments, the services provided by the cloud infrastructure system 3202 may include, but are not limited to, application services, platform services, and infrastructure services. In some examples, application services may be provided by the cloud infrastructure system via a SaaS platform. The SaaS platform may be configured to provide cloud services that fall into the SaaS category. For example, a SaaS platform may provide the ability to build and deliver on-demand application suites on an integrated development and deployment platform. The SaaS platform may manage and control the underlying software and infrastructure used to provide SaaS services. By utilizing the services provided by the SaaS platform, customers can utilize applications executed on the cloud infrastructure system. Customers can obtain application services without the need for customers to purchase separate licenses and support. A variety of different SaaS services may be provided. Examples include, but are not limited to, services that provide solutions for sales performance management, enterprise integration, and business flexibility to large organizations.

[0172] In some embodiments, platform services can be provided by a cloud infrastructure system via a PaaS platform. The PaaS platform can be configured to provide cloud services that fall into the PaaS category. Examples of platform services may include, but are not limited to, services that enable organizations (such as Oracle) to integrate existing applications on a shared public architecture and to fully utilize the shared services provided by the platform to build new applications. The PaaS platform can manage and control the underlying software and infrastructure for providing PaaS services. Customers can obtain PaaS services provided by a cloud infrastructure system without the need for customers to purchase separate licenses and support. Examples of platform services include, but are not limited to, Oracle Java Cloud Service (JCS), Oracle Database Cloud Service (DBCS), etc.

[0173] By utilizing the services provided by the PaaS platform, customers can adopt programming languages ​​and tools supported by the cloud infrastructure system, and can also control the deployed services. In some embodiments, the platform services provided by the cloud infrastructure system may include database cloud services, middleware cloud services (e.g., Oracle Fusion Middleware Services), and Java cloud services. In one embodiment, the database cloud service may support a shared service deployment model that enables organizations to pool database resources and supply databases as a service to customers in the form of a database cloud. In the cloud infrastructure system, the middleware cloud service can provide customers with a platform for developing and deploying various business applications, and the Java cloud service can provide customers with a platform for deploying Java applications.

[0174] A variety of different infrastructure services can be provided by IaaS platforms in cloud infrastructure systems. Infrastructure services facilitate the management and control of underlying computing resources (such as storage, networks, and other basic computing resources) for customers to utilize services provided by SaaS platforms and PaaS platforms.

[0175] In some embodiments, the cloud infrastructure system 3202 may also include infrastructure resources 3230 for providing resources for providing various services to customers of the cloud infrastructure system. In one embodiment, the infrastructure resources 3230 may include a combination of pre-integrated and optimized hardware (such as servers, storage devices, and networking resources) to perform services provided by the PaaS platform and the SaaS platform.

[0176] In some embodiments, resources in cloud infrastructure system 3202 can be shared by multiple users and dynamically reallocated as needed. In addition, resources can be allocated to users in different time zones. For example, cloud infrastructure system 3230 can enable a first group of users in a first time zone to utilize the resources of the cloud infrastructure system for a specified number of hours, and then enable the same resources to be reallocated to another group of users in a different time zone, thereby maximizing the utilization of the resources.

[0177] In certain embodiments, a plurality of internal shared services 3232 may be provided that are shared by different components or modules of the cloud infrastructure system 3202 and services provided by the cloud infrastructure system 3202. These internal shared services may include, but are not limited to: security and identity services, integration services, enterprise repository services, enterprise manager services, virus scanning and whitelisting services, high availability, backup and recovery services, cloud-enabled services, email services, notification services, file transfer services, and the like.

[0178] In some embodiments, cloud infrastructure system 3202 can provide comprehensive management of cloud services (e.g., SaaS, PaaS, and IaaS services) in the cloud infrastructure system. In one embodiment, cloud management functions can include capabilities for provisioning, managing, and tracking customer subscriptions received by cloud infrastructure system 3202, etc.

[0179] In one embodiment, as depicted in the figure, cloud management functionality may be provided by one or more modules, such as order management module 3220, order orchestration module 3222, order provisioning module 3224, order management and monitoring module 3226, and identity management module 3228. These modules may include or be provided using one or more computers and / or servers, which may be general purpose computers, dedicated server computers, server farms, server clusters, or any other suitable arrangement and / or combination.

[0180] In exemplary operation 3234, a customer using a client device (such as client device 3204, 3206, or 3208) may interact with cloud infrastructure system 3202 by requesting one or more services provided by cloud infrastructure system 3202 and placing a subscription order for one or more services offered by cloud infrastructure system 3202. In certain embodiments, the customer may access a cloud user interface (UI) (cloud UI 3212, cloud UI 3214, and / or cloud UI 3216) and place a subscription order via these UIs. The order information received by cloud infrastructure system 3202 in response to the customer placing an order may include information identifying the customer and one or more services offered by cloud infrastructure system 3202 to which the customer wants to subscribe.

[0181] After a customer places an order, order information is received via cloud UIs 3212 , 3214 , and / or 3216 .

[0182] At operation 3236, the order is stored in order database 3218. Order database 3218 may be one of several databases operated by cloud infrastructure system 3218 and in conjunction with other system elements.

[0183] At operation 3238, the order information is forwarded to order management module 3220. In some cases, order management module 3220 may be configured to perform billing and accounting functions related to the order, such as validating the order, and booking the order after validation.

[0184] At operation 3240, information about the order is transmitted to order orchestration module 3222. Order orchestration module 3222 can use the order information to orchestrate the provision of services and resources for the order placed by the customer. In some cases, order orchestration module 3222 can use the services of order provisioning module 3224 to orchestrate the provision of resources to support the subscribed services.

[0185] In certain embodiments, the order orchestration module 3222 enables management of the business processes associated with each order and applies business logic to determine whether the order should continue to be supplied. At operation 3242, upon receiving an order for a new subscription, the order orchestration module 3222 sends a request to the order supply module 3224 to allocate resources and configure those resources required to fulfill the subscription order. The order supply module 3224 enables allocation of resources for the services ordered by the customer. The order supply module 3224 provides an abstraction layer between the cloud services provided by the cloud infrastructure system 3200 and the physical implementation layer for supplying resources for providing the requested services. Therefore, the order orchestration module 3222 can be isolated from implementation details such as whether services and resources are actually supplied immediately or pre-provisioned and allocated / assigned only after request.

[0186] At operation 3244 , once the services and resources are provisioned, notifications of the provided services may be sent to customers on client devices 3204 , 3206 , and / or 3208 via the order provisioning module 3224 of the cloud infrastructure system 3202 .

[0187] At operation 3246, the order management and monitoring module 3226 may manage and track the customer's subscription order. In some cases, the order management and monitoring module 3226 may be configured to collect usage statistics for the services in the subscription order, such as the amount of storage used, the amount of data transferred, the number of users, and the amount of system uptime and system downtime.

[0188] In certain embodiments, cloud infrastructure system 3200 may include identity management module 3228. Identity management module 3228 may be configured to provide identity services, such as access management and authorization services in cloud infrastructure system 3200. In some embodiments, identity management module 3228 may control information about clients that wish to utilize services provided by cloud infrastructure system 3202. Such information may include information authenticating the identities of these clients and information describing which actions these clients are authorized to perform with respect to various system resources (e.g., files, directories, applications, communication ports, memory segments, etc.). Identity management module 3228 may also include management of descriptive information about each client and how and by whom the descriptive information may be accessed and modified.

[0189] Fig.33 An exemplary computer system 3300 in which various embodiments of the present invention may be implemented is shown. System 3300 may be used to implement any of the computer systems described above. As shown, computer system 3300 includes a processing unit 3304 that communicates with multiple peripheral subsystems via a bus subsystem 3302. These peripheral subsystems may include a processing acceleration unit 3306, an I / O subsystem 3308, a storage subsystem 3318, and a communication subsystem 3324. Storage subsystem 3318 includes a tangible computer readable storage medium 3322 and a system memory 3310.

[0190] The bus subsystem 3302 provides a mechanism for allowing the various components and subsystems of the computer system 3300 to communicate with each other by intention. Although the bus subsystem 3302 is schematically shown as a single bus, an alternative embodiment of the bus subsystem can utilize multiple buses. The bus subsystem 3302 can be any of several types of bus structures using any bus architecture in various bus architectures, including a memory bus or a memory controller, a peripheral bus, and a local bus. For example, this architecture can include an industrial standard architecture (ISA) bus, a microchannel architecture (MCA) bus, an enhanced ISA (EISA) bus, a video electronics standard association (VESA) local bus, and a peripheral component interconnect (PCI) bus, which can be implemented as a Mezzanine bus manufactured by the IEEE P1386.1 standard.

[0191] The processing unit 3304, which may be implemented as one or more integrated circuits (e.g., conventional microprocessors or microcontrollers), controls the operation of the computer system 3300. One or more processors may be included in the processing unit 3304. These processors may include single-core or multi-core processors. In certain embodiments, the processing unit 3304 may be implemented as one or more independent processing units 3332 and / or 3334, wherein a single-core or multi-core processor is included in each processing unit. In other embodiments, the processing unit 3304 may also be implemented as a quad-core processing unit formed by integrating two dual-core processors into a single chip.

[0192] In various embodiments, the processing unit 3304 can execute various programs in response to the program code and can maintain multiple concurrently executed programs or processes. At any given time, some or all of the program code to be executed may reside in (one or more) processors 3304 and / or in the storage subsystem 3318. Through appropriate programming, (one or more) processors 3304 can provide the various functions described above. The computer system 3300 can additionally include a processing acceleration unit 3306, which can include a digital signal processor (DSP), a special processor, and the like.

[0193] I / O subsystem 3308 may include user interface input devices and user interface output devices. User interface input devices may include a keyboard, a pointing device such as a mouse or trackball, a touch pad or touch screen incorporated into a display, a scroll wheel, a click wheel, a dial, buttons, switches, a keyboard, an audio input device with a voice command recognition system, a microphone, and other types of input devices. User interface input devices may include, for example, motion sensing and / or gesture recognition devices such as Microsoft Motion sensors that enable users to control devices such as Microsoft 360 game controller. The user interface input device may also include an eye gesture recognition device, such as detecting eye activity from the user (e.g., a "wink" when taking a picture and / or making a menu selection) and translating eye gestures to the input device (e.g., Google ) in Google In addition, the user interface input device may include a user interface that enables the user to communicate with the voice recognition system (e.g., Navigator) interactive voice recognition sensing device.

[0194] The user interface input device may also include, but is not limited to, a three-dimensional (3D) mouse, a joystick or pointing stick, a game board and a drawing board and audio / video equipment, such as a speaker, a digital camera, a digital video camera, a portable media player, a webcam, an image scanner, a fingerprint scanner, a barcode reader 3D scanner, a 3D printer, a laser rangefinder, and a sight tracking device. In addition, the user interface input device may include, for example, a medical imaging input device, such as a computer tomography, a magnetic resonance imaging, a positron emission tomography, a medical ultrasound device. The user interface input device may also include, for example, an audio input device such as a MIDI keyboard, a digital musical instrument, etc.

[0195] User interface output devices may include a display subsystem, indicator lights, or non-visual displays such as audio output devices, etc. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as using a liquid crystal display (LCD) or plasma display, a projection device, a touch screen, etc. In general, the use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computer system 3300 to a user or other computers. For example, user interface output devices may include, but are not limited to, various display devices that visually convey text, graphics, and audio / video information, such as monitors, printers, speakers, headphones, car navigation systems, plotters, voice output devices, and modems.

[0196] Computer system 3300 may include a storage subsystem 3318 containing software elements, shown as currently located in system memory 3310. System memory 3310 may store program instructions that may be loaded and executed on processing unit 3304, as well as data generated during execution of these programs.

[0197] Depending on the configuration and type of computer system 3300, system memory 3310 may be volatile (such as random access memory (RAM)) and / or non-volatile (such as read-only memory (ROM), flash memory, etc.). RAM typically contains data and / or program modules that are immediately accessible to and / or currently being operated and executed by processing unit 3304. In some implementations, system memory 3310 may include multiple different types of memory, such as static random access memory (SRAM) or dynamic random access memory (DRAM). In some implementations, a basic input / output system (BIOS) containing basic routines that help transfer information between elements of computer system 3300, such as during startup, may typically be stored in ROM. By way of example, but not limitation, system memory 3310 also illustrates application programs 3312, which may include client applications, web browsers, middle-tier applications, relational database management systems (RDBMS), etc., program data 3314, and an operating system 3316. By way of example, operating system 3316 may include various versions of Microsoft Apple and / or Linux operating systems, various commercially available or UNIX-like operating systems (including but not limited to various GNU / Linux operating systems, Google OS, etc.) and / or such as iOS, Phone, OS, 10OS and OS operating system such as mobile operating system.

[0198] Storage subsystem 3318 may also provide a tangible computer-readable storage medium for storing basic programming and data structures that provide the functionality of some embodiments. Software (programs, code modules, instructions) that provide the above-described functionality when executed by the processor may be stored in storage subsystem 3318. These software modules or instructions may be executed by processing unit 3304. Storage subsystem 3318 may also provide a repository for storing data used in accordance with the present invention.

[0199] The storage subsystem 3300 may also include a computer-readable storage media reader 3320 that may be further connected to a computer-readable storage medium 3322. Together with and, optionally in conjunction with the system memory 3310, the computer-readable storage medium 3322 may comprehensively represent remote, local, fixed, and / or removable storage devices plus storage media for temporarily and / or more permanently containing, storing, transmitting, and retrieving computer-readable information.

[0200] The computer-readable storage medium 3322 containing the code or portions of the code may also include any suitable media known or used in the art, including storage media and communication media, such as, but not limited to, volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and / or transmission of information. This may include tangible computer-readable storage media, such as RAM, ROM, electrically erasable programmable ROM (EEPROM), flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage device, magnetic cassette, magnetic tape, magnetic disk storage device or other magnetic storage device, or other tangible computer-readable medium. This may also include non-tangible computer-readable media, such as data signals, data transmissions, or any other medium that can be used to send the desired information and can be accessed by the computing system 3300.

[0201] As examples, computer-readable storage media 3322 may include a hard disk drive that reads from or writes to a non-removable nonvolatile magnetic media, a disk drive that reads from or writes to a removable nonvolatile disk, and a removable nonvolatile optical disk such as a CD ROM, a DVD, and a hard disk drive that reads from or writes to a removable nonvolatile disk. Computer readable storage media 3322 may include, but is not limited to, an optical drive that reads or writes to a removable non-volatile optical disk (disc or other optical media). The computer readable storage medium 3322 may include a solid-state drive (SSD) based on non-volatile memory (such as a flash memory-based SSD, an enterprise flash drive, a solid-state ROM, etc.), a volatile memory-based SSD (such as a solid-state RAM, a dynamic RAM, a static RAM, a DRAM-based SSD, a magnetoresistive RAM (MRAM) SSD), and a hybrid SSD using a combination of a DRAM-based SSD and a flash memory-based SSD. The disk drive and its associated computer-readable media may provide non-volatile storage of computer-readable instructions, data structures, program modules, and other data for the computer system 3300.

[0202] The communication subsystem 3324 provides an interface to other computer systems and networks. The communication subsystem 3324 is used as an interface for receiving data from other systems and sending data from the computer system 3300 to other systems. For example, the communication subsystem 3324 can enable the computer system 3300 to be connected to one or more devices via the Internet. In some embodiments, the communication subsystem 3324 may include a radio frequency (RF) transceiver component, a global positioning system (GPS) receiver component and / or other components for accessing wireless voice and / or data networks (for example, using cellular phone technology, advanced data network technologies such as 3G, 4G or EDGE (Enhanced Data Rate for Global Evolution), WiFi (IEEE 802.11 series standards), or other mobile communication technologies, or any combination thereof). In some embodiments, as an addition or replacement of a wireless interface, the communication subsystem 3324 can provide a wired network connection (for example, Ethernet).

[0203] In some embodiments, the communication subsystem 3324 may also receive input communications in the form of structured and / or unstructured data feeds 3326 , event streams 3328 , event updates 3330 , and the like on behalf of one or more users who may use the computer system 3300 .

[0204] As an example, the communication subsystem 3324 may be configured to receive data feeds 3326 in real time from users of a social network and / or other communication services, such as feed, Updates, web feeds such as Rich Site Summary (RSS) feeds, and / or real-time updates from one or more third-party information sources.

[0205] Additionally, the communication subsystem 3324 may also be configured to receive data in the form of a continuous data stream, which may include event streams 3328 and / or event updates 3330, which may be continuous or unbounded in nature, real-time events without explicit termination. Examples of applications that generate continuous data may include, for example, sensor data applications, financial quote machines, network performance measurement tools (e.g., network monitoring and traffic management applications), clickstream analysis tools, automobile traffic monitoring, and the like.

[0206] The communication subsystem 3324 may also be configured to output structured and / or unstructured data feeds 3326, event streams 3328, event updates 3330, etc. to one or more databases, which may be in computer communication with one or more streaming data source computers coupled to the computer system 3300.

[0207] Computer system 3300 can be one of various types, including a handheld portable device (e.g., Cellular phone, computing tablets, PDAs), wearable devices (e.g., Google head mounted display), PC, workstation, mainframe, kiosk, server rack, or any other data processing system.

[0208] Due to the ever-changing nature of computers and networks, the description of the computer system 3300 depicted in the figure is only intended as a specific example. Many other configurations with more or fewer components than the system depicted in the figure are possible. For example, customized hardware may also be used and / or specific elements may be implemented with hardware, firmware, software (including applets), or a combination thereof. In addition, connections to other computing devices such as network input / output devices may also be employed. Based on the disclosure and teachings provided herein, one of ordinary skill in the art will recognize other ways and / or methods of implementing various embodiments.

[0209] In the foregoing description, for the purpose of explanation, many specific details are set forth in order to provide a thorough understanding of various embodiments of the present invention. However, it is clear to those skilled in the art that embodiments of the present invention may be practiced without some of these specific details. In other cases, well-known structures and devices are shown in block diagram form.

[0210] The above description provides exemplary embodiments only and is not intended to limit the scope, applicability or configuration of the present disclosure. More specifically, the foregoing description of the exemplary embodiments will provide an enabling description for implementing the exemplary embodiments for those skilled in the art. It should be understood that various changes may be made to the functions and arrangements of the elements without departing from the spirit and scope of the present invention as set forth in the appended claims.

[0211] Specific details are given in the foregoing description to provide a thorough understanding of the embodiments. However, it will be appreciated by those of ordinary skill in the art that the embodiments may be practiced without these specific details. For example, circuits, systems, networks, processes, and other components may have been shown as components in block diagram form so as not to obscure the embodiments with unnecessary detail. In other cases, well-known circuits, processes, algorithms, structures, and techniques may have been shown without unnecessary detail so as not to obscure the embodiments.

[0212] Furthermore, it should be noted that various embodiments may have been described as a process, which is depicted as a flow chart, a flow diagram, a structure diagram, or a block diagram. Although the flow chart may have described the operations as a sequential process, many operations may be performed in parallel or simultaneously. In addition, the order of the operations may be rearranged. A process terminates when its operations are completed, but there may be additional steps not included in the figure. A process may correspond to a method, a function, a program, a subroutine, a subprogram, etc. When a process corresponds to a function, its termination may correspond to the function returning to the calling function or the main function.

[0213] The term "computer-readable medium" includes, but is not limited to, portable or fixed storage devices, optical storage devices, wireless channels, and various other media capable of storing, containing, or carrying (one or more) instructions and / or data. A code segment or machine executable instruction can represent any combination of a process, function, subroutine, program, routine, subroutine, module, software package, class, or instruction, data structure, or program statement. A code segment can be coupled to another code segment or hardware circuit by transmitting and / or receiving information, data, independent variables, parameters, or memory contents. Information, independent variables, parameters, data, etc. can be transmitted, forwarded, or sent via any suitable means, including memory sharing, message passing, token passing, network transmission, etc.

[0214] In addition, the embodiments may be implemented by hardware, software, firmware, middleware, microcode, hardware description language, or any combination thereof. When implemented in software, firmware, middleware, or microcode, the program code or code segments for performing the necessary tasks may be stored in a machine-readable medium. (One or more) processors may perform the necessary tasks.

[0215] In the foregoing description, various aspects of the present invention have been described with reference to their specific embodiments, but it will be appreciated by those skilled in the art that the present invention is not limited thereto. Each feature and aspect disclosed above may be used alone or in combination. In addition, without departing from the broader spirit and scope of this specification, the embodiments may be used in any number of environments and applications other than those described herein. Accordingly, this specification and the accompanying drawings should be considered to be illustrative rather than restrictive.

[0216] In addition, for the purpose of illustration, method is described in a particular order. It should be appreciated that, in an alternative embodiment, the method can be performed in a sequence different from the described order. It should also be appreciated that the above method can be performed by hardware components, or can be implemented with a sequence of machine executable instructions, which can be used to make a machine (such as a general or special processor or logic circuit programmed with instructions) perform the method. These machine executable instructions can be stored in one or more machine-readable media, such as CD-ROM or other types of optical disks, floppy disks, ROM, RAM, EPROM, EEPROM, magnetic cards or optical cards, flash memory or other types of machine-readable media suitable for storing electronic instructions. Alternatively, the method can be performed by a combination of hardware and software.

Claims

1. A method for distributing microservice containers for services across multiple computing environments, the method comprising: receiving a service built from a plurality of containerized microservices to be deployed in a container platform, wherein the container platform includes a plurality of computing environments; receiving a deployment criterion for deploying a service in a container platform, wherein each of the plurality of containerized microservices includes attributes corresponding to the deployment criterion; accessing characteristics of the plurality of computing environments; and Based on the deployment criteria and the characteristics of the multiple computing environments, the multiple containerized microservices are deployed across the multiple computing environments, wherein the values ​​of the microservice attributes are matched with the characteristics of the multiple computing environments to determine on which computing environment of the multiple computing environments each individual containerized microservice of the multiple containerized microservices is deployed.

2. The method of claim 1, wherein the plurality of computing environments comprises a cloud computing environment.

3. The method of claim 1, wherein the plurality of computing environments comprises an on-premises computing environment.

4. The method of claim 1, wherein at least one of the plurality of containerized microservices comprises a plurality of containers in a single container pod.

5. The method of claim 1, wherein at least one of the plurality of containerized microservices comprises a single container including the plurality of microservices in a single container pod.

6. The method of claim 1, wherein the deployment criteria includes an indication that service deployment should be optimized for security.

7. The method of claim 1, wherein the deployment criteria includes an indication that service deployment should be optimized for availability.

8. The method of claim 1, wherein the deployment criteria includes an indication that service deployment should be optimized for cost.

9. The method of claim 1, wherein the deployment criteria includes an indication that service deployment should be optimized for latency.

10. The method of claim 1, wherein the deployment criteria includes an indication that service deployment should be optimized for co-location of containerized microservices.

11. A non-transitory computer-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations comprising: receiving a service built from a plurality of containerized microservices to be deployed in a container platform, wherein the container platform includes a plurality of computing environments; receiving a deployment criterion for deploying a service in a container platform, wherein each of the plurality of containerized microservices includes attributes corresponding to the deployment criterion; accessing characteristics of the plurality of computing environments; and Based on the deployment criteria and the characteristics of the multiple computing environments, the multiple containerized microservices are deployed across the multiple computing environments, wherein the values ​​of the microservice attributes are matched with the characteristics of the multiple computing environments to determine on which computing environment of the multiple computing environments each individual containerized microservice of the multiple containerized microservices is deployed.

12. The non-transitory computer-readable medium of claim 11, wherein the plurality of containerized microservices are deployed by a container platform scheduler.

13. A system comprising: one or more processors; as well as one or more memory devices including instructions that, when executed by the one or more processors, cause the one or more processors to perform operations comprising: receiving a service built from a plurality of containerized microservices to be deployed in a container platform, wherein the container platform includes a plurality of computing environments; receiving a deployment criterion for deploying a service in a container platform, wherein each of the plurality of containerized microservices includes attributes corresponding to the deployment criterion; accessing characteristics of the plurality of computing environments; and Based on the deployment criteria and the characteristics of the multiple computing environments, the multiple containerized microservices are deployed across the multiple computing environments, wherein the values ​​of the microservice attributes are matched with the characteristics of the multiple computing environments to determine on which computing environment of the multiple computing environments each individual containerized microservice of the multiple containerized microservices is deployed.

14. The system of claim 13, wherein the plurality of containerized microservices are deployed by an API registrar.

15. The system of claim 14, wherein the API registrar is deployed as a service encapsulated in a container in the container environment.

16. The system of claim 14, wherein the API registrar is operable to: Services under development in an integrated development environment (IDE); and Services that have been deployed in the container environment.

17. The system of claim 14, wherein the API registrar maps service endpoints of the plurality of container pods to one or more API functions.

18. The system of claim 14, wherein the API registrar automatically generates a client library for calling a service to call the service.

Images