Adopting the Eventing Service

While adopting the Eventing Service in your organization, it is important to understand the following considerations.

Existing Couchbase Customers

As a Couchbase customer, the Eventing Service is a good fit for managing all your needs on a single data platform. The Eventing Service integrates seamlessly with your existing Couchbase nodes (FTS, GSI, Query services), and with the Eventing Service you can now manage data mutations. Adding a new Eventing node is simple and a repeatable process.

Workload Isolation

On a cluster, an Eventing node can run long-side with your existing nodes. An Eventing node runs independently and does not affect the system performance parameters of other Couchbase nodes.

No Additional License

For adopting the Eventing Service, apart from the Couchbase Server, you do not need any third-party license.

The Comparing Eventing Service section presents advantage of using an Event based architecture over Polling and Message Queue Based systems.

Data-sets

The Eventing Service works well with different type of data-sets.

As an example, your data-set can consist of credit card transactions from a financial domain, diagnostic vitals from a healthcare domain, ticketing details from an airline, or can be related to purchase order tracking information from an inventory-warehouse domain, the Eventing Service is built in a robust way to handle these data-sets. As an added advantage, on existing data-sets, Couchbase Functions offer an easy way to perform data enrichment. For more information on data enrichment, see the Example section {link}.

Streamlining Business Logic Changes

In earlier Polling or Message Queue implementations, business logics were deeply buried and required modifications to the infrastructure and configuration modules. To accommodate a small business logic change, multiple code-modules had to undergo development iterations.

Leveraging on the Javascript programming language, Couchbase Functions offer an easy way to handle business workflow changes. Post Eventing Service adoption, if your business workflow undergoes modification, then you need to change only your Function handler code. With shorter development cycles, application developers can focus on building quality code and don’t have to worry about infrastructure or configuration related changes.

Testing with Different Workloads

Before running the Eventing Service on your production server, you can perform various validations such as testing with different workloads and Function backlogs, to arrive at an optimized throughput.

As a first scenario, let us consider a case for optimizing Function throughput. In a cluster, you can add more CPUs and allocate additional workers. With added workers, the Function execution time decreases and thereby the throughput optimization requirement gets fulfilled.

Let us consider Function execution backlogs as the second scenario. In a cluster, if the rate of change of events rapidly increase, you notice a steep rise in the Function backlog statistics. In this case, adding additional workers will have no effect on backlog statistics. We need to add another Eventing node. With the new node and as a result of the Eventing Rebalance operation, after certain time, the Function backlog statistics drops to a controllable measure.

Feed Boundary and Restartability

Using the feed boundary option, you can design your handler code in an easy way to manage seasonal traffic events. With the Eventing Service you can run promotional campaigns such as Cyber Monday and Black Friday.

In your Test Environments, you can deploy a Function to start tracking events, undeploy to pause, then deploy again to restart event-tracking and thereby validate the Functions execution restartability feature.

After validating feed boundary and restartability, with an increased confidence, you may be comfortable to port your Functions from a Test to a Production Environment.

Eventing Service and Cross Data Center Replication (XDCR)

Couchbase, using the XDCR option, provides a method for onboarding cluster nodes which are running on prior release versions. You can replicate(XDCR) data between your current cluster node (let us say, running on Couchbase Server Release 4.0 version) with a new Eventing Node running on Couchbase Server Release 5.5 version or higher. Once the XDCR operation is complete, you can deploy Functions on the new Eventing node and start tracking data mutations.

In the Eventing node, during an XDCR operation, replication of defined Functions are not supported.

As you can infer from this section, any individual consideration or any combination of considerations such as data-sets, deploying business logic along-side data, scaling, feed boundary and restartability considerations, are compelling and helps while adopting the Eventing Service in your organisation.