Cloud Automation Services: On-Prem FaaS provider for vSphere
In the next days I will come up with a series of blog posts on VMware Cloud Automation Services (CAS). I had the pleasure to work with my colleagues in a "Community of Practice" to evaluate the feature of the VMware SaaS offering. The focus of our research was to find out how CAS can be useful for a service provider. After a quick introduction on our goals, I want to present a brand new feature, the On-Prem FaaS provider for vSphere.
Community of Practice
The community of practice is a collaboration model described in SAFe. It is an interesting model but particularly the voluntary participation can only work in a team that is not fully engaged in their squads with a neverending backlog and lots of operational duties. Like the innovation and planning iteration, it is always endangered to be sacrified to functional requirements or incident resolutions with much higher priority.
Nevertheless I really enjoyed working in a cross-continent team with our colleagues at Swisscom Cloud Lab, Palo Alto.
The goals were clear: how can we integrate and/or migrate vRA/vRO 7.x with the SaaS CAS offering. What are the new possiblities and where do we see gaps, that we have to overcome or to communicate to our customers. Hot topics:
- CI/CD process, manageability of organizations/projects
- VMC on AWS Integration
- Sharing of resources between organizations
- Networking implications of multi-cloud solutions
- Cloud agnostic blueprints – promise and limitation
- Extensibility (integrate backend servers of customers)
Fabian Haldimann and I will present some of our results in a breakout session at VMworld 2019. If your attending the conference don’t hesitate to join us for some good discussions!
Function as a Service Provider on vSphere (on-prem)
Last monday I got the information that the OpenFaaS Appliance for vSphere is already integrated in CAS and that we could start testing it. I will postpone a further introduction into the topic to my next blog and will dedicate this one to this brand new feature.
The installation is really easy, don’t hesitate to try it out yourself. Requirements: a vSphere environment either on-prem or as we did it on VMC on AWS (or any other vSphere appliance in the public cloud). Currently there is only a very basic documentation provided.
I add some screenshots to assure you, that this documentation is really enough to get the integration up and running within minutes.
Start by adding an integration in the infrastructure tab in Cloud Assembly. You will see that a new tile has popped up, awesome!
Cloud Assembly has detected, that you do not have a Extensibility Cloud Proxy install and offers the download link toghether with a token to establish license and communication. Just copy the OVA link and install the OVA on your preferred vSphere environment.
After the successful install – I really used only the basic settings with DHCP – the appliance has to be started. In Cloud Assembly the pop-up is still searching for the newly installed proxy and it will tell you when it has been detected. Here you have to be patient, because it is declaring victory prematurely. It is not waiting for the vRO that is apparently installed as well.
You’d better check the integration details and wait until the vRO is marked as up and running as well. After a little while you are ready to start your first tests:
Create an Action and select the newly available FaaS Provider. Test the action:
OK, these failed. I had to find out, that there are slight differences with regards to language support. I used a nodejs action that used some language constructs that were supported on AWS and Azure but not on OpenFaaS for vSphere. But after having found another similar construct I finally got this greenish outcome:
So this was pretty easy, if you use the generated functions to test it first, you won’t fall into this trap….
What’s under the Hood of the Appliance?
We always want to check all the details of a new service. We were missing the OpenFaaS frontend so we ssh-ed into the appliance and checked what is under the hood. We found a kubernetes installation and checked which ports are open. So in the end we found the frontend under the port 31112. This is in the range that kubernetes randomly assignes to services. Don’t be surprised if yours is running on another port…
So let me close with a few impressions from the OpenFaaS Frontend.
Custom function execution pane…
We found the function that CAS deployed…
Manually deploying new functions…
And there is an open source catalog with existing functions ready to use.
Where to go from here?
Just stay tuned. I will deliver some input for you over the next few days.
Other blog posts in this series: