Microservices architecture

Abstract

The subject matter of the present invention is a "microservices architecture". A computing device comprising: a hardware computing platform; and logic for operating on the hardware computing platform configured to: receive a microservice instance registration for a microservice accelerator, wherein the registration comprises a microservice that the microservice accelerator is configured to provide and a microservice connectivity capability indicating an ability of the microservice instance to communicate directly with other instances of the same or different microservices; and record the registration in a microservice registration database.

Description

[0001] This application is a divisional application of patent application filed on June 28, 2018, with application number 201810687136.2 and invention title "Microservice Architecture". Technical Field

[0002] This disclosure generally relates to the field of cloud computing, and more specifically, but not exclusively, to systems and methods for microservice architectures. Background Technology

[0003] Modern computing practices have shifted away from hardware-specific computing and towards a "network is device" approach. A modern network can include a data center hosting a large number of general-purpose hardware server devices (enclosed in, for example, server racks and controlled by a hypervisor). Each hardware device can run one or more instances of virtual devices (such as workload servers or virtual desktops). Attached Figure Description

[0004] This disclosure is best understood by reading the following detailed description with reference to the accompanying drawings. It should be emphasized that, in accordance with standard practice in the art, the various features are not necessarily drawn to scale and are for illustrative purposes only. Where scale is shown explicitly or implicitly, it is merely to provide an illustrative example. In other embodiments, the dimensions of the various features may be arbitrarily increased or decreased for clarity of discussion.

[0005] Figure 1 This is a network-level diagram of a cloud service provider (CSP) based on one or more examples of this specification.

[0006] Figure 2 This is a block diagram of a data center based on one or more examples of this specification.

[0007] Figure 3 A block diagram showing the components of a computing platform according to one or more examples of this specification.

[0008] Figure 4 It is a block diagram of a microservice architecture based on one or more examples in this specification.

[0009] Figure 5 This is a flowchart illustrating methods for registering and using microservices, based on one or more examples in this specification.

[0010] Figure 6 This is a block diagram illustrating the initial setup of a microservice instance based on one or more examples in this specification.

[0011] Figure 7 It is based on one or more examples in this specification that can be considered as Figure 6 The diagram illustrates the operation of extended microservices.

[0012] Figure 8 This is a block diagram of a message service link based on one or more examples in this specification.

[0013] Figure 9 This is a block diagram of service discovery based on one or more examples in this specification.

[0014] Figure 10 This is a block diagram illustrating message forwarding according to one or more examples of this specification.

[0015] Figure 11 This is a block diagram of a load balancing engine based on one or more examples of this specification. Detailed Implementation

[0016] The following disclosure provides numerous different embodiments or examples for implementing various features of this disclosure. Specific examples of components and arrangements are described below to simplify this disclosure. These are undoubtedly merely examples and not intended to be limiting. Furthermore, reference numerals and / or letters may be repeated in various examples. Such repetition is for brevity and clarity and does not inherently define relationships between the various embodiments and / or configurations discussed. Different embodiments may have different advantages, and no particular advantage is required by any embodiment.

[0017] In modern data centers, functions previously performed by dedicated logical elements can now be more usefully considered in terms of logical functionality. For the sake of illustration only, in the context of Network Functions Virtualization (NFV), one hop in a service chain can provide Deep Packet Inspection (DPI). As a non-limiting example, other microservices may include encryption, decryption, compression, decompression, IP security (IPsec), accounting functions, and performance trackers.

[0018] In legacy network environments, the example DPI function can be implemented via a dedicated DPI hardware device, whose hardware ingress port is connected to the previous hop in the service chain and whose hardware egress port is connected to the next hop in the service chain.

[0019] These hard-coded network functions have been largely replaced by data centers in many cases, where features like DPI (Dedicated Portability Provider) can be provided in several different ways. For example, DPI functionality can be implemented on software that operates within virtual machines (VMs) that form virtual service appliances (instances of which can be generated on demand). However, in some deployments, even the availability of on-demand VMs may not be adequate. As data centers grow larger and traffic increases, latency and bandwidth become increasingly critical, and data center operators may want to avoid service functions becoming performance bottlenecks. Therefore, in many data centers, additional flexibility and speed are provided by providing certain functions separately.

[0020] For example, instead of provisioning VM DPI devices on demand, data centers can provide resource pools of multiple instances with highly optimized dedicated resources. The advantage of resource pools is that highly optimized resources can be shared across many different nodes. Resource pools, as non-limiting examples, can include elements such as compute nodes, memory (volatile or non-volatile), storage devices, application-specific integrated circuits (ASICs), system-on-a-chip (SoCs), or field-programmable gate arrays (FPGAs). These resources can be allocated on demand to compute nodes (which can be considered "composite nodes") to meet the needs of the data center. Therefore, resource pools can include multiple pre-provisioned devices optimized for specific tasks or various high-capacity resources that can be aggregated into such nodes. Such resource pools can be useful for hosting many different types of accelerators in a data center.

[0021] An example of a resource pool could be an FPGA pool. This could be a pool of FPGAs that can be configured and programmed on demand to provide specific functionality at or near hardware speed. Therefore, an FPGA pool can advantageously offer similar flexibility to that available through software resources, but with speeds similar to hardware resources alone. Thus, returning to the example of DPI devices, FPGAs from an FPGA pool could be allocated to DPI functionality and configured to provide DPI at very high speeds.

[0022] In cases where even higher speeds are required, true hardware resources can be provided. These could be, for example, ASICs, which are programmed to provide specific functionality at a much higher speed than what can be achieved using software.

[0023] A system programmer providing DPI (Dynamic Point Injection) can know which resources are available at design time and write the software accordingly. For example, if a system designer knows that an FPGA pool is available in a data center, he can write his software to discover available FPGA instances (e.g., via an organizer) and request that one or more instances of the FPGA be programmed with DPI functionality, and then hand over the actual DPI processing to the prepared FPGA. However, the flexible nature of data centers makes it possible to further refine the system even if the designer does not know at design time which resources will ultimately be available in the data center.

[0024] For example, consider the following scenario: a system programmer knows during design that his software will provide DPI functionality and preferably provides DPI at the highest possible speed in any given environment, but does not know (and does not need to know) the specific resources that will implement the DPI functionality.

[0025] Data centers may have a variety of available system resources, such as GPU arrays, multi-core CPUs, hardware accelerators, FPGAs, virtual devices, and many others. Any of these can perform the desired function or play a role in performing the desired function, and it is advantageous for the system software to use the “best available” resources rather than being tied to a specific resource.

[0026] In some cases, hardware and platform specialization can be detected and balanced at a low level within the software stack. However, this can come at the cost of the portability and maintenance of the drivers in the underlying hardware. Because applications are required to independently control the presence or absence of accelerators or other resources, systems programmers may get bogged down in the details of how the task is implemented (e.g., which resources will perform the task) rather than focusing on the task itself.

[0027] This specification provides systems and methods to mitigate this problem by providing so-called "microservices". Microservices refer to a framework for partitioning functionality in a highly configurable and scalable manner, which can seamlessly encapsulate desired functionality in wrappers without requiring system designers to know at design time how or on which resources the functionality will be implemented.

[0028] The systems and methods disclosed in this paper also address the scalability of hardware and software implementations for microservice instances. This paper describes a framework for implementing microservice discovery and its capabilities. Portability and maintainability are enhanced because the framework is adaptable to capabilities that will become available in the future, including across different vendors. The framework also significantly reduces latency by providing highly optimized service links.

[0029] As an example, the system optimizations disclosed in this paper span the operational flow of a distributed system built from diverse low-level components that are accessed via “wrapper” functionality rather than being addressed individually. The usefulness of microservices is further enhanced by automating and streamlining the flow of active messages into a chain enabled by low-latency microservices. This eliminates the need for request / response interactions, which introduce significant overhead in many instances.

[0030] As an example, a microservice application programming interface (API) is exposed to the host software. The host software designer does not need to understand or care about the implementation details of the services behind the microservice API. Instead, the microservice API provides standardized calls to various capabilities, including the types and formats of inputs and outputs. The microservice API then provides function calls to microservice drivers, which can (potentially in conjunction with an organizer) discover and / or allocate instances of various microservices in different forms, such as hardware accelerators, FPGAs, resource pools, CPUs, GPUs, or native software.

[0031] When instances of microservices or resources with microservice capabilities come online, they can register with the Service Discovery Function (SDF). The SDF maintains a catalog of available microservices, which can include mappings for translating standard microservice API calls into API calls usable by specific instances of the microservices. This architecture enables specialization of certain architectural capabilities, such as "block-in-the-cable" acceleration, FPGA feature sets enabled from processing cores, or processors optimized for highly specialized software purposes. These can be transparently integrated into the data center as needed.

[0032] When a microservice driver receives a request for a new microservice, it can query the SDF (Software Development Document) and identify the availability of the microservice instance. Note that this can include not only the availability of the currently running microservice instance, but also the availability of resources that can be prepared to provide the microservice. For example, an FPGA may be available, but may not yet be programmed to provide microservices. The SDF catalog can include configuration information, such as gate configurations for programming the FPGA to provide the desired microservice. The microservice driver can then query the SDF to determine if the FPGA is available to implement the microservice functionality and can receive appropriate mappings from the catalog for the functionality and the gate configurations for the FPGA. The microservice driver can then program the FPGA using the gate configurations, and once the FPGA is programmed, the microservice driver can begin forwarding calls to the FPGA via the standardized microservice API (which maps to a specific interface of that FPGA instance).

[0033] Similar processes can be used to prepare, for example, instances of virtual machines or virtual devices, software running on CPUs or GPUs, or to assign hardware accelerators or ASIC instances to microservices so that they can be used by that microservice.

[0034] This framework offers advantages over other solutions, such as the use of middleware to abstract away the details of instance calls. Such middleware can increase latency or overhead, reduce solution portability, and in some cases, inhibit the full expression of hardware capabilities. In contrast, the microservice architecture described in this specification dynamically discovers and prepares microservices as streams, with the opportunity to fully utilize the hardware and / or software capabilities of microservice instances. The microservice driver manipulates the transformation of generic function calls at the microservice API level into specific and optimized service calls for microservice instances.

[0035] Therefore, the task logic from various implementations of a function is isolated from its implementation details. This makes tasks agnostic to where and how a function is actually executed. As described below, this also automates the process of handling service chains, as multiple microservice instances of different types can be prepared and chained together to form a service chain without the need for each microservice instance to pass results upstream back to the VM or server. In some cases, this can eliminate many of the business processes required in a request-response framework. Therefore, microservice preparation is adaptable and highly optimized, and new microservices and microservice instances can be proliferated across data centers as accelerator functions.

[0036] The systems and methods for microservice architecture will now be described in more detail with reference to the accompanying drawings. It should be noted that certain reference numerals may be repeated throughout the drawings to indicate that specific devices or blocks are identical or substantially identical across the drawings. However, this is not intended to imply any specific relationship between the various embodiments disclosed. In some examples, a class of elements may be referred to by a specific reference numeral (“part 10”), while a separate kind or example of that class may be referred to by numerals with hyphens (“first specific part 10-1” and “second specific part 10-2”).

[0037] Figure 1 This is a network-level illustration of a data center 100 of a cloud service provider (CSP) 102 according to one or more examples in this specification. As a non-limiting example, CSP 102 may be a traditional enterprise data center, an enterprise "private cloud" or "public cloud" that provides services such as Infrastructure as a Service (IaaS), Platform as a Service (PaaS) or Software as a Service (SaaS).

