Shared Application Store for PaaS Deployment

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current Platform-as-a-Service (PaaS) systems face challenges in allowing users to easily build and deploy applications, as they require technical knowledge to select and configure components, and lack pre-configured applications that can be deployed without user involvement in the build and deployment process.

Innovation Solution

A shared application store for PaaS systems that allows users to select and deploy pre-configured applications via a fork command, enabling local or remote deployment, with changes tracked and contributed back to the master application, facilitating community participation and a try-before-you-buy experience.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If users build custom applications by writing code or composition on current PaaS offerings, then application customization capability is improved, but ease of operation deteriorates due to required technical knowledge for component selection and configuration

Engineering Contradiction:
Improveapplication customization capabilityVSAvoidease of application deployment
Core Design Contradiction:
Adaptability or versatilityVSEase of operation

Solution Approach 1:

The patent applies preliminary action by providing pre-configured application templates that have already been built with necessary components, dependencies, and configurations. Users can select from pre-defined templates (e.g., web application, data processing application) that have undergone prior setup, eliminating the need for users to perform complex build and deployment actions themselves. The system performs the configuration work in advance, allowing users to simply select and deploy.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent introduces an intermediary mechanism in the form of a component repository and template system that mediates between the complex PaaS infrastructure and the end user. This intermediary layer provides simplified interfaces where users can select applications without needing to understand underlying components. The system handles component selection, dependency resolution, and configuration automatically, acting as a mediator that translates user intent into deployed applications.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Manufacturing precision

If current PaaS offerings require users to manually build and deploy applications, then manufacturing precision is improved through custom configuration, but loss of time increases due to involvement in build and deployment processes

Engineering Contradiction:
Improveapplication configuration precisionVSAvoidtime for build and deployment
Core Design Contradiction:
Manufacturing precisionVSLoss of time

Solution Approach 1:

The system performs configuration precision work in advance by creating pre-configured templates with carefully selected components and dependencies. The build process is performed beforehand during template creation, so users inherit pre-validated configurations without repeating the time-consuming build steps. This maintains manufacturing precision through pre-tested templates while eliminating the time loss associated with manual building.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent applies copying by allowing users to select from pre-built application templates and components stored in a repository. Instead of building applications from scratch each time, users can copy proven, pre-configured templates and modify them as needed. This preserves the precision of original configurations while dramatically reducing the time required to create new applications, as the heavy lifting of configuration has already been done.

Inventive Principle:
Principle #26Copying

3Ease of operation

If a shared application store is implemented with fork command for local deployment, then ease of operation is improved, but device complexity increases due to tracking changes and flowing changes between local and remote repositories

Engineering Contradiction:
Improveease of application deploymentVSAvoidcomplexity of change tracking system
Core Design Contradiction:
Ease of operationVSDevice complexity

Solution Approach 1:

The patent implements feedback mechanisms where the system automatically tracks changes made to locally deployed applications and flows them back to the remote repository. The fork command creates a local copy that maintains a connection to the remote source, and the system provides automatic feedback loops that detect modifications and manage synchronization. This automated feedback system handles the complexity of change tracking, making the process transparent to users while maintaining ease of operation.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system applies self-service by automatically managing the complexity of change tracking and synchronization without requiring user intervention. The forked local repository self-manages its relationship with the remote repository, automatically detecting changes and flowing modifications back when appropriate. This self-service capability handles the complex coordination of distributed version control, allowing users to benefit from ease of deployment without needing to understand or manage the underlying complexity.

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS9524325B2Shared application store for a platform-as-a-service (PaaS) system
Publication Date: 2016.12.20 RED HAT INC
  • US9524325B2 patent drawing
  • US9524325B2 patent drawing
  • US9524325B2 patent drawing

AI summary

A processing device of a container registry receives an indication of a selection of a container provided by the container registry, the container to deploy on a computer system in a hosted environment, the hosted environment comprising software and hardware facilities to execute the plurality of containers in a cloud computing environment, wherein the container is stored in a first repository. The processing device issues a command to create a second repository comprising a copy of the first repository. In response to the command, the processing device creates the second repository and sends the second repository to deploy in the hosted environment, wherein the command causes subsequent changes to the container to be made to the second repository during the deployment in the hosted environment.