Microservices is an architectural style for developing an application as a suite of small services called microservices that perform a single business function. A microservice is a collection of operations, effectively an API, that is remotely called but does not have a formal specification like a WSDL, yet that is meant to be independently deployable. It can be implemented in various ways, including as a set of services or as event and channel definitions.

Microservices Runtime enables you to deliver microservices as a package that includes a set of related services, interfaces, document types, and triggers that subscribe to topics or queues, or as a set of related packages of this kind (for example, five packages relating to Human Resources functions).

Each microservice can run in its own Microservices Runtime and can communicate with lightweight mechanisms such as an HTTP resource API. However, you can also execute multiple microservices in the same Microservices Runtime. This hybrid solution enables you to separate microservices when needed, but also to group them when necessary. Suppose you have two microservices that need to be scaled together in similar ways (that is, when you need a new instance of one, you need a new instance of the other). If you discover that one microservice is more heavily loaded than the other, or needs to be enhanced or updated more often, you could deploy the two microservices to separate Microservices Runtime. If both microservices tend to be updated at the same time, you could cohost them in the same Microservices Runtime.

Microservices Runtime is fully compatible with Integration Server and can host services you develop using Software AG Designer and Integration Server. While Microservices Runtime is optimized to have a reduced disk and memory footprint, you can convert it into a full Integration Server by installing additional modules, such as support for an external database.

Microservices Runtime provides out-of-the-box support for dynamic lookup of service endpoints using the open-source Consul service registry. You can register a package that functions as a microservice in the Consul service registry, or automate the registration process by adding the package endpoint during the package loading process. The corresponding removal of the endpoint information can occur when unloading the package. Microservices Runtime provides facilities to look up the endpoint information which can be used to call the microservice at run time. You can also create your own package that integrates with other service registry providers.

Microservices Runtime supports a "/metrics" endpoint that provides the current Microservices Runtime metrics in Prometheus format. Prometheus is an open-source systems monitoring and alerting toolkit that has become the de-facto standard for microservices.

You can run a microservice or a set of related microservices in a Docker container, obviating the need to purchase expensive VMs. Docker images include configuration, and enable you to deploy the exact same configuration anywhere. The Docker image can include one package or a set of related packages. You can dynamically load custom packages containing microservices while starting a container; you can use a single Docker image to run multiple microservices containers. This reduces the workload on your DevOps team by reducing the number of Docker images that need to be created and maintained on an ongoing basis. Microservices Runtime supports a health check pattern that is used to determine the overall health of a Docker container. Microservices Runtime exposes a "/health" endpoint that can be used by container orchestration tools like Kubernetes to restart the pod in case of health issues DevOps engineers can combine multiple health indicators supported by Microservices Runtime to provide a consolidated health status for each running Docker container.