[0038] CSP 102 can prepare a number of workload clusters 118, which can be a cluster of individual servers, blade servers, rack-mounted servers, or any other suitable server topology. In this illustrative example, two workload clusters 118-1 and 118-2 are shown, each providing rack-mounted servers 146 in a chassis 148.

[0039] Each server 146 can host an independent operating system and provide server functionality, or the servers can be virtualized, in which case they are under the control of a Virtual Machine Manager (VMM), hypervisor, and / or organizer, and can host one or more virtual machines, virtual servers, or virtual devices. These server racks can be co-located in a single data center or in data centers in different geographical locations. Depending on the contract, some servers 146 may be specifically dedicated to certain enterprise customers or tenants, while other servers may be shared.

[0040] Various devices within a data center can be interconnected via a switching structure 170, which may include one or more high-speed routing and / or switching devices. The switching structure 170 provides "north-south" traffic (e.g., traffic to and from a wide area network (WAN) such as the Internet) and "east-west" traffic (e.g., traffic across data centers). Historically, north-south traffic accounted for the majority of network traffic, but as World Wide Web services have become more complex and distributed, east-west traffic has increased. In many data centers, east-west traffic now constitutes the majority of traffic.

[0041] Furthermore, as the capacity of each server 146 increases, the workload can be further increased. For example, each server 146 can provide multiple processor sockets, each socket accommodating a processor with four to eight cores along with sufficient memory for each core. Therefore, each server can host a large number of virtual machines (VMs), each VM generating its own workload.

[0042] To accommodate the high volume of traffic in a data center, a high-capacity switching fabric 170 can be provided. In this example, the switching fabric 170 is shown as a “flat” network, where each server 146 may have a direct connection to a top-of-rack (ToR) switch 120 (e.g., a “star” configuration), and each ToR switch 120 is coupled to a core switch 130. This Layer 2 flat network architecture is shown as an illustrative example only. In other examples, other architectures may be used as non-limiting examples, such as a three-layer star or leaf ridge (also known as a “fat tree”) topology based on a “Clos” architecture, a center-radial topology, a mesh topology, a ring topology, or a 3-D mesh topology.

[0043] The architecture itself can be provided via any suitable interconnect. For example, each server 146 may include an architecture interface such as an Intel® Host Architecture Interface (HFI), a Network Interface Card (NIC), or another host interface. The host interface itself may be coupled to one or more processors via an interconnect or bus (such as PCI, PCIe, etc.), and in some cases, this interconnect bus may be considered part of the architecture 170.

[0044] Interconnect technologies can be provided through a single interconnect or a hybrid interconnect, where PCIe provides on-chip communication, 1Gb or 10Gb copper Ethernet provides a relatively short connection to the ToR switch 120, and fiber optic cable provides a relatively long connection to the core switch 130. Interconnect technologies, as non-limiting examples, include Intel® OmniPath. TM TrueScale TMHyperpath Interconnect (UPI) (formerly known as QPI or KTI), STL, FibreChannel, Ethernet, Ethernet-based FibreChannel (FCoE), InfiniBand, PCI, PCIe, or Fibre, to name just a few. Some of these technologies will be better suited for certain deployments or functions than others, and it is the responsibility of the technical staff to select the appropriate architecture for the immediate application.

[0045] However, it should be noted that, although such as OmniPath TM The high-end architecture described herein is provided for illustration purposes, but more generally, architecture 170 can be any suitable interconnect or bus for a particular application. In some cases, this can include legacy interconnects such as Local Area Networks (LANs), Token Ring networks, Synchronous Optical Networks (SONETs), Asynchronous Transfer Mode (ATM) networks, wireless networks (such as WiFi and Bluetooth), Simple Old-Style Telephone Systems (POTS) interconnects, or similar. It is also explicitly anticipated that new networking technologies will emerge in the future to complement or replace some of those listed herein, and any such future network topologies and technologies can be or form part of architecture 170.

[0046] In some embodiments, architecture 170 may provide communication services at various “layers” as originally outlined in the OSI seven-layer network model. In contemporary practice, the OSI model is not strictly adhered to. Generally, layers 1 and 2 are often referred to as the “Ethernet” layers (although in large data centers, Ethernet is often replaced by newer technologies). Layers 3 and 4 are often referred to as the Transmission Control Protocol / Internet Protocol (TCP / IP) layers (which can be further subdivided into TCP and IP layers). Layers 5-7 may be referred to as the “application layers.” These layer definitions are disclosed as a useful framework and are not intended to be restrictive.

[0047] Figure 2 This is a block diagram of a data center 200 according to one or more examples of this specification. In various embodiments, the data center 200 may be... Figure 1 The data centers can be the same as 100 data centers, or they can be different data centers. Additional views are available in... Figure 2 The different aspects of data center 200 are presented here.

[0048] Data center 200 can be controlled by organizer 260. Organizer 260 can provide services such as software-defined networking (SDN), network function virtualization (NFV), virtual machine management, and similar services on data center 200. Organizer 260 can be a standalone device with its own memory, storage devices, infrastructure interfaces, and one or more dedicated processors. In another example, organizer 260 itself can be a virtual machine or virtual appliance. Organizer 260 can have a global view of data center 200 and can have the ability to manage and configure multiple services, such as dynamically allocating tenants, domains, services, service chains, virtual machines, virtual switches, and workload servers as needed to meet current demands.

[0049] In this example, a structure 270 is provided to interconnect various aspects of data center 200. Structure 270 can be connected with... Figure 1 The structure 270 is the same as, or can be a different structure. As mentioned above, structure 270 can be provided using any suitable interconnect technology. In this example, Intel® OmniPath... TM Used as an illustrative and non-restrictive example.

[0050] As shown, data center 200 comprises multiple logical elements that form multiple nodes. It should be understood that each node may be provided by a physical server, a group of servers, or other hardware. Each server may be running one or more virtual machines suitable for its application.

[0051] Node 0 208 is the processing node, which includes processor socket 0 and processor socket 1. The processor can be, for example, an Intel® Xeon with multiple cores (e.g., 4 or 8 cores). TM Processor. Node 0 208 can be configured to provide networking or workload capabilities, such as by hosting multiple virtual machines or virtual devices.

[0052] Onboard communication between processor socket 0 and processor socket 1 is provided via onboard uplink 278. This provides an ultra-high-speed, short-length interconnect between the two processor sockets, enabling virtual machines running on node 0 208 to communicate with each other at ultra-high speed. To facilitate this communication, a virtual switch (vSwitch) can be prepared on node 0 208, which can be considered part of architecture 270.

[0053] Node 0 208 is connected to structure 270 via structure interface 272. Structure interface 272 can be any suitable structure interface as described above, and in this illustrative example, it can be used to connect to Intel® OmniPath. TMThe structure features Intel® HFI. In some examples, communication with the structure 270 can be tunneled, for example, by providing UPI tunneling via OmniPath™.

[0054] Because the data center 200 can provide many functions in a distributed manner (which were provided onboard in previous generations), a high-capacity fabric interface 272 can be provided. Fabric interface 272 can operate at gigabits per second and, in some cases, can be tightly coupled to node 0 208. For example, in some embodiments, the logic for fabric interface 272 is directly integrated with the processor on the system-on-chip. This provides ultra-high-speed communication between fabric interface 272 and the processor socket without the need for intermediate bus devices (which could introduce additional latency into the fabric). However, this does not imply that embodiments in which fabric interface 272 is provided via a conventional bus are excluded. Rather, it is explicitly anticipated that, in some examples, fabric interface 272 may be provided on a bus (such as a PCIe bus, which is a serialized version of PCI, providing higher speeds than traditional PCI). Throughout the data center 200, various nodes can provide different types of fabric interfaces 272, such as onboard fabric interfaces and plug-in fabric interfaces. It should also be noted that certain blocks in the system-on-chip can be provided as intellectual property (IP) blocks, which are incorporated into integrated circuits as modular units. Therefore, structural interface 272 can be derived from such IP blocks in some cases.

[0055] It is important to note that, following the "network as a device" approach, node 0 208 may provide limited or no onboard memory or storage devices. More precisely, node 0 208 may primarily rely on distributed services, such as memory servers and network storage servers. On the board, node 0 208 may only provide sufficient memory and storage devices to boot the device and enable it to communicate with structure 270. This distributed architecture is possible and can be advantageous due to the ultra-high speeds of modern data centers, as it eliminates the need for over-preparing resources for each node. More specifically, a large pool of high-speed or dedicated memory can be dynamically prepared across multiple nodes, allowing each node to access a large resource pool, but those resources are not idle when they are not needed by that specific node.

[0056] In this example, Node 1 storage server 204 and Node 2 storage server 210 provide operational memory and storage capabilities for Node 0 208. For example, storage server 204 can provide Remote Direct Memory Access (RDMA), allowing Node 0 208 to access memory resources on storage server 204 via architecture 270 using DMA, similar to how it would normally access its own onboard memory. The memory provided by storage server 204 can be conventional memory, such as Double Data Rate Type 3 (DDR3) Dynamic Random Access Memory (DRAM) (which is volatile), or it can be a more exotic type of memory, such as Persistent Fast Memory (PFM) (like Intel® 3D Crosspoint). TM (3DXP), which operates at the speed of DRAM, but is non-volatile.

[0057] Similarly, storage server 210 can be provided instead of onboard hard drives for node 0 208. Storage server 210 can provide networked bundled disks (NBOD), PFM, redundant array of independent disks (RAID), redundant array of independent nodes (RAIN), network attached storage device (NAS), optical storage device, tape drive, or other non-volatile memory solutions.

[0058] Therefore, in performing its designated functions, node 0 208 can access memory from memory server 204 and store the results on storage devices provided by storage server 210. Each of these devices is coupled to structure 270 via structure interface 272, which provides the fast communication that makes these technologies possible.

[0059] As further illustration, node 3 206 is also shown. Node 3 206 also includes a structural interface 272, along with two processor sockets internally connected via an uplink. However, unlike node 0 208, node 3 206 includes its own onboard memory 222 and storage device 250. Therefore, node 3 206 can be configured to perform its functions primarily on the board and may not be required to rely on memory server 204 and storage server 210. However, where appropriate, node 3 206 may, similar to node 0 208, employ distributed resources to supplement its own onboard memory 222 and storage device 250.

[0060] The basic building blocks of the various components disclosed herein may be referred to as "logic elements." Logic elements may include hardware (including, for example, software-programmable processors, ASICs, or FPGAs), external hardware (digital, analog, or mixed-signal), software, reciprocating software, services, drivers, interfaces, components, modules, algorithms, sensors, firmware, microcode, programmable logic, or objects capable of being coordinated to perform logical operations. Furthermore, some logic elements are provided by tangible, non-transitory computer-readable media (on which executable instructions are stored to instruct the processor to perform a task). Such non-transitory media, as non-limiting examples, may include, for example, hard disks, solid-state storage or disks, read-only memory (ROM), permanent high-speed memory (RFM) (e.g., Intel® 3D Crosspoint), etc. TM External storage devices, redundant arrays of independent disks (RAID), redundant arrays of independent nodes (RAIN), network-attached storage devices (NAS), optical storage devices, tape drives, backup systems, cloud storage devices, or any combination thereof. Such media may also include instructions programmed into an FPGA or encoded in hardware on an ASIC or processor.

