Introducing Stratos 2.0 – an open source Platform-as-a-Service
With so many cloud platforms out there, it can be difficult to pick one that best suits your needs. But what about the first truly open source cloud platform out there? WSO2s Paul Fremantle explains how to get an application running, as well as explaing the architecture behind the project.
With so many cloud platforms out there, it can be difficult
to pick one that best suits your needs. But what about the first
truly open source cloud platform out there? WSO2’s Paul Fremantle
explains how to get an application running, as well as explaing the
architecture behind the project. This article appeared in JAX
Magazine: On Cloud Nine.
Editor’s Note: Since this article was published, Stratos 2.0 is now
What does it mean to be a PaaS?
My definition of a PaaS is a cloud infrastructure that targets
providing cloud services that are more useful to developers. For
example, an IaaS provides “compute-as-a-service” – meaning a
virtual machine. A PaaS provides a higher-level service such as an
App Server. So for example, if you have compute-as-a-service, you
have to provide a virtual machine to run. If you have a Java App
Server-as-a-service, then you provide it with a WAR file.
The second aspect of this is the project itself. Some PaaSes are
only available as a running service. For example Google provides
App Engine, but doesn’t provide the ability to run it yourself.
Stratos is the code, project and product that enables you to run a
PaaS yourself. Alternatively, there is a running PaaS based on
Stratos called StratosLive.
The initial versions of Stratos targeted running Java-based
workloads including webapps, ESB flows, BPEL flows, and other
services based on the WSO2 Carbon OSGI set of middleware services.
Stratos was the first available Open Source PaaS. The newly
released Stratos 2.0 beta has been updated to support running
services that are not based on just Java or Carbon but will run
under any language or framework using a pluggable Cartridge model.
This article focuses on Stratos 2.0 – its architecture, approach
and how to use it. All samples are based on the current beta as of
The most important aspects of Stratos to any developer are:
- How to get started running an application on a Stratos
- What is required to run Stratos?
- The set of services that runs on Stratos (Cartridges)
How to get started?
Let’s imagine you have a Stratos PaaS running and take a quick
look at how you create and run an application.The first thing you
need in Stratos is a tenant. Everything in Stratos is based on a
multi-tenancy model. Each tenant has an isolated environment. A
tenant could just be a single user or a whole companies-worth of
users. Each user in a tenant is identified by an id,
e.g. firstname.lastname@example.org, where
fremantle.org identifies the tenant.
In Figure 1, you’ll find the tenant sign-up
Figure 1: Tenant Signup
Now that we have a tenant, the next job is to subscribe to the
right service. Suppose we want to deploy a PHP app that uses a
MySQL database, then I will need a subscription to both the PHP
cartridge and the MySQL cartridge. I can subscribe through the web
console or a command line. The command line is pretty
stratos email@example.com mypassword subscribe php myphp –repoURL https://github.com/pzfreo/php-stratos.git
The repoURL is where the code is stored. For example, if we’re
using PHP, we need to put the PHP app in the www/ directory in this
repo. By default Stratos will check out this code when you
subscribe and when instances are started or restarted. You can also
install a webhook (e.g. at Github) which will notify Stratos of
updates and then Stratos will git pull them.
We can also provide min/max instances, repo userid/password, and
other options to the command-line. This returns a URL where my app
is now going to be available (in this case
So far, we’ve done the following
- Created a subscription
- Started the instance(s) of the PHP cartridge
- Checked out the code from Git into each instance
- Registered the instances with the load-balancer
We can also use the web console to subscribe to cartridges as
shown in Figure 2.
Figure 2: Available
In addition, we can “connect” a cartridge to another: for example,
subscribe to MySQL, and then connect the PHP app to a MySQL
What is required to run Stratos?
Stratos 2.0 is a PaaS that runs on multiple IaaS: it uses an
excellent project called jclouds to work on top of multiple
IaaS cloud runtimes including EC2, OpenStack (and hence Rackspace
Cloud, HP Cloud and SUSE Cloud) as well as VMware vSphere and
others. In production as StratosLive, Stratos has been run on
various runtimes including OpenStack and EC2. The simplest approach
is to start the Amazon EC2 AMI, which utilizes EC2 as the IaaS. The
second simplest approach is to use OpenStack and/or
Stratos is mainly written in Java, so for example to run the
command-line client you need a JDK6 or JDK7 installed on the
machine where you are running the CLI. For a full installation
of Stratos on a multi-machine cloud, the recommendation is to use
Puppet. There are a set of Puppet scripts that allow you to do
The set of services that runs on Stratos
The number of services that are available to the users of
Stratos are provided by the cartridges. Basically a cartridge
allows you to plug in new types of service into the Stratos
environment. A cartridge can be created by anyone, but it requires
the Stratos administrator to plug them in and configure them into a
specific deployment of Stratos. Once a cartridge is enabled, then
any tenant can subscribe to them.
The current beta supports the following services /
- Java Applications (Webapps/WAR files, JAX-WS services, JAX-RS
services) using the WSO2 Application Server 5.0
- PHP 5.5 Applications
- MySQL 5.5 databases
Below is a subset of the existing Stratos 1.6 services and in
the release, it is planned to also support all the existing
- ESB flows using the WSO2 Enterprise Service Bus 4.6
- BPEL flows using the WSO2 Business Process Server 3.0
- JMS queues/topics using AMQP and the WSO2 Message Broker
- Business Rules using Drools and the WSO2 Business Rules
- Complex Event Processing using the WSO2 CEP and Siddhi.
- Registry/Repository using the WSO2 Governance Registry
- SAML2 SSO, OpenID, OAuth 2, XACML 3.0, and other identity and
access management using the WSO2 Identity Server
- Data Services using the WSO2 Data Services Server
- Cassandra-as-a-Service using the WSO2 Storage Server
This is actually just a small part of the plans however: in the
works are MongoDB, Node.js, Ruby and others. There is also a
clearly defined model for adding cartridges and a guide to doing it
that any company, open source project or developer can follow.
One of the most important aspects of Stratos is that it is
inherently multi-tenant. Every aspect has been written with a
concept of tenant. For example, when you subscribe to a particular
service (e.g. PHP) you get a PHP runtime on behalf of your tenant.
This sets up the load-balancer to route requests from your tenant’s
URLs to your PHP web application.
One really nice new addition to the Stratos 2.0 features is
domain mapping. If you own a specific domain (e.g. fremantle.org)
you can map a domain name to the instance of a cartridge – e.g. map
wordpress.fremantle.org to your PHP subscription.
This multi-tenancy is also available to developers: you can use
Stratos as a place to write SaaS apps that are multi-tenant
themselves. This is a topic for another article however!
The tenancy model extends to support many core services
including logging, SQL (MySQL-as-a-Service), NoSQL
(Cassandra-as-a-Service) and others. No matter how many instances
of a cartridge get scaled up and down, the logs get automatically
sent to a central multi-tenant log service that stores them and
makes them available to each tenant.
The tenant model is used in different models by each deployment:
for example in the public StratosLive, the tenants are individual
organizations, each with their own user base. In other private
deployments of Stratos, tenants have been used to represent a
department or project with each tenant taking users from a shared
user base. This is enabled by the Identity Server which provides
the core identity and access control model for Stratos.
One important aspect of the multi-tenancy of Stratos is that
different cartridges can be either single tenant or multi-tenant.
In the multi-tenant case, it is the responsibility of the tenant to
maintain the isolation of tenants. In return, you can get much
better resource utilization by hosting many tenants in the same
Figure 3 shows how the Stratos 2.0 PaaS is
Figure 3: The Stratos
The whole structure sits on top of an IaaS and utilizes jclouds
to connect to the IaaS. The next layer is the Stratos Core, which
consists of a set of components that control the management of
services in the structure. These components manage all the work in
the system, including load balancing, starting and stopping
instances of services, and distributing code.
The Stratos Controller is the main component of the PaaS. This
manages the subscriptions, maintains identity, and provides the
core services used by the CLI and Web Console.
The Elastic Load Balancer controls a number of aspects. Firstly,
as the name says, this can work with the SC and Cloud Controller to
stop and start instances as load grows and shrinks. Secondly this
re-writes URLs and deals with routing requests that come into the
PaaS into the specific instance running on behalf of a tenant. So
for example, this might route a request to wordpress.fremantle.org
to http://10.2.3.35 which
is the private instance running for the tenant fremantle.org.
An important feature of the ELB is the “private jet” mode, which
allows you to reserve certain instances for one or more tenants.
This means that when there is a multi-tenant cartridge (like a
Carbon server) you can choose between sharing tenants in a single
instance or having a dedicated instance just by setting a policy at
The cloud controller is called by the ELB, and the Stratos
Controller. This takes requests from them to stop and start
instances. This then uses jclouds to talk to the IaaS. From here,
we can support very lightweight containers, such as utilizing LXC
containers using OpenStack which have a very small footprint.
Above Stratos Core is a set of important foundation services.
These are optional, but have been found to provide essential
services in StratosLive and other deployments. The services here
- Relational Storage Service (RSS) – multi-tenant SQL database
- Column Storage Service (CSS) – multi-tenant Cassandra
- File Storage Service (FSS) – Hadoop File System (HDFS)
- Registry / Repository
- Single Sign On and Identity/Access Management
- Task Management-as-a-Service
- Billing and Metering
Finally, the top layer is the set of platform services created
on behalf of the tenants. In other words the cartridges we
Stratos relies on Git as a code/artefact deployment mechanism,
so when you subscribe to a cartridge you provide a Git repository
location. Then in order to deploy an application, you simply need
to check that application into Git. This is handled by two
subcomponents called the Artefact Distribution Centre (ADC) and the
Deployment Synchronizer (DepSync).
Finally an important point to make about the architecture is the
openness. All the components talk between each other through APIs,
which are available to code to. Each of the components has many
plug-points – for example you can add your own load-balancing
algorithms to the ELB. And of course, it’s all open source.
Stratos was the first supported Open Source PaaS. Since then it
has come a long way, and the new Stratos 2.0 is a significant
improvement over Stratos 1.6. The ability to plug new cartridges
into Stratos 2.0 and create new multi-tenant services using any
language or framework is a big boost. The inherent multi-tenancy
and the richness of the foundation services, plus the wide set of
Cartridges are all important differentiators when evaluating
Stratos. I hope you have found this article interesting and it has
tempted you to try out the Stratos beta and get involved in the
For downloads, AMIs, and documentation please look at the
Beta2 release notes.
Author Bio: Paul Fremantle is co-founder
and CTO of WSO2. Paul is an Apache Member and was one of the
founders of the Apache Synapse project as well as leading and
participating in many of the open source innovations at WSO2. Paul
has wide experience in creating enterprise-grade server runtimes
and working with agile development teams to create world class
software. Paul also plays the tin whistle.
This article appeared in JAX Magazine: On Cloud Nine. For
that issue and others, click here.
Cloud image courtesy of akakumo