Testing Cloud Services

WSO2 Stratos is a comprehensive, powerful PaaS solution which, WSO2 released newly. It is based on revolutionary Carbon platform and is a self-serving, multi-tenant, elastic runtime for private and public cloud infrastructures.

In this new deployment, Stratos has enabled WSO2 products as services. With it whole WSO2 middle-ware platform is available in the cloud as services.

So how was these services tested. As Paul has mentioned in one of his blog posts (Cloud Native), there are a set of technical attributes that the team take account of, to work well in a cloud environment. Out of these, Mutlitanency and Self servicing abilities were tested with more emphasis in this alpha release.

Self Servicing

Self-service means creating and managing your own tenant in the Stratos application. With this one could register his own organization (tenant) and manage the services, users within it.

How you do this:

1. Access Stratos from https://cloud.wso2.com/ and you will have Stratos Manager who is the entry point to wso2 cloud services.
2. Register a tenant in Startos Manager by going through the registration process that is available there in main page. This is a very simple process where you are asked to give only the domain name, administrator's credentials and security captcha.

After a successful registration, you can sign-in to Stratos using the admin account which would be admin_name@domainname. For an example, if I have my domain as 'ranaweera.lk' and administrator as 'admin', I can sign-in as 'admin@ranaweera.lk'

So that's about registering. This initial user is called the tenant-admin. After registering the organization, the tenant-admin can;
 - create users within it,
 - create various roles and assign users to them,
 - enable\disable services.

Tenant-users can;
- login and access the enabled cloud services,
- deploy there own web services,
- deploy mashups,
- apply security, change policies, apply throttling, engage modules etc to these services.

Few illustrative cases on this are;




Managing users:
From Stratos Manager, if you access 'Users & Roles' option, it allows you to add new users and roles in addition to existing admin user and role. While adding roles you can select the set of permissions you need to assign to a certain role. A user can be assigned one or many roles and vice versa. This is similar to the user management functionality we already have in all WSO2 products.

These users who were added above, are called 'tenant users'. A tenant user can login to 'Stratos Manager' from https://cloud.wso2.com/.  The user credentials that the admin assigned at the time the user was created must be used here. After signing-in to Stratos Manager, he will see all the cloud services that the tenant-admin has enabled for the tenant.

He then can sign-in to the cloud services using the same credentials.


Theming:
The tenant admin also can update the theme of his tenant by going to 'Theme' menu. There are few default themes as well as a 'customize' option.

A theme  that is applied at the Cloud Manager level should be propagate to all the cloud services within that tenant.

Billing:

This feature lets the billing information for the tenant viewable by the admin role. This component is still in development stages, so there'll be more to be said under this in future..


All the above can be done without a third party involvement making it 'self serving'. It is for the tenant administrator to manage with his tenant users.

Multitanancy

Mutlitanancy within Stratos is the ability it provides multiple organizations to register ,  Stratos Manager and work simultaneously, within their own domain. Like in our real world scenarios here the details of one organization should be private and shared only within it.

Lets simulate a step by step procedure of creating this environment;

1. First create a tenant (tenant A) and add users to it.
2. Create another tenant (tenat B) and add user to it too.
The tenant admin and users of tenant A could only access\view\edit services within their tenant. The admin and tenant users in tenant B are totally blind about the existent of tenant A.

We can use this environment to run through scenarios such as below;

Multitanancy in mashups (js services):

If the Cloud Mashup Sever was enabled as a service and tenant admin sign-in to it. He can create a javascript service in it. Lets say our admin has created a service which scrapes updates from a site and sends emails to a set of recipients. This service should be available for other tenant users to view and use. They should be able to edit it depending on the permissions granted by the admin. This mashup should appear in the service list with the author's name.

Now if you sign-in to tenant-B. Neither the admin nor the users of tenant B can access or see the services created by tenant A users. Because the two domains are two seperate entities.
Of course there are a set of system samples which will be available for all users by default. These are deployed under 'system' user.


Multitanancy in task-scheduling:

If a user\admin from a tenant schedule a task, (This is available in Cloud Mashup Server, from Configure > Scheduled Tasks menu), it will be visible and operational only within the tenant which originated it.


Multitanancy in gadgets:

In the Cloud Gadget, it allows the users to add gadgets of their desire. It lets him design their own gadget environment by adding\editing\deleting new tabs, new gadgets in their environment. All these customization done by a user (may it be the tenant user or tenant admin) is strictly for that particular user's account.

And, also these settings are not shared among tenants!

Cloud Gadget also lets you a community feature which facilitates gadgets' rating and commenting. A comment or a rating submitted by one tenant user can be viewable by other tenant users. But they are not shared with another tenant.

There's also a feature which gives you an update on the number of users who are using a particular gadget at a given time. This count is based on the users who use the gadget within a given tenant. It is not shared among tenants.



Mutlitenancy in entitlement policies:
You can create entitlement policies by going to Cloud Identity. These policies that you create in your tenant will be used only within it. And yes, these xcml policies can be used among the could services you have within your tenant.

For an example you should be able to do what is said in here.


Multitenancy in keystores/relying parties:

Again, Cloud Identity lets you store your relying party certificates and keystores. Similar to other scenarios these also tenant specific and blind to other tenants.



Likewise there's more and more scenarios you get to exercise and of course 'apply' in real world using WSO2 Stratos, which has whole of WSO2 middleware platform available in a single environment as services. Instead of having several servers started separately, here you have all the servers available at once. You can intercommunicate with them much easily.