There has been some excellent feedback about Project Rainmaker from those who have had a chance to see it. I am very happy with the response so far and hope that we can get more people involved and excited about this new technology.
One question that has come up from several people is: how do CloudPortal Services Manager (formerly known as Cortex) and Rainmaker fit together? Is there an overlap in functionality? Does one replace the need for the other?
The answer is:
- Neither Services Manager nor Rainmaker replaces the other.
- Neither Services Manager nor Rainmaker requires the other, either.
- There is very little overlap between the two; the only overlap exists where it is needed to enable either product to function independently.
- Services Manager and Rainmaker are complimentary: “Better Together”.
It might be helpful to start by explaining what Rainmaker is, since it is the newer and less-well-known product.
Citrix has been active in the cloud computing space for quite a while (several years now). Our XenApp and XenDesktop technologies, our excellent WAN performance, and our experience with security and isolation, all contribute to our ability to step up as a leader in the cloud. We have been doing “Desktops as a Service” and “Windows Apps as a Service” for just about the entirety of our company’s history. Usually in the past those “Services” were provided by an IT organization within a company, but our technology is equally suited to outsourced IT.
Moving to the cloud space presents some new challenges around systems management. Multi-tenancy, larger scale deployments, and security/isolation concerns mean that it is no longer acceptable to limit configuration to a single farm scope. The ratio of users to administrators must be much higher in the cloud space, to keep costs down and margins acceptable; this means we must automate our systems more, we must enable more self-service, and we must make our configuration more “repeatable”. By this I mean that once a configuration has been tested, it must be easy to replicate it in a way that doesn’t invalidate the prior testing.
It is certainly possible to use XenApp and other Citrix products today to create a successful CSP business. We have guidance available now in the form of whitepapers which outline the best way to set up, deploy, and maintain XenApp with CSP concerns in mind, with proper tenant isolation. This is our CSP Reference Architecture. However following the Reference Architecture is not always straightforward. It requires a high degree of knowledge and skill to achieve the proper configuration. Maintenance over time, such as adding and removing servers to handle changing load, or updating servers with a patch, is still a manual multi-step process. The management tools provided with XenApp are not multi-tenant aware and therefore do not provide much assistance in determining what services each tenant has available, what servers they are using, etc. Each of the Citrix products requires a different type of configuration in order to configure multi-tenancy properly, and there is no protection against a mismatch such as a PCM workload not matching a XenApp worker group.
Project Rainmaker was created to address these problems. Please note: this is not the final name of the product; just the internal codename. Specifically, Rainmaker’s charter is to do three things:
- Enable a single multi-tenancy model for DaaS and Windows-apps-as-a-Service (WaaS).
- Enable cloud-scale deployments of DaaS and WaaS. This means multiple farms, but also in the future, multiple products and multiple versions.
- Simplify management of DaaS and WaaS within the prescribed CSP Reference Architecture.
Rainmaker achieves these goals by providing a configuration system that has a multi-tenant data model with flexible isolation concepts at its core (such as being able to choose separate isolation modes per-service), a simple UI, and automated workflows that control XenApp, Active Directory, Web Interface, and other products behind the scenes.
What Rainmaker does not do is to manage other types of services, other than DaaS and WaaS. Rainmaker does not provision users to Sharepoint sites, or to ShareFile storage space, or to SQL databases. It is not designed to do so. Rainmaker can manage service isolation and server provisioning for a hosted Microsoft Outlook application, but does not manage the Exchange inboxes for users who subscribe to Outlook. For that, you should look to CloudPortal Services Manager.
CloudPortal Services Manager
Formerly known as the Cortex Control Panel, CloudPortal Services Manager operates at a higher level than Rainmaker. As the name suggests, it is designed to manage services of all types. It supports a large number of services already, and more can be added via the SDK.
When Services Manager is used to provision a service for a user, it communicates with back-end systems using customized business logic for each system, in order to make the service available to the user. For instance, if an Exchange inbox is provisioned for a user, Services Manager will communicate with Exchange to add the inbox. Exchange must already have been pre-configured to be installed, functional and to have the appropriate storage groups. If a hotfix for Exchange comes out, it is up to the administrator to apply the hotfix to all Exchange servers without causing a service outage.
Services Manager currently supports a limited form of service provisioning with XenApp. It can be used to provision users to applications and desktops which have already been published within a XenApp farm. Managing the properties of the apps and desktops, and the servers on which they run, still must be done manually outside of the Services Manager console.
To summarize, Services Manager is designed for provisioning users to services, but it is not designed to install, configure, manage the capacity, or manage the lifecycle of those services. For that, you must use the consoles or configuration tools provided by the services themselves. It would be impractical for Services Manager to contain a superset of all configuration provided by all of the services it manages. Still, there is incredible value in the user provisioning aspect that Services Manager provides, because it is by far the most common type of configuration change needed on a day-to-day basis, and it is the aspect of configuration which is naturally suited to provide as self-service.
The relationship between Rainmaker and Services Manager, then, is similar to the relationship between the Microsoft Exchange Management Console and Services Manager. The former is used to configure and manage the service; the latter is used to provision the (already configured) service to customers, tenants, and users, along with all other types of services.
Using Rainmaker, a CSP admin can advertise Desktops and Windows Apps as Services. They can manage the workloads that host those desktops and apps. They can monitor which tenants are using the apps, and which users within those tenants are using the apps. They can manage service updates, such as rolling out a hotfix or service pack, without causing service interruptions.
Using Services Manager, a CSP admin can take those Desktops and Windows App Services, and provision them to customers, tenants, and users. They can delegate which services each tenant is allowed to see or subscribe to. They can bundle a hosted Microsoft Outlook WaaS service with a hosted Exchange inbox. They can give their customers and tenants the ability to do self-service, such that all they need to do is select an application and add users. Services Manager leverages Rainmaker under the covers, and Rainmaker makes sure those services are correctly hosted, provisioned, and isolated.
The two products truly enhance each other and provide an end-to-end solution for DaaS and WaaS.
…But still good, even apart
If you choose to use only Services Manager, with the limited XenApp provisioning support already available, that will continue to be available for you. There is a cost to migrate to Rainmaker and we do not force that cost on anyone. Eventually, I believe CSPs will recognize that the benefits of Rainmaker outweigh this cost and will migrate to it naturally, as they would have migrated to newer farm versions anyway.
If you already have a Control Panel and it isn’t Services Manager, there are two ways to leverage Rainmaker by itself:
- Rainmaker will provide an SDK with everything needed to integrate any Control Panel with it. The public Rainmaker SDK will be the same one used by Services Manager, so other Control Panels will have the same access to its functionality.
- Rainmaker will provide an end-to-end UI for provisioning DaaS and WaaS to tenants and end-users. It is much more limited than what Services Manager provides, and it is not capable of providing self-service, but it is there to help those whose Control Panels are not yet integrated with Rainmaker.
I hope that this post has been informative and has helped to reduce some of the confusion around the two products and how they fit together. Keep watching this space for more information about Rainmaker in the future.