…or should I build my service – vCO/XaaS integration solution on top of vCO general-purpose plug-ins?
Note: This is a revamped version of the document “Should I create a new plug-in for vCO…”, but moving the focus towards vCAC and the role of the vCO plug-ins as key components in vCAC’s XaaS philosophy.
This is the million dollar question, especially after the great success of general-purpose but powerful plug-ins like the HTTP-REST, SOAP, AMQP and Database plug-ins.
The answer is not trivial but in short we could state that:
- If you act as a solution provider or partner and you want to offer to your customers an optimal orchestration/automation solution for your service based on vCO, then you should create a new and specific plug-in for vCO. Furthermore this will allow you also to achieve a complete integration with vCAC in general, and the vCAC service catalog in particular, by exposing your plug-in domain objects as resources and publishing your plug-in workflows as services or as 2nd day operations for those resources.
- If you act as a vCO user or a service provider and you want just to combine different 3rd party solutions inside your own vCO orchestration/automation library, then you should use the existing plug-ins, it doesn’t really matter whether they are specific or general-purpose. In this case, in vCAC, you will still be able to publish workflows from your library as services very easily, but the integration at resource level (visualizing your resources as items and managing them through 2nd day operations) won’t be trivial or even possible at this time.
This document takes mainly the solution provider point of view (all those storage, network, database, load-balancer, etc. providers), and it tries to explain the benefits of building custom plug-ins for those solutions.
So, what advantages will customers have with a dedicated vCO/XaaS plug-in for your service?
More flexibility
With a general-purpose plug-in you have a limited set of building blocks (very basic workflows and actions, and few scripting objects) to build your own plug-in or library on top of it. And you’ll be able just to provide a more or less complex set of actions and workflows.
On the other hand, when you create a new specific plug-in, you can start defining a rich set of scripting objects that are specific to your own domain, and a more complex (but concise) set of actions and workflows on top of them. In this way users will be able to choose the best way for them to use your plug-in, like using directly your higher-level workflow or using your fine-grained scripting objects instead.
Better integration
Related to the previous point, the set of workflows and actions included in your specific plug-in will fit exactly the functionalities and use cases that you want to provide to users. It means that you don’t need to include (nor implement!) any extra workflows or actions to workaround some of the limitations of the general-purpose plug-ins or to hide the complexity of using them internally all the time.
Triggers and efficient long-running workflows
When you develop a plug-in you can create and provide your own triggers to allow users to implement long-running workflows more efficiently. And of course you can provide also your own “waiting for trigger” workflow implementations, to help users to create efficient long-running workflows more easily.
Optimization and performance
When users have to create their own orchestration libraries with vCO plug-ins they are restricted, at the lower level, to the scripting box elements and the vCO’s scripting language. This Javascript-based language is good enough to work with the scripting objects from the plug-ins and to do few things more, otherwise you are quite limited or you need to do some kind of hack or complex workaround to make things work.
But when you create plug-ins you use Java. It means that you have virtually no limitations. Your code will run directly compiled from the source files instead of being interpreted by the vCO’s scripting engine. Moreover, you can implement directly in your code some other optimizations that would be hard (or impossible) to do just from the scripting language. That’s why, things that you can do in Java, it’s better to do them there rather than to do them manually inside scripting boxes.
And if you are really motivated when developing plug-ins you can even try with other JVM compatible languages instead of Java
Better configuration options
Most probably users will need to configure your plug-in somehow. And, ideally for them, this configuration should be consistent with the way other plug-ins are configured. When you create a plug-in from scratch you can decide what the best way to configure your plug-in is. You could still offer a tab inside the vCO Web Configurator to configure all the settings, but preferably you will include in your plug-in some special workflows for configuration purposes.
But if you are using a general-purpose plug-in, first you have to pre-configure it or to provide instructions to the user to configure it. And second, if your plug-in requires some extra configuration, more than the general-purpose plug-in, then you need to handle it manually with some scripting code.
Use of the inventory
This point is especially important if you want to provide some kind of inventory (inside vCO Client’s Inventory tab) together with your plug-in. With this inventory, users can explore the objects that your plug-in exposes, to start workflows from them, and after that, when running workflows, to choose the appropriate input parameters very easily.
And this is quite straightforward to achieve when you develop your own plug-in, but creating your own customized inventory objects is still not possible for a general-purpose plug-in at this time.
Isolation
This is another important aspect to be taken into consideration. If the solution you are providing is dependent on a general-purpose plug-in that you don’t control, users should be aware of it, because any change on the general-purpose plug-in (e.g. regular updates, accidental misconfiguration, etc.) could break your solution. And after that, possible fixes and patches won’t be dependent only on you but on other plug-ins and plug-in developers.
But if your plug-in is isolated from the rest you have a much better control about what you are providing and how you are providing it, and usually at the end this is translated in a better user experience for the customers.
Complete integration with vCAC or XaaS or Your Solution as a Service
One of the most valuable features of vCAC is to provide service catalog users with advanced services coming from vCO. vCAC service architects can do that for any vCO workflow, but having your own plug-in will allow them to:
- Expose your plug-in workflows directly as services.
- Create custom resources for the object types of your model (plug-in inventory types).
- Define custom resource actions (a.k.a. 2nd day operations) for those custom resources.
In other words, consumers of the vCAC service catalog will eventually interact with your solution in an extremely simple way thanks to your custom plug-in.
But then, what are the general-purpose plug-ins useful for?
For vCO users and service providers, to access to any 3rd party solution…
- Because a plug-in for a particular application is not available but the application exposes a SOAP or HTTP-REST API for example.
- Because a plug-in for a particular application is available but it is missing actions that the customer wants to automate. In this case a SOAP or HTTP-REST API could be used while waiting for a future release of the application plug-in that provides broader coverage.
For solution providers and partners, to do some specific tests and to create prototypes and proof of concepts of new workflows and plug-ins.
For vCAC service architects, to offer some relatively simple service to their users through the vCAC service catalog. This kind of simple service won’t be able to define and use custom resources but, developing new workflows, just to create items of predefined resource types and perhaps to contribute with some simple resource actions for those types.
So, as you can see at the end, the general-purpose plug-ins are great for many things but they are not always silver bullets that you can use to integrate anything that you want (e.g. your solution as a provider) within vCO and vCAC. Especially when you are not creating a fully customized orchestration and automation library of workflows but you want to provide the best experience (a custom plug-in) to customers for orchestrating and automating your solution by using vCO and exposing it through vCAC.