Browse Prior Art Database

A system for running microservices in a container hosting environment with scale and failure recovery

IP.com Disclosure Number: IPCOM000246373D
Publication Date: 2016-Jun-02
Document File: 3 page(s) / 75K

Publishing Venue

The IP.com Prior Art Database

Abstract

A system for running microservices in a container hosting environment with scale and failure recovery

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 47% of the total text.

Page 01 of 3

A system for running microservices in a container hosting environment with scale and failure recovery

Modern applications design to run as-a-service on the Cloud are composed as a set of Microservices. Each microservice has an individual task, and can be independently scaled. A common mode for deploying microservices is as containers, in a single-server container environment, or a scaled environment such as hosted container service.

    Common problems that exist when running containers in such an environment include: - Restoring function/capacity after containers fail - Scaling an individual Microservice within a system up/down - increasing/decreasing the number of containers

    - Updating a set of containers to a new software level without downtime - a new container image, or new configuration for the container

This system describes a system for solving these problems in a minimal way.

    This system provides a lightweight design for scaling, auto-restart and rolling-update of containers.

    It has the following prerequisites, which are met by a number of technologies:
A container service with the following functions: - The ability to create a new container with a uniquely specified name - The ability to delete an existing container using its name - The ability to query the status of a container, including checking if a container with a specified name exists

    These simple functions are common to a wide range of container runtimes
A horizontally scalable key-value store with the following properties: - A hierarchical structure - The ability to watch a sub-tree within that hierarchy for changes - The ability to perform locking/leader-election between containers with active connections to the store

    The are a set of transactional state stores built upon consensus algorithms that are commonly used in the Cloud space.

    There are several state store products currently available that have a mix of these properties

    This system describes 3 components/microservices, with associated algorithms, that work together to create groups of containers, keep them running, apply rolling updates, and scale.

    1) A REST API that receives external requests for changes to the environment, and places those requests into the state store

    2) A worker that detects changes in the state store, and performs operations against the container service with a high degree of parallelism to make reality match the status in the store

    3) A caretaker that regularly checks the status of containers, and in cases where there is a mismatch and no worker is currently working on that group of containers, makes a change in the state store to trigger a worker to perform work
REST API

The REST API is the simplest component in the architecture.

A scaled container that exposes a REST API.

    It exposes operations such as 'create', 'restart', 'scale', 'update', 'delete' which affect the state store.


Page 02 of 3

    It never takes any locks on the state store, so is able to provide very fast response times to...