The Microservice architecture drives the design of the software towards small and well defined modules of business functions with high cohesion.

Cloud Native

Strictly following the Twelve-Factor manifesto all services are cloud enabled but do not require to run in the cloud.

Polyglot does not depend on a particular database product nor on storage technology. Different services may use different types of datastores. From relational to NoSQL databases.


A workflow engine is used to control and change the material flow handling (MFC/WCS) dynamically without interrupts nor downtimes.


Admin UI

Monitoring and supervising of microservices based on SpringBoot Admin


A web application for operators and superusers to manage warehouse inventory and processes.


The cross-platform mobile handheld application for warehouse operations on mobile phone or tablet devices built with Flutter.


Monitoring and supervising capabilities of microservices, RabbitMQ, databases and servers

Project References

Beside of the non-public installations some customers allow to refer to their usage of

BMW Group AG

Uses to drive and supervise automatic warehouses

Scheppach GmbH

Uses to manage multiple manual warehouses with typical receiving, inventory management, picking and shipping processes.

DSHS has been established successfully by a partner in the US for national health government.

General Electric

Built their own product on top of to fully control their warehouses on their own.

Deployment Scenarios

A typical customer project built with is usually a composition of microservices to fulfill the functional requirements. Whereas a service may run in the cloud or on premise customer side. This mainly depends on the quality requirements of the project. For example, a service like the tcp/ip driver must obviously run with low latency close to the automation systems layer whereas and UI services may easily run off-side. is designed to run in four deployment models

  • Cloud

    All microservices run off-site in the cloud and may shared with other customers. Service access is secured but no QoS are defined.

  • Fog

    All microservices run on-side in the private cloud and are solely dedicated to the customer project.

  • Hybrid

    In a combination of Cloud and Fog deployment, some common shared services may reside on the public cloud where other mission critical of time critical services run locally in the private cloud

  • Monolith

    All microservices are packaged into a single monolithic deployment unit that runs on traditional application services. Notice that in this scenario elasticity is only available on infrastructure level (IaaS) not on service level.

Microservice Hub

As we've built a couple of microservices, we find it reasonable to create a central website where all microservices are listed and explained in detail. Beside a functional service description each microservice' website contains informtion about how a service consumer can access and use the outer public API. This API documentation explains how to operate with the exposed resources and describes the interaction model, how service calls can be combined to fulfill common use cases.

We differentiate between RTU and BYO services. The former ready-to-use services are already deployed in the public cloud and require valid access tokens for access. The latter build-your-own services are not installed and not online available. For all online services an account registration is required.

Online services may guarantee SLA depending on the non-functional service requirements and based on their runtime environment. Some services (like the service registry and configuration service) run in a geo distributed cluster on different PaaS platforms (e.g. Heroku Cloud and OpenShift Cluster) to achieve a high degree of availability. The SLA are defined by the service itself and documented on the service website.

The Public Microservice Hub.

Private services.


Heiko Scherrer

Project founder and actively developing since 2005.

Markus Schneider

As a business analys and architect Markus is close to customer projects, brings and implements valueable input to the overall project.

Frank Lauer

One of the first projects contributors when was built on EJB technology.

Michael Schmut

Innovation driver. Michael put in ideas and laid out the set of technologies already before the project was initiated.

Tina Russell

In times of Adobe Flex was used for the UI part, Tina implemented the UI application almost on her own.

Florian Gyger


Mischa Farbstein

Best in business analysis and requirements engineering with lots of project experience.