For those of you who I have had the opportunity to have prior conversations with, CPBM 2.0 is the fruits of our Project Danube that has evolved CPBM from being a product that just vended IaaS offerings to a platform that can now onboard, merchandize, and vend any “X” in the cloud-as-a-service (XaaS).

So what is behind this evolution?

As we have been enabling our Service Provider customers launch IaaS offerings (powered by Citrix CloudPlatform and launched to market through CPBM), it has become clear that for the growing adoption of these IaaS clouds and the success of our customers, more and more workloads need to move to the cloud. And, be made available for consumption to end-users through an expanding self-service catalog that can not only aggregate many such workloads but also offer more and more services of value. A natural progression here would be to add more services related to IaaS such as STaaS (S3-like object storage value propositions), PaaS (developer platforms as a service) leading all the way up to desktops and applications (DaaS), and software available as service (SaaS).

In working with our enterprise customers, a two-faced challenge has been on the minds of decision makers. On the one side, as IT, how do I address the disintermediation that is happening as my business users are consuming more and more services in the public cloud? Where are my assets? On the other side, as a service provider to my business users, how do I solve the disintermediation problem without compromising on the agility my users are so used to from public cloud services? Can I broker services that are sourced from various providers, internal and external, and deliver them in an agile, centralized and coherent manner?

It is in addressing these challenges that we have taken this necessary first step to evolve CPBM into this platform. As we pause at this significant milestone – the release of CPBM 2.0 – it is definitely an evolutionary odyssey that we have begun and will continue even as the number of applications and services in the cloud explode in much the same way websites started to explode in the mid-nineties.

And, what is the technical enabler?

At the core of this transformation is a re-architecture of CPBM to the java-based OSGi framework model for pluggable components. Services that need to be offered via a single portal powered by CPBM can now be brokered – from service subscriptions to showback-reporting and billing – through the development of Service Connectors.

Service Connectors can be developed by DIY teams – Citrix, ISV partner, implementation partner, customer dev teams – using the CPBM CloudService SDK and contributed into the CPBM platform as a componentized OSGi bundle.

And, what does the Service Connector do?

Very simply, it bridges the service endpoint to CPBM so that the service offerings from the endpoint can be on-boarded, merchandized, and vended through the CPBM catalog. Also, think of it as a lightweight product (separate from the CPBM platform) that can be managed independently for its own lifecycle. A simple analogy for a connector would be to a wordpress plug-in.

Tell me more

To implement a connector, a developer will have to be aware of the following high-level steps needed to integrate the desired cloud service to CPBM:

Given information on the service endpoint in the form of a service descriptor file, the connector is first able to onboard the service into CPBM for merchandization. The service descriptor is an XML-based manifest, based on our prescriptive format that will provide metadata about the service that needs to be on-boarded and answer some simple questions:

Who am I?

What do I do?

What do I have to offer?

What am I able to measure and report usage on?

What are the events that I am able to monitor and inform you?

A service that has been bootstrapped based on the metadata and initialized in CPBM can now be dynamically queried for its offerings that can in turn be created as products in CPBM. Products are the finest granular units of consumption that CPBM recognizes, something that can inherently carry a utility price (in many currencies). Products can be packaged into Bundles and published into segmented service catalogs.

Service catalogs are available to CPBM portal users for initiating self-service (or approval-enabled) subscription requests that can in turn through the connector initiate the provisioning of accountsand/or resources in the backend service based on a set of configurations and constraints. This is achieved primarily through implementations within the connector for a set of CPBM-defined SPIs (Service Provider Interfaces).

For services that a CPBM portal user has subscribed to, the connector can then enable the user to have a seamless, single-signed-on access to the resource management UI of the cloud service. Something that can be achieved by the connector developer through a combination of metadata and implementations of ViewResolver interfaces as defined by CPBM.

Lastly and importantly, the connector developer will have to implement SPIs for usage and event collectors. This is what would enable CPBM to take what is essentially raw metered data and process it into rated information for that cloud service that can then be taken up for showbacks and/or billing purposes.

There will be follow-ups to this post with more information on getting started for your connector development. In the meanwhile, please feel free to contact us and stay in touch through this blog’s comment section.