[0061] Figure 3 A block diagram illustrating the components of a computing platform 302A according to one or more examples of this specification is shown. In the depicted embodiments, platforms 302A, 302B, and 302C, together with a data center management platform 306 and a data analytics engine 304, are interconnected via a network 308. In other embodiments, the computer system may include any suitable number (i.e., one or more) of platforms. In some embodiments (e.g., when the computer system includes only a single platform), all or part of the system management platform 306 may be included on platform 302. Platform 302 may include platform logic 310 having one or more central processing units (CPUs) 312, memory 314 (which may include any number of different modules), chipset 316, communication interface 318, and any other suitable hardware and / or software to execute a hypervisor 320 or other operating system capable of performing workloads associated with applications running on platform 302. In some embodiments, platform 302 may serve as a host platform for one or more client systems 322 that enable these applications. Platform 302A can represent any suitable computing environment, such as high-performance computing environments, data centers, communication service provider infrastructure (e.g., one or more parts of an evolved packet core), in-memory computing environments, computing systems in vehicles (e.g., cars or airplanes), Internet of Things environments, industrial control systems, other computing environments, or combinations thereof.

[0062] In various embodiments of this disclosure, the cumulative stress and / or rate of cumulative stress of multiple hardware resources (e.g., cores and non-cores) is monitored, and entities of computer platform 302A (e.g., system management platform 306, hypervisor 320, or other operating systems) can assign hardware resources of platform logic 310 to perform workloads based on stress information. In some embodiments, self-diagnostic capabilities may be combined with stress monitoring to more accurately determine the health of hardware resources. Each platform 302 may include platform logic 310. Platform logic 310, together with other logic capable of implementing the functionality of platform 302, includes one or more CPUs 312, memory 314, one or more chipsets 316, and communication interfaces 328. Although three platforms are shown, computer platform 302A may interconnect with any suitable number of platforms. In various embodiments, platform 302 may reside on a circuit board mounted in a chassis, rack, or other suitable structure, comprising multiple platforms coupled together via a network 308 (which may include, for example, a rack or chassis switch).

[0063] Each CPU 312 may include any suitable number of processor cores and supporting logic (e.g., non-cores). Cores may be coupled to each other via one or more controllers residing in the CPU 312 and / or chipset 316, coupled to memory 314, at least one chipset 316, and / or communication interface 318. In a specific embodiment, the CPU 312 is implemented within a socket (which is permanently or detachably coupled to platform 302A). Although four CPUs are shown, platform 302 may include any suitable number of CPUs.

[0064] Memory 314 may include any form of volatile or non-volatile memory, including but not limited to magnetic media (e.g., one or more magnetic tape drives), optical media, random access memory (RAM), read-only memory (ROM), flash memory, removable media, or any other suitable local or remote memory component or multiple components. Memory 314 may be used by platform 302A for short-term, medium-term, and / or long-term storage. Memory 314 may store any suitable data or information utilized by platform logic 310, including coded logic embedded in computer-readable media or stored in conjunction with or otherwise (e.g., firmware). Memory 314 may store data used by the core of CPU 312. In some embodiments, memory 314 may also include storage for instructions that may be executed by the core of CPU 312 or other processing elements (e.g., logic residing in chipset 316) to provide functionality associated with manageability engine 326 or other components of platform logic 310. Platform 302 may also include one or more chipsets 316 that include any suitable logic to support the operation of CPU 312. In various embodiments, chipset 316 may reside on the same die or package as CPU 312, or reside on one or more different dies or packages. Each chipset may support any suitable number of CPUs 312. Chipset 316 may also include one or more controllers to couple other components of platform logic 310 (e.g., communication interface 318 or memory 314) to one or more CPUs. In the depicted embodiments, each chipset 316 also includes a manageability engine 326. Manageability engine 326 may include any suitable logic to support the operation of chipset 316. In specific embodiments, manageability engine 326 (which may also be referred to as innovation engine) is capable of collecting real-time telemetry data from chipset 316, CPU 312 and / or memory 314 managed by chipset 316, other components of platform logic 310 and / or components of platform logic 310. In various embodiments, the collected telemetry data includes stress information as described herein.

[0065] In various embodiments, manageability engine 326 operates as an out-of-band asynchronous computing agent capable of interfaced with various elements of platform logic 310 to collect telemetry data with minimal or no interruption to running processes on CPU 312. For example, manageability engine 326 may include dedicated processing elements (e.g., processors, controllers, or other logic) on chipset 316 that provide the functionality of manageability engine 326 (e.g., by executing software instructions), thus preserving the processing cycles of CPU 312 for operations associated with the workload performed by platform logic 310. Furthermore, the dedicated logic for manageability engine 326 may operate asynchronously relative to CPU 312 and may collect at least some of the telemetry data without increasing the load on the CPU.

[0066] The manageability engine 326 can process the telemetry data it collects (specific examples of stress information processing will be provided herein). In various embodiments, the manageability engine 326 reports the data it collects and / or the results of its processing to other components in the computer system, such as one or more hypervisors 320 or other operating systems and / or system management software (which may run on any suitable logic, such as system management platform 306)). In specific embodiments, critical events such as cores that have accumulated excessive stress can be reported before the normal intervals used for reporting telemetry data (e.g., a notification can be sent immediately upon detection).

[0067] Additionally, the manageability engine 326 may include programmable code that can be configured to set which CPU(s) 312 will manage and / or which telemetry data will be collected by a specific chipset 316.

[0068] Each of the chipset 316 also includes a communication interface 328. The communication interface 328 can be used for signaling and / or data communication between the chipset 316 and one or more I / O devices, one or more networks 308, and / or one or more devices coupled to the network 308 (e.g., system management platform 306). For example, the communication interface 328 can be used to send and receive network traffic, such as data packets. In a specific embodiment, the communication interface 328 includes one or more physical network interface controllers (NICs), also known as network interface cards or network adapters. The NIC may include electronic circuitry for communication using any suitable physical layer and data link layer standard, such as Ethernet (e.g., as defined by the IEEE 802.3 standard), Fibre Channel, InfiniBand, Wi-Fi, or another suitable standard. The NIC may include one or more physical ports that can be coupled to a cable (e.g., an Ethernet cable). The NIC may be able to enable communication between any suitable element of the chipset 316 (e.g., manageability engine 326 or switch 330) and another device coupled to the network 308. In various embodiments, the NIC may be integrated with the chipset (i.e., on the same integrated circuit or circuit board as the rest of the chipset logic), or may be electromechanically coupled to a different integrated circuit or circuit board of the chipset.

[0069] In specific embodiments, communication interface 328 may allow the transfer of data associated with management and monitoring functions performed by manageability engine 326 (e.g., between manageability engine 326 and data center management platform 306). In various embodiments, manageability engine 326 may utilize elements of communication interface 328 (e.g., one or more NICs) to report telemetry data (e.g., to system management platform 306) to preserve the use of the NICs of communication interface 318 for operations associated with workloads performed by platform logic 310.

[0070] Switch 330 can be coupled to various ports of communication interface 328 (e.g., provided via a NIC) and can exchange data between these ports and various components of chipset 316 (e.g., one or more high-speed peripheral component interconnect (PCIe) channels coupled to CPU 312). Switch 330 can be a physical or virtual (i.e., software) switch.

[0071] Platform logic 310 may include an additional communication interface 318. Similar to communication interface 328, communication interface 318 can be used for signaling and / or data communication between platform logic 310 and one or more networks 308 and one or more devices coupled to network 308. For example, communication interface 318 can be used to send and receive network traffic, such as data packets. In a specific embodiment, communication interface 318 includes one or more physical NICs. These NICs may be able to enable communication between any suitable element of platform logic 310 (e.g., CPU 512 or memory 514) and another device coupled to network 308 (e.g., elements of another platform or remote computing devices coupled to network 308 via one or more networks).

[0072] Platform logic 310 can receive and execute any suitable type of workload. A workload may include any request to utilize one or more resources of platform logic 310 (e.g., one or more cores or associated logic). For example, a workload may include: a request to instantiate software components (such as I / O device driver 324 or guest system 322); a request to process network packets received from virtual machine 332 or devices outside platform 302A (e.g., network nodes coupled to network 308); a request to execute a process or thread associated with guest system 322, an application running on platform 302A, hypervisor 320, or another operating system running on platform 302A; or other suitable processing requests.

[0073] Virtual machine 332 can emulate a computer system using its own dedicated hardware. Virtual machine 332 can run a guest operating system on top of hypervisor 320. Components of platform logic 310 (such as CPU 312, memory 314, chipset 316, and communication interface 318) can be virtualized so that, to the guest operating system, virtual machine 332 has its own dedicated components.

[0074] Virtual machine 332 may include a virtualized NIC (vNIC), which is used by the virtual machine as its network interface. The vNIC may be assigned a Media Access Control (MAC) address or another identifier, thus allowing multiple virtual machines 332 to be individually addressable in the network.

[0075] VNF 334 may include software implementations of functional building blocks with defined interfaces and behaviors that can be deployed in a virtualization infrastructure. In a specific embodiment, VNF 334 may include one or more virtual machines 332 that collectively provide specific functionality (e.g., WAN optimization, Virtual Private Network (VPN) termination, firewall operation, load balancing operation, security functions, etc.). VNF 334 running on platform logic 310 can provide the same functionality as traditional network components implemented through dedicated hardware. For example, VNF 334 may include components for performing any suitable NFV workload, such as Virtualization Evolution Packet Core (vEPC) components, mobility management entities, 3GPP control and data plane components, etc.

[0076] SFC 336 is a group of VNF 334s organized into chains to perform a series of operations, such as network packet processing operations. Service function links provide the ability to define an ordered list of network services (such as firewalls and load balancers) that are strung together in the network to create service chains.

