Interview With Paul Fremantle On WSO2 Stratos

WSO2 recently released Stratos an Open Source Cloud Computing Platform for Enterprise Application Development.WSO2 Stratos is built on top of and extends WSO2 Carbon an OSGi-compliant middleware.

The WSO2 Carbon platform encompasses the breadth of enterprise middleware capability, from hosting core services in the WSO2 Web Services Application Server and WSO2 Data Services, though connecting and composing services with the WSO2 Enterprise Service Bus and WSO2 Business Process Server, to the screen with the WSO2 Mashup Server and WSO2 Gadget Server. All are managed by the WSO2 Governance Registry, the WSO2 Identity Server and the WSO2 Business Activity Monitor.

Stratos provides a Web console that makes provisioning any of the WSO2 Carbon products in a multitenant environment possible. WSO2 calls this ability where customers’ provision and use of any WSO2 Carbon products scale transparently in multitenant environment as being ‘cloud-native’. According to the press release, the key benefits/characteristics that make a cloud-native product are:

Elasticity: infrastructure usage scales up and down based on usage.

Multi-tenancy: applications supporting different business units or regional offices can be delivered cost-effectively from a single location.

Billing, metering, and flexible monitoring: users control and pay only for what they use.

Self-provisioning and management: results in a near-zero time delay between developing applications and deploying them out to users.

Dynamic, just-in-time discovery and wiring: the virtualized infrastructure can be flexibly and even partially moved across servers, private and public clouds.

Fastly’s edge cloud platform powers secure, fast and reliable online experiences for the world’s most popular digital businesses. See for yourself.

InfoQ interviewed Paul Fremantle CTO of WSO2 to talk about the product offering and provide insights into the roadmap and development of Stratos.

InfoQ: When you refer to cloud native, what is/are the features that transform a WSO2 cloud image into a cloud-native platform?

PF: We think there is a set of key characteristics that make a system "cloud native". The core/essential ones are to be Multi-tenant, Self-service, Elastic and Metered/Billed. In addition we also think that dynamic discovery of endpoints and incremental deployment and testing are key. Details are available in a recent blog post, and we also have a white paper for more detail.

Basically the difference between the cloud images and Stratos can be most easily explained by going to http://cloud.wso2.com and registering yourself. Stratos is multi-tenant, self-service, metered and elastic. If you use the cloud images you have to rely on the underlying infrastructure (e.g. Amazon EC2) to spin up new instances of (for example) an ESB, meter it and scale it. With Stratos we do that for you independently of the underlying infrastructure cloud, and in a way much more tuned to the platform.

For example each Amazon VM costs money. In Stratos we run multiple ESB tenants on the same JVM and scale up JVMs as needed. That way if there are lots of ESBs doing nothing much (e.g. test/dev ESBs) they don't cost anything until they use enough resources to spin up a new VM.

InfoQ: Can we take a cloud/ready application (respects the characteristics of cloud native application) and make it cloud native?

PF: The initial target of Stratos is to take existing apps and run them within a tenant. But while building Stratos we had to deal with the issue of building apps that run multi-tenant across tenants. I call this the sub-tenant Vs super-tenant programming models. Stratos does have ways that you can take a sub-tenant app and turn it into a multi-tenant app, but it’s not completely coding-free. You have to add some code that understands you are living in a multi-tenant world. Saying that it’s not difficult either.

We don't have any docs on this yet. This is something we are working on with selected beta customers.

InfoQ: How portable is the platform? Can one take this and bring it in-house if the compliance/sensitivity of the data make it more suitable for a private cloud deployment?

PF: Stratos is completely portable to run in-house. In fact that is our major target for the next two years. We are the pretty unique in being an Open Source PaaS that you can deploy in-house.

InfoQ: How dependent on the OS/platform would you consider is too much dependency? Where does Stratos stand in the spectrum of platform dependence?

PF: We support Windows/Linux/Solaris as well as multiple cloud infrastructures including Amazon, Ubuntu, Eucalyptus and vmWare (coming shortly). I think being tied to a platform or OS is like being tied to anything - the more the number of lock-in points, the less freedom you have in the long run.

InfoQ: What are the levels of metering granularity you support? Could you give the readers some metrics that are used?

PF: We meter bandwidth, storage, service calls and numbers of users (all per tenant) by default, but the metering system is extensible by customers, so you could meter things like mediations or more business level metrics too.

PF: Right now we support a read-write registry that any tenant can write to, and tenants can connect to databases. We are planning a NoSQL/BigTable-like model, but at the moment our main concern was to provide a deployment model for existing apps, which are mainly SQL based.

[Stratos] plays well with S3, Amazon RDS and NoSQL. At the moment WSO2 isn't *providing* any databases: we are expecting those to exist somewhere already, or the customer to spin up something in Amazon like RDS.

InfoQ: Secondly are some of these storage services available in a platform/storage agnostic fashion (API) or are they point to point storage mechanisms?

PF: At the moment we don't have any agnostic API for data other than JDBC. Our plan is to provide a data service and API as part of a future Stratos release during 1Q-2011.

InfoQ: Given that Google App Engine and Microsoft Azure are the closest in this space; PaaS solutions; companies that have huge experience in building scalable systems; How does WSO2 compete with the breadth of experience of these giants? Obviously there is a secret sauce for the multi-tenant architecture; could you give a scale of the infrastructure?

PF: Of course WSO2 doesn't have the experience in running the same size infrastructure as Azure or AppEngine. However, we have customers running large scale systems processing 100s of millions of transactions a day, and we have been running public cloud services for a while before the launch of Stratos. Our initial target for Stratos is private cloud deployment, and we don't see any challenges we haven't dealt with scaling up in those environments. For the public Stratos runtime, we are running that on Amazon EC2.

InfoQ: From a business model perspective, can you compare and contrast the model with other companies like Red Hat, Novell etc. Assuming a large body of code that goes into building the product is contributed by the team @ WSO2. How do you protect the IP that give competitive advantage?

PF: We do everything under the Apache License. That doesn't really "protect" IP - it opens it up. The reason we use the Apache License is that it opens up amazing partnership opportunities.

Our main revenue stream is production support subscriptions, which are based on the number of instances of our software running (i.e. the number of JVM instances in production). We also provide a set of agile consultancy and services, with the most popular offering being our QuickStart, CloudStart and PartnerStart packages. These typically get users up and running in one week with some simple scenarios.

InfoQ: Outside of the focus on standards can you share some insights into the product strategy and the criteria for picking products to be included in the product suite?

PF: We firstly focus on consistency and lean-ness. Our aim is to ensure that Carbon (our standard platform) and Stratos (the cloud-native version) are completely modular and consistent. The next focus is really to be customer driven. We've added components based strongly on customer demand. We built our Registry because our customers needed an effective Open Source Registry. We added BAM because customers asked us how to monitor their SOA, and so forth.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.