Unicontainer Static Linking Reduces Container Size

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing container technologies face challenges in scalability, security, and performance due to the need for multiple instances of libraries and services, leading to increased size and potential vulnerabilities, especially in distributed computing environments where they are not amenable and difficult to debug once in production.

Innovation Solution

The development of unicontainers, which are optimized by identifying and removing unnecessary dependencies, statically linking only the necessary functions, and building layers of dependencies to create a minimal, flexible, and secure container image that can run on various infrastructures, including Docker and bare metal, with the ability to incorporate orchestration logic at deployment time.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If traditional container technologies are used with multiple instances of libraries and services, then application functionality and compatibility are improved, but container size increases and security vulnerabilities increase

Engineering Contradiction:
Improveapplication compatibilityVSAvoidcontainer size
Core Design Contradiction:
Adaptability or versatilityVSQuantity of substance

Solution Approach 1:

The patent extracts only the necessary functions from dependencies by analyzing the dependency hierarchy and identifying which functions are actually required by the application. The build module obtains specific versions of dependencies that provide only the required functions, removing unnecessary functionalities. This extraction principle resolves the contradiction by keeping container size small while maintaining application compatibility through selective inclusion of essential library functions.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent segments the dependency hierarchy into multiple levels, analyzing each layer to determine minimum functions necessary. The build process divides dependencies into statically-linked components and dynamically-linked components based on their necessity. This segmentation allows the system to include only essential functions in the container image, reducing size while preserving required application functionality.

Inventive Principle:
Principle #1Segmentation

2Adaptability or versatility

If traditional container technologies include multiple instances of libraries and services, then application functionality is improved, but security vulnerabilities increase

Engineering Contradiction:
Improveapplication functionalityVSAvoidsecurity vulnerabilities
Core Design Contradiction:
Adaptability or versatilityVSObject-affected harmful factors

Solution Approach 1:

The patent extracts and removes unnecessary functions from dependencies through static analysis of the dependency hierarchy. By identifying and excluding unused functionalities, the container includes only essential code, reducing the attack surface and potential security vulnerabilities while maintaining required application functionality.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent changes the parameter of dependency inclusion from comprehensive (including all functions) to selective (including only necessary functions). The build module determines minimum functions required and obtains dependency versions tailored to provide only those functions, thereby reducing security vulnerabilities while preserving application functionality.

Inventive Principle:
Principle #35Parameter changes

3Quantity of substance

If container dependencies are optimized by removing unnecessary functions, then container size is reduced and security is improved, but build complexity increases

Engineering Contradiction:
Improvecontainer sizeVSAvoidbuild process complexity
Core Design Contradiction:
Quantity of substanceVSDevice complexity

Solution Approach 1:

The patent performs preliminary static analysis of the dependency hierarchy before building the container. The system pre-identifies necessary functions and determines the minimum set of dependency functions required. This preliminary action simplifies the build process by having the analysis completed beforehand, reducing build complexity while achieving reduced container size.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The build module automatically analyzes the dependency hierarchy and determines necessary functions without requiring manual intervention. The system self-services the complex task of dependency optimization through automated static analysis and function identification, reducing build complexity despite the sophisticated optimization performed.

Inventive Principle:
Principle #25Self-service

4Productivity

If static previrtualization and partial evaluation are used to optimize dependencies, then container performance is improved and size is reduced, but compilation time increases

Engineering Contradiction:
Improvecontainer execution performanceVSAvoidcompilation time
Core Design Contradiction:
ProductivityVSLoss of time

Solution Approach 1:

The patent performs static previrtualization and partial evaluation as preliminary actions during the build process. By optimizing dependencies beforehand through language-independent intermediate representation and partial evaluation, the system achieves improved container execution performance. The compilation time increase is accepted as a one-time cost during build, while runtime performance is significantly improved.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies partial evaluation selectively to functions that can be determined before execution. Rather than evaluating all functions, the system performs partial evaluation only on determinable functions, achieving performance improvement without excessive compilation time. This partial action approach balances optimization benefits against build time costs.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentUS12118361B2Unicontainers
Publication Date: 2024.10.15 SRI INTERNATIONAL
  • US12118361B2 patent drawing
  • US12118361B2 patent drawing
  • US12118361B2 patent drawing

AI summary

In general, this disclosure describes techniques for building an application designed to run on a given infrastructure as a container. For example, a unicontainer as described herein may represent a smallest-size, statically-linked binary that is the most optimal implementation of a container for executing an application. In some examples, a computing system builds this container by identifying unused or unneeded functionalities from dependencies for the application, for instance where such functionalities are provided by a target infrastructure for the container.