[0077] Hypervisor 320 (also known as a virtual machine monitor) may include logic for creating and running guest systems 322. Hypervisor 320 may provide a virtual operating platform for guest operating systems run by virtual machines (i.e., from the virtual machine's perspective, they are running on separate physical nodes when they are actually consolidated onto a single hardware platform), and manage the execution of guest operating systems by platform logic 310. The services of hypervisor 320 may be provided through software virtualization or through hardware-assisted resources (which require minimal software intervention), or both. Multiple instances of various guest operating systems may be managed by hypervisor 320. Each platform 302 may have an independent instantiation of hypervisor 320.

[0078] Hypervisor 320 can be a native or bare-metal hypervisor that runs directly on platform logic 310 to control the platform logic and manage guest operating systems. Alternatively, hypervisor 320 can be a managed hypervisor that runs on the host operating system and abstracts the guest operating system from the host operating system. Hypervisor 320 may include virtual switch 338, which can provide virtual switching and / or routing capabilities to the virtual machines of guest system 322. Virtual switch 338 may include a logical switching structure that couples the vNICs of virtual machines 332 together, thereby creating a virtual network through which virtual machines can communicate with each other.

[0079] Virtual switch 338 may include software elements that are executed using components of platform logic 310. In various embodiments, hypervisor 320 may communicate with any suitable entity (e.g., an SDN controller) that allows hypervisor 320 to reconfigure parameters of virtual switch 338 in response to changes in conditions in platform 302 (e.g., the addition or removal of virtual machine 332 or indications that optimizations may be performed to enhance platform performance).

[0080] The management program 320 may also include resource allocation logic 344, which may include logic for determining the allocation of platform resources based on telemetry data (which may include stress information). The resource allocation logic 344 may also include logic for communicating with various components of the platform logic 310 entity of platform 302A (e.g., components of platform logic 310) to achieve this optimization.

[0081] Any suitable logic can make these optimization decisions. For example, system management platform 306; hypervisor 320 or resource allocation logic 344 of another operating system; or another logic of computer platform 302A may be able to make such decisions. In various embodiments, system management platform 306 may receive telemetry data from multiple platforms 302 and manage workload distribution across multiple platforms 302. System management platform 306 may communicate with hypervisor 320 of various platforms 302 (e.g., out-of-band) or other operating systems to implement workload distributions indicated by system management platform.

[0082] The components of platform logic 310 can be coupled together in any suitable manner. For example, a bus can couple any of the components together. The bus can include any known interconnect, such as a multipoint bus, mesh interconnect, ring interconnect, point-to-point interconnect, serial interconnect, parallel bus, coherent (e.g., cached coherent) bus, hierarchical protocol architecture, differential bus, or radio transceiver logic (GTL) bus.

[0083] The components of computer platform 302A may be coupled together in any suitable manner, such as through one or more networks 308. Network 308 may be any suitable network or a combination of one or more networks operating using one or more suitable network protocols. A network may represent a series of nodes, points, and interconnected communication paths for receiving and transmitting information packets (which are propagated through a communication system). For example, a network may include one or more firewalls, routers, switches, security devices, antivirus servers, or other useful network devices.

[0084] Figure 4This is a block diagram of a microservices architecture based on one or more examples of this specification. In this case, microservices architecture 400 includes host software 404 running on compute nodes in a data center, which may include VMs hosted on a hardware platform. Host software 404 may request access to various resources, such as non-volatile storage devices, permanent high-speed memory, FPGAs, and other suitable services. In the illustrative example, microservices architecture 400 provides security features, such as for non-repudiation of structures flowing through microservices, to provide evidence of data integrity or origin.

[0085] In one example, host software 404 may need to encrypt and sign the structured business through the microservice, and then immediately transfer its DMA (Direct Memory Access) to persistent memory before forwarding the business to the next hop.

[0086] In this example, multiple microservice accelerators 415 are available, including native software 430, resource pool 424, FPGA (or FPGA pool) 420, and hardware accelerator 416. It should be noted that the microservice accelerator 415 disclosed herein is provided only as a non-limiting example, and the hardware accelerator 415 may also include any other means or functions configured to provide microservices.

[0087] Local software 430 can be software that runs on the same operating system as software 404. In other words, local software 430 can be a subroutine or module that runs on the same platform hardware as host software 404.

[0088] Resource pool 424 can be a resource pool, such as one that can be provided on a compute sled or in a computer rack, where a large number of identical or nearly identical resources are dynamically provided and prepared to other nodes in the data center. This can include storage servers, including PFM servers, storage servers, or various accelerators or other resources.

[0089] FPGA pool 420 is also available, with multiple FPGAs that can be dynamically prepared and programmed to implement desired microservice functions.

[0090] Hardware accelerator 416 may also be provided. Hardware accelerator 416 may include ASIC, SoC, or other dedicated hardware that performs functions at ultra-high speed relative to software.

[0091] When each resource comes online, it can register with the Service Discovery Function (SDF) 440. SDF 400 can be a standalone VM running in the data center, or it can be an organizer (e.g., Figure 2 The modules or functions of the organizer 260.

[0092] For example, native software 430 can be brought online and registered with SDF 440. This registration can include the capabilities of the functionality (in this case, providing encryption and signing for authentication). It can include the nature of the instance and how it is implemented (e.g., in software running on a quad-core Intel® Xeon™ processor with two cores available for dedicated encryption and signing functionality). It can also register with SDF440 details of how each function call should be formatted for interoperability with native software 430.

[0093] Similarly, resource pool 424, FPGA 420, and hardware accelerator 416 can also register their capabilities with SDF 440. SDF 440 stores all of these in catalog 448. Note that, for example in the case of FPGA 420, registration with SDF 440 may include not only the ability of FPGA 420 to perform encryption and signing, but also the gate configuration for configuring the logic for performing functions on FPGA 420, as well as the mapping of pins or ports to input and output functions.

[0094] In this example, the local software 430, resource pool 424, FPGA pool 420, and hardware accelerator 416 can all provide (or be configured to provide) the same or nearly the same functionality, such as authentication microservices requiring encryption and signing.

[0095] Taking authentication as an example, host software 404 can simply perform encryption and signing on-board via its own software stack. However, this can be computationally inefficient and resource-intensive, and can make the service a bottleneck in network processes. Offloading the functionality to an accelerator can be more efficient and faster, and can ensure packets travel more smoothly through the data center. However, at the time of design, the programmers of host software 404 may not know which authentication acceleration capabilities will be available.

[0096] Therefore, to increase the efficiency of host software 404, instead of calling its own native subroutines or trying to find the exact resources expected to be available in the data center, host software 404 can issue calls to the microservice API 408 (which can be a unified "cloud-friendly" API). Instead of targeting a specific platform or device, calls to the microservice API 408 can be formatted according to a standardized form (e.g., a single "Service.Nonrepudiation([parameters])" method call), which is uniform across resource instances. This allows for the dynamic dispatching and binding of the functionality behind the microservice API 408 and allows microservices to be accessed through unified addressing. Through ontological cataloging of properties, some functions in catalog 448 can be selected, or selection can be assisted.

[0097] Microservice API 408 communicates with microservice driver 412, which queries SDF 440 to identify the best available microservice instance for performing the approved functions. The identification of the best available instance may include factors such as the priority of host software 404 across the data center, the load on existing instances of the microservice functions, the relative speed of the instance, and any other factors that can be used to optimize the overall functionality of the data center.

[0098] For example, consider a scenario where hardware accelerator 416 provides the fastest processing for encryption and signing functions. This could be because hardware accelerator 416 is implemented entirely in hardware and is therefore very fast. However, other nodes in the data center may already be using instances of hardware accelerator 416 at or near their optimal capacity. Therefore, introducing new processes to hardware accelerator 416 instead of optimizing data center resources could actually become an additional burden on those resources. Instead, microservice driver 412, communicating with SDF 440, can identify FPGA pool 420 as the best available resource for implementing encryption and signing microservices. Thus, instead of imposing an additional burden on hardware accelerator 416, microservice driver 412 can receive gate configurations from SDF 440 via directory 448 for allocating one or more FPGAs in FPGA pool 420 to implement encryption and signing functions. However, it should be noted that microservice driver 412 may not be an agent for actually implementing FPGA programming. That function can be dispatched to dedicated hardware, and the instructions for implementing programming can come from microservice driver 412, from the organizer, or from any other device configured to implement FPGA programming. Once one or more FPGAs have been allocated and programmed, they can continue operating on the process of entering the host software 404 until the microservices landscape of the system changes and there is a need to reallocate microservice instances.

[0099] Note that in this example, the microservice driver 412 prepares not only the service but also the processes associated with it. This ability to dynamically define message flows leads to the concept of chaining, which has the beneficial effect of pipelined activation of multiple microservices and thus reduces latency buildup. Instead of applications waiting for functionality to be enabled, microservices can be easily chained together in a single process.

[0100] For example, if a service chain is defined (where the incoming packet is first decrypted and its signature is verified), and the packet is then subjected to DPI, the microservice driver 412 can prepare not only instances of the decryption and signing microservices, but also instances of the DPI microservice. These instances are prepared such that when the decryption and signature verification functions are complete, the result does not need to be returned to the host software 404, and then DPI is enabled via the microservice API 408. Instead, when the microservice driver 412 prepares both services, it can create an interface between them so that once the decryption microservice has completed decrypting the packet, it can directly provide the decrypted packet to the DPI microservice instance. The DPI microservice instance can then perform its DPI functions and either return the result to the host software 404 or, if another microservice exists in the chain, forward the packet to the next microservice.

[0101] Figure 5 This is a flowchart of a method 500 for registering and using microservices, based on one or more examples of this specification.

[0102] In box 508, multiple microservices or resources with microservice capabilities register with SDF 540. SDF 540 can store the registered instances in the ontology catalog 548.

[0103] In box 504, the application makes a microservice discovery request for a specific function described in the ontological model. This request is sent to the service discovery module 512.

[0104] In box 516, the service discovery module performs a directory lookup via SDF 540. SDF 540 provides a list of available microservice instances, including the properties of each instance.

[0105] In box 520, the microservice driver can match attributes from directory 548 with the requirements of instance service box 504.

[0106] If the full instance is available with sufficient bandwidth, then in box 524, the microservice driver can organize access to the instance, such as by providing a new endpoint Uniform Resource Identifier (URI) to enable the host software to access the microservice instance.

[0107] If no instance is available, in box 528, the microservice driver can prepare a new instance, and communication with that new instance can be coordinated with service requests.

[0108] In box 532, the request host software can connect to the microservice instance. This may include, for example, a simple handshake, so that each knows it is communicating with the other.

[0109] Finally, in box 536, the host service begins, for example, by exchanging packets to the provided URI using a prepared microservice instance.

[0110] It is important to note that in this basic case, both the implementation and its path are dynamic, and the application itself is unaware of the best way to instantiate the functionality and the best way to communicate with the functionality.

[0111] Subsequently, Figure 6 and Figure 7 Additional details of the microservice architecture are shown, in which Figure 6 This shows the initial creation of a microservice instance, and Figure 7 This demonstrates the subsequent use of the microservice instance.

[0112] Figure 6 This is a block diagram illustrating the initial setup of a microservice instance based on one or more examples from this specification. In this case, application 604 uses middleware 610 to communicate with driver 614. Application 604 has a need to access the microservice.

[0113] In operation 1, application 604 submits a microservice discovery request via the microservice driver. The microservice driver can then issue the discovery request in box 620 via a structure. Furthermore, in box 620, the microservice driver can select desired implementation options (such as hardware accelerators, FPGAs, or resource pools) and issue a request to a management and network organization (MANO) server (e.g., organizer 260) (which in this case provides SDF).

[0114] In operation 3, MANO 628 initiates or otherwise prepares an instance of the desired microservice. This may include, for example, an application container 640 containing an API wrapper 644 and a software library 648. In another example, this includes an application container 650 containing an API wrapper 654, a driver or middleware 658, and a hardware accelerator 660.

[0115] The appropriate attributes of the provided instance are encapsulated in the microservice description 634 (which is registered in the microservice registry 630).

[0116] In operation 4, message forwarder 624 is established to enable application 604 to communicate with new instances of the microservice. This can be, for example, a dynamic message forwarder of the required type. Message forwarder 624 can be implemented as a configuration to connect the application to the appropriate microservice architecture (network, bus, etc.). In this embodiment, forwarding is a 'passive' delivery of data.

[0117] In operation 5, the necessary connection must be established between message forwarder 624 and application 604, providing an open line for communication between the application and the microservice instance. This provides a connection for requesting tasks provided by the microservice instance for current or future processes, such as... Figure 7 Further details are shown in (e.g., in operations 6 and 7).

[0118] Generally, a microservice enablement chain is constructed by continuously repeating this operation, allowing each instance of a microservice to be dynamically selected and customized for direct communication from its predecessor microservice instances in the chain. Therefore, in the case of a microservice chain, the establishment of message forwarder 624 in some cases provides a connection not between application 604 and the microservice, but between the preceding and following microservices in the service chain. Like application 604, each predecessor microservice may be unaware of the implementation details of its successor microservices and the details used to provide the optimal path for enabling.

[0119] Figure 7 It is a description of how microservices operate; it can be considered as... Figure 6 An extension of the block diagram.

[0120] exist Figure 7 In the example, host software 702 has requested the preparation of multiple microservices (i.e., microservice 704-1, microservice 704-2, and microservice 704-3).

[0121] In operation 6, host software 702 accesses microservice 704-1, for example, by providing data flow to the URI associated with microservice 704-1.

[0122] Microservice 704-1 receives a process from host software 702 and executes its specified microservice on that process. For example, microservice 704-1 can provide decryption and key verification on incoming packets.

[0123] In operation 7, microservice 704-1 then operates message forwarder 708 to forward packets to microservice 704-2.

[0124] Microservice 704-2 can be, for example, a DPI microservice, which performs detailed analysis of inbound packets.

[0125] Once microservice 704-2 completes its deep packet inspection, it operates another message forwarder 708 to forward packets to microservice 704-3.

[0126] Microservices 704-3 can perform additional auxiliary functions, such as statistical or big data functions, which do not affect the values ​​of the group, but are used to manage the data center and provide services to customers.

[0127] Once the microservice 704-3 has completed its function, it returns the packet to the host software 702, which can then manipulate the packet according to the normal process.

[0128] exist Figure 7 In one example, message forwarder 708 could be a single monolithic message forwarder that provides interconnection between microservice instances (similar to a lightweight vSwitch specifically designed for forwarding packets between microservices), allowing message forwarder 708 to act as a hub between microservices. In another example, each microservice instance could have its own dedicated connection to other microservices, allowing microservices to be "daisy-chained" together without any intermediate hub.

[0129] It's important to note that in this scenario, the entire service chain is applied to the packet after it encounters the host software 702, eliminating the need for the packet to "ping-pong" back and forth between the host software 702 and the various microservices in the service chain. Also note that the use of microservices allows the host software 702 to treat the various functions in the service chain as if they were single calls to instances of local modules. Therefore, instead of explicitly accessing multiple accelerators (where the packet is sent to an accelerator, returned to the host, sent to a second accelerator, returned to the host again, sent to a third accelerator, and returned to the host a third time), a series of accelerators are used in the chain and enabled via a single function call from the host software 702.

[0130] Please note, Figure 5-7 The disclosed diagrams and processes, for example, provide an abstraction of the hardware of the low-level accelerators behind public microservice APIs. This provides flexibility in local and remote execution, addressing, and enabling. The ontology described in the registry can be provided using an extended language for defining and discovering microservices based on their expected functionality. For example, a feature of the ontology language could be a descriptor such as "functionality equals encryption (AES-GCM)". Thus, applications can specify expected functionality and parameters (such as encryption type) without specifying concrete implementation details. However, in some cases, details such as maximum acceptable latency, minimum acceptable bandwidth, or other factors that may affect performance requirements by a specific application can be provided. The ontology language can also support linking of sub-functions in its syntax. In one embodiment, the ontology language can be compatible with OpenAPI and provide easy discovery by both humans and computers.

[0131] The following will illustrate several building blocks for implementing the microservices architecture described above. These will include the following specific descriptions:

[0132] Please note, Figure 5-7The disclosed diagrams and processes provide, for example, an abstraction of the hardware behind the low-level accelerators of public microservice APIs. This provides local and remote execution, flexible addressing, and enablement. The ontology described in the registry can be provided through an extended language for defining and discovering microservices based on their expected functionality. For example, a feature of the ontology language might be a descriptor such as "functionality equals encryption (AES-GCM)". Thus, applications can specify expected functionality and parameters, such as encryption type, without specifying concrete implementation details. However, in some cases, details such as maximum acceptable latency, minimum acceptable bandwidth, or other factors that may affect the performance requirements of a particular application can be provided. The ontology language can also support linking of sub-functions in its syntax. In one embodiment, the ontology language can be compatible with open APIs and prevent easy discovery by humans and computers.

[0133] The following will illustrate several building blocks for implementing the microservices architecture described above. These will include the following specific descriptions:

[0134] • Unified API and unified addressing, as further described below in section

[0133] .

[0135] • Microservice registration (SR), as further described below in paragraph

[0134] .

[0136] • Microservice discovery (SD), as further described below in paragraph

[0136] .

[0137] • A unified access method, as further described below in section

[0137] .

[0138] • Middleware and drivers, as further described below in section

[0138] .

[0139] • Message forwarder, as further described below in section

[0139] .

[0140] • Microservice links, as further described below in section

[0141] .

[0141] • Microservice discovery endpoint (SDE), as further described below in section

[0148] .

[0142] • Messaging service (MS), as further described below in section

[0150] .

[0143] • Microservice requests, as further described below in section

[0150] .

[0144] • Addressing services (AS), as further described below in section

[0151] .

[0145] • A microservice description catalog, as further described below in section

[0152] .

[0146] • Message service path configuration, as further described below in section

[0156] .

[0147] • The message service process is further described below in section

[0158] .

[0148] • Load Balancing Engine (LBE), as further described below in paragraph

[0176] .

[0149] For a unified API in unified addressing, in this case, the open API can be used to define a standard language-agnostic interface to the Representational State Transmission (REST) ​​API, which allows both humans and computers to discover the capabilities of microservices and understand and interact with them remotely through minimal implementation logic. Additional details are provided in the description of the addressing service described below.

[0150] The microservice registry (SR) mechanism allows for further discovery of services based on their descriptions. Service providers or builders can provide details about endpoints and service descriptions through an extended language, with non-restrictive examples including possible combinations of functionality, telemetry details, licensing and metering details, scalability, instantiation, and access methods.

[0151] Registration can be part of a configuration file or a database. Additional details are available in the descriptions within the following microservice description directory.

[0152] Microdiscovery (SD) identifies available services upon request, including the identification of the best or optimal instance, the option to create a new instance (if possible), and the configuration of links and services. SD can be accessed via known mechanisms or addresses (such as specific URIs) or other mechanisms that may be part of middleware or an SDK. The SD function locates services capable of performing the requested function and configures specific service instances and message forwarders for passing data between the requesting application and different service instances in the service chain. When an instance is enabled by an application, the microservice can forward its output to the enabling software or to the next service in the service chain. Depending on the request from the application, the SD function can use existing instances or create new instances (if supported by the implementation). The SD function can also act as a load balancer, optionally adding dynamic load balancing performed by message forwarders, and works with MANO on instance creation and removal. MANO can use location and preferences, as well as details of platform capabilities, to generate the best matching instance for a hardware or software service. See the following description of SDE for additional details.

[0153] A unified access approach allows the use of the best possible access method to depend on the location and environment of the service. In one example, the microservice is accessed via a REST API running on the network. However, in other instances, access may be made through another mechanism, such as Remote Direct Memory Access (RDMA), shared memory, Memory-Mapped Input / Output (MMIO), etc. Unified access can be scalable and adaptable to different access methods, and in some examples, it can be manipulated within middleware components.

[0154] Middleware components and kernel drivers can be used to manipulate unified access, thus abstracting access from the actual implementation. In some cases, these components are existing parts of the cloud infrastructure.

[0155] Message forwarders can be prepared during microservice discovery and preparation, and can include details of which services are requested. A message forwarder can be configured to perform forwarding to the next service instance. This creates the concept of a service flow. Additional details related to message forwarders are described below in conjunction with the following message service path configuration and message service flow description.

[0156] It's important to note that applications using microservice discovery to find endpoints and access methods can enable them during processing. For an application, using microservices is as simple as issuing subroutine calls, transparently controlled by the microservice driver via a message forwarder (which proxies, load balances, and bridges requests to the correct microservice instance). The use of the message forwarder can be defined through policies, as further described in the following description of the message service flow. Message Service Linking Figure 8 Further details are shown below.

[0157] Figure 8 This is a block diagram of a message service link according to one or more examples of this specification. A message service link is a method for exposing hardware and software functionality in a cloud-friendly manner using microservices with a unified addressing scheme. Registration of a microservice may include the registration of microservice connectivity capabilities, which indicate the ability of a microservice instance to communicate directly with other instances of the same or different microservices.

[0158] In operation 1, application 830 sends a request for functionality to service discovery 812.

[0159] In operation 2, service discovery 812 obtains the path ID in response to application 830 to prepare functions and entry points.

[0160] Service discovery 812 then accesses configuration 816 and message forwarding data 820 to prepare the appropriate service chain. This may include preparing service implementations 804 (including multiple services 0 to n). Each service may include a path ID and a next-hop URI.

[0161] In operation 3, application 830 constructs message 824, which may include a path ID, message content, and trace ID. In operation 4, application 830 sends message 824 to service implementation 804.

[0162] In operation 5, the service implements the appropriate chain for the microservice (804) and begins propagating messages through the microservice (824).

[0163] In operation 6, service implementation 804 may optionally return a completion status to message forwarding block 820.

[0164] The service discovery endpoint provides a scalable infrastructure for discovering available services, regardless of their implementation or location. This supports drop-in replacements and optimizations based on application preferences, workload types, and combinations of services.

[0165] In this context, the term "endpoint" means a known API used by an application to perform functionality. Service discovery is exposed to an application in various combinations, such as, as a non-restrictive example:

[0166] • A special URL or URI that serves as the entry point.

[0167] • PCI or PCIe devices, whether physical or analog, are addressed using B / D / F encoding with defined message codes and data formats. This allows for easy virtualization using devices like virtio or SR-IOV, (in the case of hardware implementation) with ioctl-based APIs, cHr-DeV, or pseudo-NICs.

[0168] • System calls or other libraries for low-latency calls. In some cases, the service discovery endpoint may be hard-coded, or it may be part of a cloud INIT script or similar provided.

[0169] Figure 9 This is a block diagram of service discovery based on one or more examples in this specification. In the case of a service request, an application requests a specific function from the messaging service (i.e., the Microservice Discovery Function (MDF)) by providing a description of the function to be performed or expected to be performed. This is in Figure 9As seen in the diagram, the service discovery function 900 receives a description of the desired service as input. This can be a single function or a sequence of functions to be applied to the same message in a service chain. In another example, this could be an enumerated list of desired capabilities. In one example, an open API could be used for this purpose, although this is a non-limiting example. The service description can be provided in different ways or formats, and may include the requested functionality in addition to other information such as function-specific parameters or desired performance parameters. The output of the service discovery function 900 may include the path ID to be used for the service, endpoint details, and available options.

[0170] For addressing services, a unified addressing scheme can be used to provide a consistent calling convention for requesting remote or local resources, and hardware or software microservices (where appropriate). A unified addressing service can be implemented by redirecting calls and providing data delivery to the actual instance. The application itself may be agnostic to the instance and its location or implementation details. These can be mapped to multiple load-balanced instances to support autoscaling. Endpoints (for example, calls to localhost URLs) in this approach can be entry points to message forwarders. Message forwarders can process message input parameters, such as path IDs, and translate them into the actual runtime enablement of the microservice instance.

[0171] A microservice description catalog can be used for service registration. When they become available, new microservice implementations and instances can be registered with the service discovery function. Registration can include, as input, a description of the services provided, a description of capabilities (including items such as scaling options, resource sharing, and data type clocks), and may also include telemetry data, quality factors, and the like. The output of registration can include a confirmation status.

[0172] A microservice registry can include entry point configurations, and as a non-limiting example, a description of how the service is enabled, a description of supported functionalities, and SLA details. For instance, when a specific package of an FPGA is loaded, it can be registered as a microservice to enable the provision of application resources and be marked as preferred, while the software implementation can still receive messages as needed. New instances can also be transparently added to the calling application, providing a path ID instead of an instance ID to access the microservice. Dynamic allocation of new instances can be supported to enable autoscaling.

[0173] The service can also use the API for telemetry to report its usage, load, and any issues it encounters. In some cases, namespaces and contexts can be supported for VM or functional domain isolation. Advantageously, this does not require changes to the device itself.

[0174] Using Intel® Quick Assist™ as an example, instead of using SR-IOV to map devices in a VM, the architecture in this specification allows instances of SSL microservices to be implemented as wrappers on QAT instances and equipped with access points (such as URIs). When an application needs to encrypt or decrypt data, it forms a message specifying the data to be processed and the encryption or decryption function to use. An alternative packet is returned to the requesting application, and the next destination can be an Ethernet microservice, which actually sends the encrypted content over the wire.

[0175] With a messaging service path configured, during microservice discovery, when an application requests a specific function, the messaging service can perform the following operations:

[0176] • Verify that the requested functionality is supported.

[0177] • Assign a path ID to the requested function sequence and return the path ID for later use by the application.

[0178] • Allocate resources to enable streaming processing (connected instances, shared memory, etc.). Tasks can be specified to execute synchronously or asynchronously. Shared memory buffers can be connected to microservice instances and can also be used for various platform operations, such as remote calls (e.g., via Ethernet, RDMA, or the like). This can lead to the creation of service flows.

[0179] A unified mechanism for addressing services can include local software instances, local hardware implementations, or any type of remote implementation. The messaging service manages the established service paths, including the configuration of intermediate services for cross-domain or cross-server connections. Applications can use any implemented method to communicate with the messaging service, such as URIs, PCIe, library calls, or the like. Applications can also support sending messages to instances of microservices.

[0180] The message service process supports various features:

[0181] • Input queues can be implemented in a hardware-friendly manner using a shared storage buffer.

[0182] • If the current instance is unable to accept processing for any reason, input queue redirection can be used to postpone or dispatch processing, thus enabling "hot potato" load balancing.

[0183] • The service implementation can be either software or hardware.

[0184] • Optional hardware assistance provides platform pseudo-instructions, implemented as microcode, that can perform message forwarding. This can utilize internal tables for state and can also perform load balancing, argument verification, etc.

[0185] This allows the service stack to delegate many well-formatted operations and responsibilities to platform or cloud services. Therefore, infrastructure specialization and engagement can occur independently or in parallel with task progress and optimization. Concerns such as whether an exchange is virtual or how it will affect scaling or latency can be moved to a lower level (where they best fit a dynamic environment). Thus, microservices know where to forward messages along specific paths; for example, message forwarding functionality can be implemented using memory channels (instances on the same server) or remote enablement via RDMA or a structure library on Intel® OmniPath™.

[0186] • A service can be implemented in software or hardware, or a combination of both.

[0187] • Hardware-based load balancing can facilitate the use of hardware implementations of services.

[0188] • When bottlenecks exist along the service path, a pipeline overflow notification mechanism can be used.

[0189] • Notification of new messages can be provided to the next service via a lightweight semaphore (especially when the receiver is on the same host) or via an interrupt. In another example, the receive service can poll the input queue.

[0190] For an application request, the message the application prepares to send includes four parts:

[0191] • The path ID provided by the messaging service.

[0192] •content.

[0193] • Optional token ID (used for completion notification).

[0194] • Optional introduction or conclusion.

[0195] The path ID defines the logical path a message should follow and is implicitly encoded throughout the process, thus allowing messages to be sent without waiting for the processing of previous messages to complete. The messaging service can provide status (if requested by the application) via a token ID to track the completion of requests.

[0196] Prefaces and conclusions can be used to support polymorphic and pipelined messaging flows. A preface adapts the message processing at the target location, allowing customization to be pushed closer to where the data will be manipulated, while a conclusion specifies the continuity and forwarding of data, results, events, or states. This doesn't necessarily have to be limited to the initiator, but potentially to other entities as well. This broadens the concept of proactive messaging to proactive flows.

[0197] Figure 10This is a block diagram illustrating message forwarding according to one or more examples of this specification. In this case, the message forwarding block receives inputs and outputs as shown.

[0198] Internally, the message forwarder can be implemented as a redirection table, which includes, but is not limited to, the following types of service instance entry points:

[0199] • To the NIC or a remote address, such as a remote URI.

[0200] •To PCIe BDF.

[0201] • Access the software via exception or polling mode.

[0202] •Through structure.

[0203] • Memory-to-memory or memory-mapped I / O (MMIO).

[0204] In the case of two applications communicating, alternative application A sends data to service B (which may have both software and / or hardware implementations), and application A sends a message to message forwarder 1000.

[0205] The input to message forwarder 1000 may include path information or a path information handle and the payload to be forwarded.

[0206] The message forwarder 1000 can transform a message as needed to make it suitable for the next hop. This may include encapsulating, decapsulating, or otherwise transforming the message. The message forwarder 1000 then sends the transformed message along with new path information or a path information handle.

[0207] In various embodiments, message forwarder 1000 may participate in message delivery directly or indirectly. In direct use, message forwarder 1000 receives a message from the application and forwards it to the appropriate service instance. In indirect use, message forwarder 1000 is configured to directly forward requests to the service endpoint to the specified instance, assuming that the instance supports direct access.

[0208] Message forwarder 1000 provides activation and addressing / access arbitration. In other words, message forwarder 1000 acts as a message activation mediator. For example, message forwarder 1000 can send or forward a token to a destination service function. The destination can use that token to retrieve data from message forwarder 1000. The service function can use that token to poll message forwarder 1000 and know whether the source application is ready to deliver. This is different from, for example, a target service instance receiving data from an application and then contacting message forwarder 1000. In other words, the destination can be the active object doing something, and higher-level code can act as a composer for these low-level actions, setting them up and then letting them run.

[0209] The forwarding device implementing message forwarder 1000 enables addressing without requiring mapping to nodes and ports. Instead, addresses can be mapped to named entries and entity functions. Entities can be hardware, software, firmware, or any combination thereof, possessing a triggerable receiver with a structured interface. The result at the receiving endpoint is similar to function activation:

[0210] • If the triggered entity is software, the feature enablement is either λ or RPC.

[0211] • If the triggered entity is a smart disk, the function can be enabled by disk operations.

[0212] • If the triggered entity is a hardware accelerator, then feature activation can be an NQ operation.

[0213] • If the target is an FPGA, an opaque handshake may exist, which organizes and links to the FPGA.

[0214] The above description is provided as a non-limiting example, and many other configurations are possible. The end result is that activities become decoupled and pipelined.

[0215] In the context of process and execution management, message content can include intermediate data for processing and references to existing data. For example, application A can send an encrypted message to microservice F and a token T to A's peer application C. When C contacts F using token T, C automatically decrypts the message and is given another token M. When C decides, it starts stream M and reads the plain data. Polling is an efficient means of communication between remote entities and does not require alerts or requests for control. Instead, remote entities can retrieve tokens through polling. Other options include NICs, enqueued or dequeued data streams, or the like.

[0216] Message forwarding pushes messages to a pre-allocated buffer for a specific flow or process. Zero-copy can also be used if the pre-allocated buffer is shared with the application. MF enables execution through hardware or software implementations. Buffering and burst processing can also be configured to minimize overhead and improve resource utilization while maintaining Quality of Service (QoS) or deadlines (if requested by the application). In one example, a ring buffer can be used to implement the connection between the application, message forwarder, and service implementation.

[0217] Polymorphic behavior is also prepared. This blends the concept of proactive messaging in a polymorphic way, where the proactive part of proactive messaging is manipulated. This blurs the lines between hardware, software or accelerators, local or remote, polling or non-polling, enabling the framework to support the idea that intelligence can be distributed and coordinated at a high level while data and event processing occurs at a low level.

[0218] Message service links can also be used as a method for inter-process communication (IPC). This provides added flexibility and reduced costs, and can be implemented using Function as a Service (FaaS) or microservices with bindings to multiple IPC APIs and different languages.

[0219] Figure 11 This is a block diagram of a load balancing engine (LBE 1100) according to one or more examples of this specification. In various embodiments, message forwarding may support multiple load balancing options. In this example, the LBE 1100 receives path information or path information handles for inbound messages, as well as telemetry and quality of service targets from various instances of the target service function. This provides the LBE 1100 with information to determine which instance of the microservice to route the request to or whether to spawn a new instance of the microservice. The LBE 1100 routes inbound packets to the instance via the new path information or path information handle and may also maintain logs, for example, for background analysis or retraining.

[0220] Load balancing options include, as a non-limiting example:

[0221] • Arbitration for idle instances based on bus state.

[0222] • Cyclic load balancing.

[0223] • Weighted fair queuing.

[0224] • Load balancing can be achieved either through hot potato routing or through deadline-based load balancing (including maximum balance within time deadlines). The forwarding table on the input can select alternative destinations when the current instance is overloaded.

[0225] • Prioritization (e.g., preferring hardware instances with overflow over software instances).

[0226] This disclosure also provides the following technical solutions:

[0227] 1. A computing device, comprising:

[0228] Hardware computing platform; and

[0229] The logic used to operate on the hardware computing platform is configured as follows:

[0230] Receive microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity capabilities indicating the ability of the microservice instance to communicate directly with other instances of the same or different microservices; and

[0231] The registration is recorded in the microservice registration database.

[0232] 2. The computing device as described in technical solution 1, wherein the logic is further configured to publish the microservice registration to the microservice driver.

[0233] 3. The computing device as described in technical solution 1, wherein the microservice registration database is an ontology database.

[0234] 4. The computing device as described in technical solution 1, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain.

[0235] 5. The computing device as described in technical solution 1, wherein the microservice registration database is further configured to include information for mapping microservice application programming interface (API) calls to natively enabled information for the microservice accelerator, wherein the microservice API is a generic API for the device to access the microservice accelerator.

[0236] 6. The computing device as described in technical solution 1, wherein the microservice registration database is further configured to include information for generating new instances of the microservice accelerator.

[0237] 7. The computing device as described in technical solution 6, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0238] 8. The computing device as described in technical solution 7, wherein the information for programming the new instance includes gate configuration for the field-programmable gate array (FPGA).

[0239] 9. The computing device as described in technical solution 1, wherein the logic is further configured to receive and store information relating to the load on an existing instance of the microservice accelerator.

[0240] 10. One or more tangible, non-transitory, computer-readable media storing executable instructions for providing microservice discovery functionality (MDF), said MDF being configured to indicate means:

[0241] Receive microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity capabilities indicating the ability of the microservice instance to communicate directly with other instances of the same or different microservices; and

[0242] The registration is recorded in the microservice registration database.

[0243] 11. One or more tangible non-transitory computer-readable media as described in technical solution 10, wherein the logic is further configured to publish the microservice registration to the microservice driver.

[0244] 12. One or more tangible non-transitory computer-readable media as described in technical solution 10, wherein the microservice registration database is an ontology database.

[0245] 13. One or more tangible non-transitory computer-readable media as described in technical solution 10, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain.

[0246] 14. One or more tangible non-transitory computer-readable media as described in technical solution 10, wherein the microservice registration database is further configured to include information for mapping microservice application programming interface (API) calls to natively enabled information for the microservice accelerator, wherein the microservice API is a generic API for device access to the microservice accelerator.

[0247] 15. One or more tangible non-transitory computer-readable media computing devices as described in technical solution 10, wherein the microservice registration database is further configured to include information for generating new instances of the microservice accelerator.

[0248] 16. One or more tangible non-transitory computer-readable media as described in technical solution 15, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0249] 17. One or more tangible non-transitory computer-readable media as described in claim 16, wherein the information for programming the new instance includes gate configurations for a field-programmable gate array (FPGA).

