All enterprise IT systems follow an architectural continuum blending old and new technologies and systems. The traditional approach to architecture was to use an integrated vendor ecosystem that provided tightly coupled products. Requirements driven from adopting a multi-cloud approach brought the challenge of integrating heterogeneous ecosystems and services.
Now, event-driven architectures are replacing that traditional way of thinking. Event-driven architectures have grown in popularity because they ease the process of successfully adopting heterogeneous architectures.
What is Knative?
Knative is a Kubernetes-based platform for deploying, running and managing serverless applications. The Knative Serving component provides autoscaling (even to zero) and revision tracking of the serverless functions. The Knative Eventing component allows the subscription, delivery and management of events. Knative Eventing providers facilitate event source integrations with multiple public cloud products and services. The Knative eventing component has two sub-components: Broker and Trigger. Kubernetes has an Event Source resource that links an event producer and an event sink. The Knative Eventing Broker component acts as an event sink. The Eventing Broker enables events attributes to select events. The Eventing Trigger calls the Serving component based upon a filter on the event attributes.
VMware Event Router overview
The VMware Event Router is an event provider for VMware vCenter Server and VMware Horizon events to Knative. If you would like to explore the power of a vSphere event-driven architecture and you have an existing Knative deployment, you can deploy it using this Helm Chart. If you’re just getting started and would like to get going quickly, consider the VMware Event Broker Appliance (VEBA). The Knative architecture is modular, and the appliance provides the required components on a single appliance. The appliance OVA installation takes parameters that configure the event router with a binding to vCenter Server.
vCenter Server Knative example: Event-driven function
The VMware-samples GitHub repository contains a folder containing example Knative functions. The most simplistic example of a function is kn-ps-echo. This configures an unfiltered Knative Eventing Trigger and provides a Knative Serving component written in Powershell, which outputs to Stdout.
A Knative function requires a container image. The example function is in a publicly available repository named projects.registry.vmware.com/veba/kn-ps-echo. Within the “example” folder is the Dockerfile used to create the container. We can see this defines a Powershell runtime environment with the CloudEvents SDK and ThreadJob modules installed. Two Powershell scripts are copied in server.ps1 and handler.ps1. That server.ps1 executes when the container starts. The server.ps1 acts as a System.Net.HttpListener, which receives the event and on message receipt passes this on to handler.ps1 to execute.
As the manifest file and dependant container image are publicly available to test, we can just execute the manifest file and it will create the Knative kservice and trigger resources.
vCenter Server constantly generates events and as the example has an unfiltered trigger events are output to Stdout. We can view the output by looking at the log file of the container executing the script. If we list the pods in the VMware-functions namespace and filter using function name we can see two pods and the deployment pod has two containers.
The scripts are run in a container named user-container in the deployment pod so we can follow its logs and see the flow of vCenter events echoed.
We can see all events are of the same Type: but the Subject: is populated with the Event name.
Note: At the time of running the kn-ps-echo didn’t seem to be working correctly as it did not output the CloudEvent Data.
Creating a vCenter Server Knative example: Event-driven function
We’ve seen how simple it is to consume a pre-built function, and luckily, it’s just as simple to create a pre-built function to meet a a bespoke need.
Start off by thinking about a use case for event-driven architecture. I got a lot of value from eventing in AWS in forming loosely coupled relationships between discreet systems and maintaining synchronicity of state between the systems. vCenter Server and vRealize Operations Manager both have maintenance mode. When performing lifecycle management tasks, it’s common to enable this mode on both products. Here, I’ll look at the use case where I set vCenter Server maintenance mode to the event triggers functions, which then mirrors the state in vRealize Operations Manager.
The first thing we need to do is identify the vCenter Server event created when a host is placed in maintenance mode. Checking the event documentation we can find the two events are EnteredMaintenanceModeEvent and ExitMaintenanceModeEvent. Next, we need to establish an API call to set state in vRealize Operations Manager checking the API documentation the markResourceAsBeingMaintained can be used to mark and unmark resource maintenance mode. I’ll start by creating a container image for the “enter” event. The kn-ps-echo example Dockerfile and server.ps1 contain nothing I need to change, so they can be reused.
What I do need to do though is create a handler.ps1, which takes input from the event and calls REST API of vRealize Operations.
To be environmentally agnostic, I have the script use Environment Variables. These can be stored in a Kubernetes Secret resource that can be associated with the containers and available at script runtime.
With the Dockerfile and scripts in place, we can build the container image locally and then push this to a public container registry.
Once the container is available in the public repository, I can create a Knative service and trigger resource that links to the container image and has an association with the secret:
The exit function is logically laid out the same but with a slightly different trigger filter and handler action. With the manifest files created, both can now be applied.
Once we pull down the container image from the repository, we can check the created resources.
With the functions in place, we can follow the logs on the container and place a host into maintenance mode to check that it works.
Adopting a Knative event-driven architecture
Interested in finding out how to get more value from your existing investment and modernizing your enterprise IT systems? Your VMware Success 360 architect can assist you with more use cases and help you adopt an event-driven architecture.
