Cloud Automation Services: Extensibility

This post in my series on VMware Cloud Automation Services (CAS) introduces Cloud Assembly Extensibility. I want to point to some helpful blog posts, discuss how we are using vRA 7.x Extensibility and the requirements we have to meet to use the new CAS features for event subscription and processing. The new On-Prem FaaS provider based on OpenFaaS is in the center of these considerations.

Introduction into Cloud Assembly Extensibility

The excellent blog by Cody De Arkland (together with the linked one by my colleague Kaloyan Kolev), the samples on his GitHub repository and my experiences with the vRA 7.x Extensibility Framework allowed a jump start into the topic. From Simon Lynch & Tony Phan please find another great blog post on very similar topics. I don’t repeat the facts that are outlined in these blogs and will directly focus on Swisscom’s requirements and expand on topics that are not already covered in depth.

Some additional hints from my side:

  • Cody concludes his blog with mentioning „blocking“ subscriptions. These are very important, because the orchestrator does not only wait for the result but it can be replied (values can be changed) or the orchestrator flow can be terminated (rolled back). Check out the samples from Cody, you will find how to change values. If you want to abort the processing, just throw an exception. This is the only possiblity for our customers to control the processing flow: they can deny a further execution.
  • Deploying a new or changed ABX function can be time consuming, on Azure I have measured up to 30 secs to setup up a function. It makes sense to force deployment by explicitly testing the function. I had to do this for automatic testing because a burst of function calls can influence the execution time – every call triggers a deployment instead of a reuse of a already deployed function. This led to race conditions.
  • I had some problems when I started to change or release functions on CAS that should be controlled by GIT. CAS commites changes with a so called exportId. Any subsequent refresh of changes triggered from GIT failed so far. I cannot explain it by now and have to investigate this effect further.

Main use case for Swisscom

Swisscom is providing virtual private cloud for its customers, mostly large enterprises with a broad existing IT landscapes. When they do the first steps on the journey to the cloud, the cloud installations are only a tiny fraction of the overall IT infrastructure. Usually they do not want to redesign all their existing processes on these new possibilities. They want to leverage the already introduced ITSM systems, CMDB, IPAM, DNS and with a pay-as-you-go offering, they will try to have the machines started and stopped according to their needs to reduce costs. For the productive system we’re using vRA 7.6 lifecycle events. We enrich them to make them easily usable and post each event to a REST endpoint defined per tenant (customer).

Many of our customers have regulatory requirements to keep all their data in Swiss hosted data centers.  This is a challenge for us, because it is not accepted to use Azure Functions or AWS Lambda – because of the compute region and the challenges that network contexts in the public clouds can pose.  Here the VMware Appliance for Extensibility comes to the rescue. We can now reconsider to move quite an amount of needed functionality direct on OpenFaaS on-prem.

 

PoC for the Swisscom requirements: we forward all compute lifecycle events to an endpoint (usually operated by our customer)

 

Action runs with the ABX function provider setting „Auto“

 

ESC Event Subscriber

  • Latest version of a reference application that our customers can use to process events.
  • Enriched with a CMDB sample and an event list feeded by server sent events.
  • Angular frontend based on Clarity is packaged with spring boot directly (only one server).

Deployment via GIT

I have added some CAS management functions to enable automated deployment of ABX functions. Following the blogs by Cody I created a GIT integration per project. In order to automate these tasks I used the CAS API, a fine introduction into the new API can be found in this blog.

Create a project source:

POST https://api.mgmt.cloud.vmware.com/content/api/sources

{
    "type": "com.github.saas",
    "config": {
        "path": "actions",
        "branch": "vmworld2019",
        "repository": "repository/scscopcas",
        "contentType": "ABX_SCRIPTS",
        "projectName": "vmworld 2019",
        "integrationId": "126192f657b3d87558e235740ac2e"
    },
    "projectIds": ["3b1a0017-dccd-4958-964e-229cb73a2dbb"],
    "name": "GitHub CS",
    "syncEnabled": true
}

return:

{"id":"356052c1-32d1-479c-b3c9-41ace145c20e"}

This will automatically publish the actions in Cloud Assembly only and returns the ID of the source.

If you want to trigger a synch on that resource, you can issue the following request:

POST https://api.mgmt.cloud.vmware.com/content/api/sourcecontrol/sync-requests

{"sourceId":"491d3234-e473-4351-9291-11a15ddf99a4"}

return:

{
    "requestId": "96619caa-2d34-4b5f-b854-0444d987ceea",
    "sourceId": "491d3234-e473-4351-9291-11a15ddf99a4",
    "contentSourceId": "491d3234-e473-4351-9291-11a15ddf99a4",
    "projectId": "3b1a0017-dccd-4958-964e-229cb73a2dbb",
    "status": "REQUESTED",
    "message": "Sync requested",
    "createdAt": "2019-07-20T19:15:02.878Z",
    "lastUpdatedAt": "2019-07-20T19:15:02.876Z"
}

This is a newly created synch request, you can poll for the outcome with

GET https://api.mgmt.cloud.vmware.com/content/api/sourcecontrol/sync-requests/96619caa-2d34-4b5f-b854-0444d987ceea

This is a very interesting feature and shows how open CAS has become in comparison with vRA 7.x. Alex Ellis, founder of OpenFaaS, showed me how easy managing FaaS can be: you can basically edit the function code directly in the WebIDE of your GIT provider, if a webhook is installed as OpenFaaS Cloud is offering the deplyoment is automatically performed.

You may have noticed in the blog of Cody for the actions a bidirectional GIT support is already available. If you edit the action on the CAS frontend, the changes are propagated back to GIT. This is not (yet?) the case for blueprints, but let’s leave this discussion for my next post…

 

Other blog posts in this series:

Cloud Automation Services: On-Prem FaaS provider for vSphere

Custom Forms with vRealize Automation Cloud

CI/CD with vRealize Automation Cloud

vRealize Automation Cloud – Infrastructure as Code

vRealize Automation Cloud – Code Stream

Open Service Broker for vRealize Automation Cloud