[0250] 18. One or more tangible non-transitory computer-readable media as described in technical solution 10, wherein the logic is further configured to receive and store information relating to the load on an existing instance of the microservice accelerator.

[0251] 19. A computer-implemented method for providing microservice discovery functionality (MDF), comprising:

[0252] Receive microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity capabilities indicating the ability of the microservice instance to communicate directly with other instances of the same or different microservices; and

[0253] The registration is recorded in the microservice registration database.

[0254] 20. The method of claim 19 further includes publishing the microservice registration to the microservice driver.

[0255] 21. As described in technical solution 19, wherein the microservice registration database is an ontology database.

[0256] 22. The method of claim 19, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain.

[0257] 23. The method of claim 19, wherein the microservice registration database is further configured to include information for mapping microservice application programming interface (API) calls to native counterparts of the microservice accelerator, wherein the microservice API is a generic API for device access to the microservice accelerator.

[0258] 24. The method of claim 19, wherein the microservice registration database is further configured to include information for generating new instances of the microservice accelerator.

[0259] 25. The method of claim 24, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0260] The foregoing outlines features of several embodiments to enable those skilled in the art to better understand various aspects of this disclosure. Those skilled in the art will recognize that they can readily use this disclosure as a basis for designing or modifying other processes and structures for achieving the same purpose and / or attaining the same advantages of the embodiments described herein. Those skilled in the art will also find that such equivalent constructions do not depart from the spirit and scope of this disclosure, and that they can make various changes, substitutions, and modifications therein without departing from the spirit and scope of this disclosure.

