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? 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 final.
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 writing (beta2).
The most important aspects of Stratos to any developer are:
- How to get started running an application on a Stratos PaaS?
- 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. email@example.com, where fremantle.org identifies the tenant.
In Figure 1, you’ll find the tenant sign-up screen:
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 straightforward:
stratos firstname.lastname@example.org 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 myphp.php.stratos.com).
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 cartridges
In addition, we can “connect” a cartridge to another: for example, subscribe to MySQL, and then connect the PHP app to a MySQL database.
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 DevStack.
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 this.
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 / cartridges:
- 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 services:
- 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 2.0
- Business Rules using Drools and the WSO2 Business Rules Server
- 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 instance.
Figure 3 shows how the Stratos 2.0 PaaS is structured.
Figure 3: The Stratos Architecture
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 load-balancer.
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 include:
- Relational Storage Service (RSS) – multi-tenant SQL database management
- Column Storage Service (CSS) – multi-tenant Cassandra
- File Storage Service (FSS) – Hadoop File System (HDFS) as-a-service
- 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 described earlier.
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 community.
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