Service Orchestration for Low Latency Applications

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Software applications face challenges in achieving low latency due to complex data dependencies and resource competition, especially as applications grow, leading to increased network and serialization costs, and inefficient resource usage, which existing manual orchestration and scheduling methods struggle to address effectively.

Innovation Solution

The implementation of automated orchestration and scheduling mechanisms that analyze dependency information and runtime characteristics to assign services to optimal processes and machines based on criteria like latency, reliability, and financial cost, using techniques such as dependency graphs and machine learning models to dynamically adjust service placement and execution priorities.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If applications grow more complex with more services, then functionality and capability are improved, but latency increases and low-latency expectations become harder to meet

Engineering Contradiction:
Improveapplication complexityVSAvoidlatency
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

The patent segments the application into multiple independent services that can be orchestrated dynamically. Each service is a discrete unit that can be scheduled independently on different computing clusters, allowing the system to manage complexity while optimizing for low latency through selective co-location of dependent services.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent implements dynamic orchestration and scheduling where service placement and execution priorities are not fixed but adapt based on runtime characteristics, dependency information, and current system state. This allows the system to respond to changing conditions and optimize latency dynamically rather than being constrained by static configurations.

Inventive Principle:
Principle #15Dynamics

2Ease of operation

If manual orchestration and scheduling methods are used, then developers have control over service placement, but resource utilization becomes inefficient and network costs increase

Engineering Contradiction:
Improvedeveloper controlVSAvoidresource utilization efficiency
Core Design Contradiction:
Ease of operationVSProductivity

Solution Approach 1:

The patent implements automated orchestration and scheduling systems that self-manage service placement and resource allocation based on dependency information and runtime characteristics. The system automatically determines optimal service co-location to minimize network costs and maximize resource utilization without requiring manual developer intervention for each scheduling decision.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent incorporates feedback mechanisms where the orchestration system continuously monitors runtime characteristics of services and adjusts scheduling decisions accordingly. Execution logs are analyzed to identify critical paths, and this feedback loop enables the system to learn from actual performance data and improve resource utilization over time.

Inventive Principle:
Principle #23Feedback

3Adaptability or versatility

If services are placed in separate processes or machines for modularity, then service independence is improved, but network and serialization costs increase

Engineering Contradiction:
Improveservice independenceVSAvoidnetwork and serialization costs
Core Design Contradiction:
Adaptability or versatilityVSLoss of energy

Solution Approach 1:

The patent maintains service independence through segmentation into separate deployable units while introducing an orchestration layer that intelligently determines when services should be co-located in the same process or machine. This allows services to remain modular and independently deployable while minimizing network overhead by placing dependent services together when beneficial.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces an orchestrator as an intermediary layer between services that manages communication and coordination. This orchestrator analyzes dependency information and makes intelligent decisions about service placement, acting as a mediator that can optimize communication patterns and reduce serialization costs by grouping related services.

Inventive Principle:
Principle #24Intermediary (Mediator)

4Productivity

If automated orchestration is implemented, then resource utilization and latency are improved, but system complexity and orchestration overhead increase

Engineering Contradiction:
Improveresource utilizationVSAvoidorchestration system complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The patent implements automated orchestration systems that self-manage the complexity of service coordination. The orchestrator automatically collects dependency information, analyzes runtime characteristics, and makes scheduling decisions without requiring manual configuration or intervention, thereby improving resource utilization while managing orchestration complexity through automation rather than manual processes.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS20230091261A1Orchestration and scheduling of services
Publication Date: 2023.03.23 MICROSOFT TECHNOLOGY LICENSING LLC
  • US20230091261A1 patent drawing
  • US20230091261A1 patent drawing
  • US20230091261A1 patent drawing

AI summary

This document relates to orchestration and scheduling of services. One example method involves obtaining dependency information for an application. The dependency information can represent data dependencies between individual services of the application. The example method can also involve identifying runtime characteristics of the individual services and performing automated orchestration of the individual services into one or more application processes based at least on the dependency information and the runtime characteristics.