[0261] All or part of any hardware element disclosed herein may be readily provided in a System-on-a-Chip (SoC) (including a central processing unit (CPU) package). SoC stands for Integrated Circuit (IC), which integrates components of a computer or other electronic system onto a single chip. Thus, for example, a client device or server device may be provided wholly or partially in an SoC. An SoC may include digital, analog, mixed-signal, and radio frequency functions, all of which may be provided on a single chip substrate. Other embodiments may include a multi-chip module (MCM) in which multiple chips reside within a single electronic package and are configured to interact closely with each other via the electronic package.

[0262] It should also be noted that in some embodiments, certain components may be omitted or combined. In a general sense, the arrangements shown in the figures may be more logical in their representation, while the physical architecture may include various arrangements, combinations, and / or mixtures of these elements. It must be noted that countless possible design configurations can be used to achieve the operational objectives outlined herein. Accordingly, the associated infrastructure has countless alternative arrangements, design choices, device possibilities, hardware configurations, software implementations, and equipment options.

[0263] In a general sense, any processor with a suitable configuration is capable of executing any type of instruction associated with data to achieve the operations detailed herein. Any processor disclosed herein can transform an element or product (e.g., data) from one state or event to another. In operation, a storage device may, where appropriate and based on specific needs, store information in any suitable type of tangible, non-transitory storage medium (e.g., random access memory (RAM), read-only memory (ROM), field-programmable gate array (FPGA), erasable programmable read-only memory (EPROM), electrically erasable programmable ROM (EEPROM), etc.), software, hardware (e.g., processor instructions or microcode), or any other suitable component, device, element, or object. Furthermore, information tracked, transmitted, received, or stored in a processor may, as needed and implemented, be provided in any database, register, table, cache, queue, control list, or storage structure, all of which may be referenced in any suitable time frame. Any memory or storage device disclosed herein should be understood to be appropriately encompassed within the broad terms 'memory' and 'storage device'. The nontransitory storage media described herein are explicitly intended to include any nontransitory dedicated or programmable hardware configured to provide the disclosed operations or to enable a processor to perform the disclosed operations.

