This chapter is from the book
This chapter is from the book
This chapter is from the book
OCI Events Service
All OCI services emit events. Events can be thought of as status updates about lifecycle state or activities that these services are performing. The occurrence of a change, such as a compute instance being created (“Instance creation started”) or the completion of a block volume backup (“Block Volume backup complete”), can be represented as events. Events typically capture some context about the occurrence so that the event is actionable. An example is the OCID of the compute instance that was created. A downstream system can potentially take action based on this contextual information that is captured in the event. In large distributed systems like cloud platforms such as OCI, numerous services and components can emit events that signal their normal operations; in most cases, only a few events would be interesting and acted upon. With voluminous events being produced, the Events service provides a way to listen to or filter only interesting events and then use the context captured in the event to take an action. Although any system can emit events, in the context of the OCI Events service it is the OCI services that emit events.
In a general sense, events are a way for systems to communicate facts about their operations or statuses to other systems. Although events might sound similar to a message in a messaging system, an event described using the CloudEvents format represents a fact. As a signal about the occurrence of a change in a system and bundled with contextual information about the change, an event is not particularly intended for any one consumer. An event also notably lacks intent. This contrasts with messages, which usually convey some intent from one system to another. As cloud platforms gain popularity and application design evolves to become distributed, resilient, and more aware of its surrounding systems, events play a crucial role in enabling that transition. This has also led to a proliferation of event formats, which limits the interoperability of events across platforms. The CNCF project CloudEvents is an emerging standard that aims to unify how event publishers can standardize on the format used to describe an event. This enables events to be described in a standardized manner so that developers can build systems that can interoperate and handle events across cloud platforms. The OCI event service uses the CloudEvents format to describe events. Listing 3-5 shows an OCI event that uses the CloudEvents specification.
Listing 3-5 OCI Event Using the CloudEvents Specification
{
"eventType": "com.oraclecloud.computeapi.launchinstance.end",
"cloudEventsVersion": "0.1",
"eventTypeVersion": "2.0",
"source": "ComputeApi",
"eventTime": "2019-08-16T12:07:42.794Z",
"contentType": "application/json",
"eventID": "unique_ID",
"extensions": {
"compartmentId": "ocid1.compartment.oc1..unique_ID"
}
"data": {
"compartmentId": "ocid1.compartment.oc1..unique_ID",
"compartmentName": "example_compartment",
"resourceName": "my_instance",
"resourceId": "ocid1.instance.oc1.phx.unique_ID",
"availabilityDomain": "availability_domain",
"additionalDetails": {
"imageId": "ocid1.image.oc1.phx.unique_ID",
"shape": "VM.Standard2.1",
"type": "CustomerVmi"
}
},
}
The structure of the event message can be broken down into two broad parts:
The event envelope: The event envelope encompasses all the attributes at the top level, including the eventID, version, eventType, and other attributes. The event envelope is based on the cloud event specification, and the eventType usually provides the most basic mechanism to identify specific events to filter for processing. In the example presented in Listing 3-5, the value for eventType is com.oraclecloud.computeapi.launchinstance.end, and predictably it represents the completion of a compute instance launch.
The payload: The data or payload that is pertinent to the event itself is contained in the data attribute. The content and structure of the JSON payload differ for each event type, to be pertinent to the event. The schema for the payload can also be versioned to support schema evolution. This is when the content of the payload and its structure change over time to support newer attributes and features. The eventTypeVersion can be used to indicate what version of the payload structure or data schema the payload is using for the event type.
Services emit events continuously. You work with events by creating rules that match only certain event types, tags, or attributes contained in the event payload itself. The filtered events are then delivered to a target service that can act on the event. The OCI event service supports Notifications, Streaming, and Functions as target services where filtered events can be delivered.
Any attribute of the event can be used to filter events into a flow of events that a developer would be interested in. The filtering is done by creating conditions. Conditions match the event message structure and produce a flow of events that match the conditions, which can now be delivered to a target service. Conditions can use various operands such as any, all, or even wildcard-based matching. Figure 3-13 shows the console with a matching rule.
)
FIGURE 3-13 Working with the Events Service to Create a Matching Rule and an Action to Trigger When the Rule Condition Is Met
The console provides an intuitive interface to create and validate rules with sample payloads and tests for matching conditions. Here you see that a matching rule has been created for the event type com.oraclecloud.objectstorage.createobject. This event type represents an event for which a new object has been created in object storage—in other words, a new file has been uploaded to an object store bucket. The conditions further check whether the bucket where the new object has been created is named flat_files_to_process.
After events have been filtered, the filtered events are directed to one of the supported target systems, such as streaming, functions, or notifications. The broad goal here is for the downstream systems to process the event data to perform an action. For instance, when an object storage bucket has been created, the event that notifies the completion of the bucket creation could be used to run a serverless function on a regular schedule to check for data inside this bucket.
In the example, there is a single action to invoke a specific function. The event will cause the function to be triggered, and the function can take any action based on the event data. In the example, you can presume that the function will use the event payload to access the file uploaded into the object storage bucket and perform some ETL job to import the data contained in it to a database. In this example, the event-driven model with a serverless function allows developers to build completely event-driven applications that process data when data becomes available so that they do not have to worry about infrastructure management.
The same event-driven principles can be applied to a variety of situations. The event service therefore enables application developers to build applications that can react to changes in the infrastructure and events or occurrences happening in the infrastructure layer directly, and then react to them from within their applications. This means that developers can build applications that are more resilient, autonomous, and elastic, thereby making the event service an important tool in building cloud native applications.