The following diagram illustrates Apache Stratos 4.1.x layered architecture at a high level:
The bottom most layer in the Stratos architecture is the Infrastructure as a Service (laaS) layer. In virtual machine (VM) scenarios, Stratos uses jclouds to communicate with the underlying IaaS. As a result, Stratos is capable of supporting any IaaS (e.g., EC2, OpenStack, CloudStack, Google cloud, etc.) that is compatible with jclouds. In addition, Stratos uses Google Kubernetes together with CoreOS to integrate Docker with Stratos. Stratos also has a Mock IaaS, which simulates all the basic features that Stratos requires from an IaaS, so that Stratos can be tested easily at zero cost. Stratos, uses the Cloud Controller to communicate (i.e., sending messages to create or destroy instances) with the underlying IaaSs. The Cloud Controller also listens to messages from instances, and updates the routing topology periodically. The Topology in-turn sends these messages to the topics, which the load balancer (LB) has subscribed to.

Stratos core comprises of the following key components: Stratos Manager, Auto-scaler, REST API/CLI/Web UI, Artifact Distribution Coordinator (ADC) and Complex Event Processor (CEP). Stratos Manager provides a comprehensive RESTful API that can be used to integrate with external PaaS management interfaces for all user interactions. Thereby, the end-users can use the set of REST APIs that are exposed by Stratos Manager to provision their applications, and also monitor and meter the PaaS.

Autoscaler is responsible for the elasticity of all the components of the system. Thereby, it takes decisions with regard to scaling up or down, based on the load and the policies (i.e., deployment policy and auto-scaling policy) that are defined in the application. It contains an embedded rule engine to take fast and accurate decisions. In addition, the Applications Topology, which is based on the deployed composite applications and their status information, is maintained in the Autoscaler to minimize the complexity of event flows.

Stratos provides users a Command Line Interface (CLI) and the web UI, which uses Stratos Manager RESTful API resources, to manage their applications and the PaaS.

Artifacts are the parts of an applicationwhich gets deployed to the relevant instances. Artifact Distribution Coordinator (ADC) is responsible for the distribution of these artifacts. ADC uses the Instance Notifier to notify the instances of the new artifacts. 

Stratos uses Complex Event Processor (CEP) to do real-time monitoring, based on the health statistics that are published to the CEP from the cartridges and services. The CEP does temporal (i.e., time-based) queries to analyze all the event streams that are being sent to it, and sends summarized information to the Auto-scaler. Currently, Stratos uses WSO2 CEP; however, Stratos supports any Complex Event Processor.

 Message Broker (MB) handles the communication among all the components in a loosely coupled manner. Currently, Stratos uses Apache ActiveMQ; however, Stratos supports any Advanced Message Queuing Protocol (AMQP) Message Broker.

Traffic comes in through any Load Balancer (LB) (e.g., HAProxy for non-HTTP traffic and Apache Stratos LB for HTTP traffic). Cloud Controller (CC) periodically updates the Load Balancer via the topology update messages. The LB routes the traffic based on its configurations, and publishes status events directly into the real-time event processor.  

Stratos has a set of core services (i.e., identity service, logging service and monitoring/metering service). Stratos uses the identity service to provide an built-in mechanism to handle identities, roles and permissions of users. Stratos provides an optional logging service, which you can use to centrally monitor all the relevant logs that correspond to the instances. You can use the monitoring/metering service in Stratos to enable system monitoring, where Stratos publishes useful information to a remote monitoring/metering server. 

The top most layer in Stratos is the cartridge layer. A cartridge is a runtime entity of Stratos. Stratos supports four categories of cartridges: data, framework, application and load balancer. You can define new cartridges in Stratos or bring your legacy systems as a cartridge into the PaaS, to reap the benefits of an underlying PaaS. The cartridge agent reside within the cartridge. cartridge agents in each booted up instance can send various events to the Message Bus and the real-time event stream. These events range from Instance Activated to Instance Maintenance Mode, and more.


The key benefits of Stratos architecture are as follows:
  • Ability to develop, deploy and manage a complete solution, which comprises of multiple services and their inter-dependencies, with the support for Composite Applications.
  • The overall architecture is resilient and pluggable by using the Message Broker (MB) as the core communication system.
  • A strong auto-scaling decision making process, because both real-time and rule-based decision making are integrated into the decision making architecture. 
  • Better load balancing and elastic scaling as a result of HTTP and non-HTTP traffic being handled in an equal manner.
  • Ability to plugin a Load Balancer (e.g., HAproxy) 
  • Dynamic Load Balancers with the capability of auto-scaling the Load Balancer itself.
  • More scalability and flexibility with the integration of Docker, CoreOS and Kubernetes. 


  • No labels