[0264] The computer program logic that implements all or part of the functionality described herein is implemented in various forms, including, but not limited to, source code, computer-executable form, machine instructions or microcode, programmable hardware, and various intermediate forms (e.g., forms generated by an assembler, compiler, linker, or locator). In one example, source code includes a set of computer program instructions implemented in various programming languages ​​(such as object code, assembly language, or high-level languages ​​such as OpenCL, FORTRAN, C, C++, JAVA, or HTML for use with various operating systems or operating environments) or in hardware description languages ​​(such as Spice, Verilog, and VHDL). Source code may define and use various data structures and communication messages. Source code may be in a computer-executable form (e.g., via an interpreter), or source code may be converted (e.g., via a converter, assembler, or compiler) into a computer-executable form or into an intermediate form, such as bytecode. Where appropriate, any of the above can be used to construct or describe appropriate discrete or integrated circuits, whether sequential, combinational, state machine, or otherwise.

[0265] In one exemplary embodiment, any number of electronic circuits in the figures can be implemented on a board associated with the electronic device. The board can be a general-purpose circuit board capable of housing various components of the internal electronic system of the electronic device and also providing connectors for other peripherals. Any suitable processor and memory can be suitably coupled to the board based on specific configuration needs, processing requirements, and computational design. It should be noted that for many of the examples provided herein, interactions may be described in terms of two, three, four, or more electronic components. However, this is done merely for clarity and illustration. It should be understood that the system can be combined or reconfigured in any suitable manner. According to similar design alternatives, any of the components, modules, and elements shown in the figures can be combined in a variety of possible configurations, all within the broad scope of this specification.

[0266] Many other alterations, substitutions, changes, modifications, and alterations are ascertainable to those skilled in the art, and it is intended that this disclosure include all such alterations, substitutions, changes, modifications, and alterations that fall within the scope of the appended claims. In order to assist the United States Patent and Trademark Office (USPTO) and any reader of any published patent in interpreting the appended claims, the applicant wishes to indicate that: (a) the applicant does not intend to invoke paragraph 6(6) (pre-AIA) or paragraph (f) (post-AIA) of section 112 of 35 U.S.SC, as it existed on the date of its filing, unless the words “component for…” or “step for…” are specifically used in the particular claims; and (b) the applicant does not intend to limit this disclosure by any statement in this specification in any way not otherwise clearly reflected in the appended claims.

[0267] Example Implementation

[0268] The following example is provided for illustration.

[0269] Example 1 includes a computing device comprising: a hardware computing platform; and logic for operating on the hardware computing platform, configured to: receive a microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity indicating the ability of the microservice instance to communicate directly with other instances of the same or different microservices; and record the registration in a microservice registration database.

[0270] Example 2 includes the computing device of Example 1, wherein the logic is further configured to publish the microservice registration to the microservice driver.

[0271] Example 3 includes the computing device of Example 1, wherein the microservice registration database is an ontology database.

[0272] Example 4 includes the computing device of Example 1, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain. This may include sequentially enabling a set of microservices to perform a requested function.

[0273] Example 5 includes the computing device of Example 1, wherein the microservice registry database is further configured to include information for mapping microservice application programming interface (API) calls to native enablement for the microservice accelerator, wherein the microservice API is a generic API for the device to access the microservice accelerator. Native enablement can be optimally efficient based on the implementation and location of the microservice and the requester of the service.

[0274] Example 6 includes a computing device of any of Examples 1-5, wherein the microservice registration database is further configured to include information for generating new instances of the microservice accelerator.

[0275] Example 7 includes the computing device of Example 6, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0276] Example 8 includes the computing device of Example 7, wherein the information used to program the new instance includes the gate configuration for the field-programmable gate array (FPGA). Other embodiments may include additional firmware loaded onto a hardware accelerator (like a GPU) to program it for specific functionality.

[0277] Example 9 includes a computing device of any of Examples 1-5, wherein the logic is further configured to receive and store information relating to the load on an existing instance of the microservice accelerator. The existing instance of the microservice accelerator can be programmed to serve new requesters in the same way, thus reducing the resource overhead of creating new instances.

[0278] Example 10 includes one or more tangible, non-transitory, computer-readable media storing executable instructions for providing a microservice discovery function (MDF), the MDF being configured to instruct means to: receive a microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity capabilities instructing the microservice instance to communicate directly with other instances of the same or different microservices; and record the registration in a microservice registration database.

[0279] Example 11 includes one or more tangible, non-transitory, computer-readable media of Example 10, wherein the logic is further configured to publish the microservice registration to a microservice driver.

[0280] Example 12 includes one or more tangible, non-transitory, computer-readable media of Example 10, wherein the microservice registry database is an ontology database.

[0281] Example 13 includes one or more tangible, non-transitory, computer-readable media of Example 10, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain.

[0282] Example 14 includes one or more tangible, non-transitory computer-readable media of Example 10, wherein the microservice registry database is further configured to include information for mapping microservice application programming interface (API) calls to natively enabled microservice accelerators, wherein the microservice APIs are generic APIs for devices to access the microservice accelerators. Example 15 includes one or more tangible, non-transitory computer-readable media computing devices of any one of Examples 10-14, wherein the microservice registry database is further configured to include information for creating new instances of the microservice accelerators.

[0283] Example 16 includes one or more tangible, non-transitory, computer-readable media of Example 15, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0284] Example 17 includes one or more tangible, non-transitory, computer-readable media of Example 16, wherein the information for programming the new instance includes gate configurations for a field-programmable gate array (FPGA).

[0285] Example 18 includes one or more tangible, non-transitory, computer-readable media of any of Examples 10-14, wherein the logic is further configured to receive and store information relating to the load on an existing instance of the microservice accelerator.

[0286] Example 19 includes a computer-implemented method for providing microservice discovery functionality (MDF), comprising: receiving a microservice instance registration for a microservice accelerator, wherein the registration includes microservices configured to be provided by the microservice accelerator and microservice connectivity capabilities indicating the ability of the microservice instance to communicate directly with other instances of the same or different microservices; and recording the registration in a microservice registration database.

[0287] Example 20 includes the method of Example 19, and further includes publishing the microservice registration to the microservice driver.

[0288] Example 21 includes the method of Example 19, wherein the microservice registration database is an ontology database.

[0289] Example 22 includes the method of Example 19, wherein the connectivity includes information configured to allocate the microservice accelerator to the service chain.

[0290] Example 23 includes the method of Example 19, wherein the microservice registry database is further configured to include information for mapping microservice application programming interface (API) calls to natively enabled information for the microservice accelerator, wherein the microservice API is a generic API for devices to access the microservice accelerator. Example 24 includes the method of any one of Examples 19-23, wherein the microservice registry database is further configured to include information for creating new instances of the microservice accelerator.

[0291] Example 25 includes the method of Example 24, wherein the information for generating a new instance of the microservice accelerator includes information for programming the new instance.

[0292] Example 26 includes the method of Example 25, wherein the information used to program the new instance includes gate configuration for a field-programmable gate array (FPGA).

