By Mariusz Chwalek · June 2 2017

A quick update note on where we are with some of our Cloud Plugins.
Originally when we started working with customers on more integrated automation solutions, what often referred to as “Full Stack” provisioning, the mechanism of putting it all together was generally an external orchestration system. It would take responsibility for the provisioning of the target Operating System, storage, compute, network, etc. - and then make a call to RapidDeploy via a RESTful web services API for us to carry out some automation on an already provisioned infrastructure. The external provisioning tool (HPSA, vRealize Orchestrator, Cloud Formation, etc.) would take responsibility for provisioning the infrastructure via it’s integrations with the public / private cloud - and delegate specialised tasks to be performed via RapidDeploy.
It is/was relatively easy to pass in host details, credential, etc. to allow RD to connect and the delegated automation activities (install Jetty or WebSphere, Configure it, Deploy App., etc.) to be carried out. This is how many customer architect full stack provisioning solutions still today.
If the explanation above is clear though - you will probably realise that we did not require a plugin to the cloud providers in order for this to happen (we just needed to have an API that other tools could use to call us).
So Why do we need Cloud Provider Plugins?
The simple answer is that there are increasing numbers of use cases that have required us to. I’ll give a couple of examples below:
  1. A server instance is not running on a Cloud Provider. Let’s say you have, sensibly, configured AWS CloudWatch to shutdown development and test instances that have not been used for some hours. Then - a developer checks in some code, or a release manager wants to deploy a new version of code / configuration to a target. We don’t want to re-provision, but perhaps just start a provisioned instance and update it. In this use case we want to know some information about an instance and connect to the cloud provider, retrieve the credentials/IP to connect to it, etc. and start it.
  2. A Server Instance does not exist. In RD we allow the creation of a logical server definition. You can define what software is installed, how it is configured, what apps are installed - but it does not exist / has not been created. In this use case we want to be able to deploy an application, with all its dependencies on one or more servers, and if they don’t exist on a cloud provider (we obviously need to provide RD with some information - key, credentials, machine image to provision, etc.)
  3. Provision / Configure other infrastructure. So it is of course not just servers that need configure on cloud infrastructure - network, storage, etc. may also need to be configured for an application to work.
  4. Scaling. We may want to scale an already existing application - so create more hosts of a certain type.
OK - so hopefully from the explanation above you understand a little of what our cloud plugin providers can do,  how you can use them and that we have new updated to the Plugins for AWS, Azure and VM Ware. As ever - a full list of plugins are here.

Topics: VMware, AWS, Azure