[0293] Example 27 includes a method of any of Examples 19-23, wherein the logic is further configured to receive and store information relating to the load on an existing instance of the microservice accelerator.

[0294] Example 28 includes an apparatus comprising components for performing the method described in any one of Examples 19-27.

[0295] Example 29 includes the device of Example 28, wherein the components for performing the method include a processor and a memory.

[0296] Example 30 includes the device of Example 29, wherein the memory includes machine-readable instructions that, when executed, cause the device to perform the method described in any of Examples 19-27.

[0297] Example 31 includes any of the devices described in Examples 28-30, wherein the device is a computing system.

[0298] Example 32 includes at least one tangible, non-transitory, computer-readable medium comprising instructions that, when executed, constitute a method of implementation or a means of execution as required by any of Examples 19-31.

[0299] Example 33 includes a computing device comprising: a hardware computing platform; and logic implemented on the hardware computing platform for: receiving application programming interface (API) calls to microservices; discovering available microservice accelerators configured to provide the microservices; translating the API calls into native enablements for the microservice accelerators; and forwarding the native enablements to the microservice accelerators.

[0300] Example 34 includes the computing device of Example 33, wherein discovering the available microservice accelerator includes querying the microservice discovery function (MDF).

[0301] Example 35 includes the computing device of Example 34, wherein the logic is configured to receive from the MDF a list of available microservice accelerators configured to provide the microservice.

[0302] Example 36 includes the computing device of Example 35, wherein the logic is configured to determine that no instance of the microservice accelerator with acceptable idle bandwidth is available for the microservice, and is configured to generate a new instance of the microservice accelerator.

[0303] Example 37 includes the computing device of Example 36, wherein generating the new instance includes programming a new instance of the microservice accelerator.

[0304] Example 38 includes the computing device of Example 36, wherein generating the new instance includes programming a field-programmable gate array (FPGA) to provide the new instance.

[0305] Example 39 includes a computing device of any one of Examples 33-38, wherein the logic is configured to prepare the microservice accelerator in the microservice chain.

[0306] Example 40 includes the computing device of Example 39, wherein the API calls to the microservices originate from a host device, and wherein the microservice chain is configured to operate independently of the host device.

[0307] Example 41 includes the computing device of Example 40, wherein the logic is configured to provide a message forwarder for the microservice chain according to a central configuration.

[0308] Example 42 includes the computing device of Example 40, wherein the logic is configured to daisy link the microservices in the microservice chain.

[0309] Example 43 includes one or more tangible, non-transitory, computer-readable media storing instructions for providing a microservice driver, configured to: receive an application programming interface (API) call to a microservice; discover an available microservice accelerator configured to provide the microservice; translate the API call into a native enablement for the microservice accelerator; and forward the native enablement to the microservice accelerator.

[0310] Example 44 includes one or more tangible, non-transitory, computer-readable media of Example 43, wherein discovering the available microservice accelerator includes querying the microservice discovery function (MDF).

[0311] Example 45 includes one or more tangible, non-transitory, computer-readable media of Example 44, wherein the logic is configured to receive from the MDF a list of available microservice accelerators configured to provide the microservice.

[0312] Example 46 includes one or more tangible, non-transitory, computer-readable media of Example 45, wherein the logic is configured to determine that no instance of a microservice accelerator with acceptable free bandwidth is available for the microservice, and is configured to generate a new instance of the microservice accelerator.

[0313] Example 47 includes one or more tangible, non-transitory, computer-readable media of Example 46, wherein generating the new instance includes programming a new instance of the microservice accelerator.

[0314] Example 48 includes one or more tangible non-transitory computer-readable media of Example 46, wherein producing the new instance includes programming a field-programmable gate array (FPGA) to provide the new instance.

[0315] Example 49 includes one or more tangible, non-transitory, computer-readable media of any one of Examples 43-48, wherein the logic is configured to prepare the microservice accelerator in a microservice chain.

[0316] Example 50 includes one or more tangible, non-transitory, computer-readable media of Example 49, wherein the API calls to the microservice originate from a host device, and wherein the microservice chain is configured to operate independently of the host device.

[0317] Example 51 includes one or more tangible, non-transitory, computer-readable media of Example 50, wherein the logic is configured to provide a message forwarder for the microservice chain according to a central configuration.

[0318] Example 52 includes one or more tangible, non-transitory, computer-readable media of Example 50, wherein the logic is configured to daisy-chain the microservices in the microservice chain.

[0319] Example 53 includes a computer implementation method for providing a microservice driver, comprising: receiving an application programming interface (API) call to a microservice; discovering an available microservice accelerator configured to provide the microservice; translating the API call into a native enablement for the microservice accelerator; and forwarding the native enablement to the microservice accelerator.

[0320] Example 54 includes the method of Example 53, wherein discovering the available microservice accelerator includes querying the microservice discovery function (MDF).

[0321] Example 55 includes the method of Example 54, and further includes receiving from the MDF a list of available microservice accelerators configured to provide the microservice.

[0322] Example 56 includes the method of Example 55, and further includes determining that no instance of a microservice accelerator with acceptable idle bandwidth is available for the microservice, and configuring a new instance to generate the microservice accelerator.

[0323] Example 57 includes the method of Example 56, wherein generating the new instance includes programming a new instance of the microservice accelerator.

[0324] Example 58 includes the method of Example 56, wherein producing the new instance includes programming a field-programmable gate array (FPGA) to provide the new instance.

[0325] Example 59 includes the method of any of Examples 53-58, and also includes the microservice accelerator in the preparation microservice chain.

[0326] Example 60 includes the method of Example 59, wherein the API call to the microservice originates from a host device, and wherein the microservice chain is configured to operate independently of the host device.

[0327] Example 61 includes the method of Example 60, and also includes a message forwarder that provides the microservice chain configured according to the central hub.

[0328] Example 62 includes the method of Example 60, and also includes daisy-chaining the microservices in the microservice chain.

Claims

1. Server hardware for providing services, said server hardware comprising: The hardware can be configured to register at least one service instance for use by at least one database, the at least one database being used for association with service discovery, the at least one service instance being used when providing at least one service to at least one client, and the services that can be provided by the server hardware include the at least one service; as well as The mapping hardware can be configured to map application programming interface (API) calls to service request data, wherein the API calls at least partially correspond to the services that can be provided by the server hardware, and the service request data is used to associate with at least one of the services that can be requested by the at least one client. in: The API call is to be used in association with the activation of the service; The service is implemented using at least a portion of multiple service instances; The multiple service instances can be configured to include virtual machine instances and / or container instances; The virtual machine instance and / or container instance can be configured to include accelerator resources, central processing unit (CPU), and / or memory resources; The at least one service can be configured to be implemented using at least one function chain to be executed by multiple instances of the virtual machine instance and / or container instance; The at least one functional chain defines at least one ordered set of service-related functions; At least one service instance and the provision of the service are associated with Uniform Resource Locator information; and The server hardware can be configured to dynamically allocate instance resources associated with the provision of the at least one service.

2. The server hardware as described in claim 1, wherein: The at least one functional chain includes a pipeline of functions.

3. The server hardware as described in claim 1, wherein: At least one cloud service provider includes the server hardware; as well as The at least one service shall be provided in accordance with at least one tenant service agreement.

4. The server hardware as described in claim 3, wherein: The at least one service is related to one or more of the following: Group inspection; encryption; Decrypt; compression; Decompress; Safe operation; Performance tracing; Firewall operation; Virtual Private Network (VPN) operation; Load balancing; and / or Bookkeeping.

5. The server hardware as described in claim 4, wherein: The at least one service shall be provided to the at least one client, at least in part, by the server hardware via at least one Internet network; as well as The service includes one or more microservices.

6. A method at least partially implemented using server hardware, said server hardware being used to provide a service, the method comprising: Register at least one service instance for use by at least one database, the at least one database being used for association with service discovery, the at least one service instance being used when providing at least one service to at least one client, the at least one service being provided by the server hardware; as well as The application programming interface (API) calls are mapped to service request data, the API calls at least partially corresponding to the services that can be provided by the server hardware, and the service request data is used to associate with at least one of the services that can be requested by the at least one client; in: The API call is to be used in association with the activation of the service; The service is implemented using at least a portion of multiple service instances; The multiple service instances can be configured to include virtual machine instances and / or container instances; The virtual machine instance and / or container instance can be configured to include accelerator resources, central processing unit (CPU), and / or memory resources; The at least one service can be configured to be implemented using at least one function chain to be executed by multiple instances of the virtual machine instance and / or container instance; The at least one functional chain defines at least one ordered set of service-related functions; At least one service instance and the provision of the service are associated with Uniform Resource Locator information; and The server hardware can be configured to dynamically allocate instance resources associated with the provision of the at least one service.

7. The method of claim 6, wherein: The at least one functional chain includes a pipeline of functions.

8. The method of claim 6, wherein: At least one cloud service provider includes the server hardware; as well as The at least one service shall be provided in accordance with at least one tenant service agreement.

9. The method of claim 8, wherein: The at least one service is related to one or more of the following: Group inspection; encryption; Decrypt; compression; Decompress; Safe operation; Performance tracing; Firewall operation; Virtual Private Network (VPN) operation; Load balancing; and / or Bookkeeping.

10. The method of claim 9, wherein: The at least one service shall be provided to the at least one client, at least in part, by the server hardware via at least one Internet network; and The service includes one or more microservices.

11. A machine-readable storage medium comprising storage instructions, the instructions being executable by at least one machine, the instructions, when executed by said at least one machine, causing implementation of the method according to any one of claims 6 to 10.

12. An apparatus at least partially implemented using server hardware, said server hardware being used to provide services, said apparatus comprising: Components for registering at least one service instance for use by at least one database, the at least one database being used for association with service discovery, the at least one service instance being used when providing at least one service to at least one client, the at least one service being provided by the server hardware; as well as A component for mapping application programming interface (API) calls to service request data, wherein the API calls at least partially correspond to the services that can be provided by the server hardware, and the service request data is used to associate with at least one of the services that can be requested by the at least one client; in: The API call is to be used in association with the activation of the service; The service is implemented using at least a portion of multiple service instances; The multiple service instances can be configured to include virtual machine instances and / or container instances; The virtual machine instance and / or container instance can be configured to include accelerator resources, central processing unit (CPU), and / or memory resources; The at least one service can be configured to be implemented using at least one function chain to be executed by multiple instances of the virtual machine instance and / or container instance; The at least one functional chain defines at least one ordered set of service-related functions; At least one service instance and the provision of the service are associated with Uniform Resource Locator information; and The server hardware can be configured to dynamically allocate instance resources associated with the provision of the at least one service.

13. The device as claimed in claim 12, wherein: The at least one functional chain includes a pipeline of functions.

14. The device as claimed in claim 12, wherein: At least one cloud service provider includes the server hardware; as well as The at least one service shall be provided in accordance with at least one tenant service agreement.

15. The device as claimed in claim 14, wherein: The at least one service is related to one or more of the following: Group inspection; encryption; Decrypt; compression; Decompress; Safe operation; Performance tracing; Firewall operation; Virtual Private Network (VPN) operation; Load balancing; and / or Bookkeeping.

16. The device of claim 15, wherein: The at least one service shall be provided to the at least one client, at least in part, by the server hardware via at least one Internet network; and The service includes one or more microservices.

Images