Event-driven computing is hardly a new idea; people in the database world have used database triggers for years. The concept is simple: whenever you add, change, or delete data, an event is triggered to perform a variety of functions. What’s new is the proliferation of these types of events and triggers among applications in other areas like Auto scaling, Auto-remediation, Capacity Planning etc. At its core, event-driven architecture is about reacting to various events on your systems and acting accordingly.

Autoscaling (in one or other way a kind of automation) has become an integral component in almost all the cloud platforms, microservices aka containers are not an exemption. In-fact containers known for flexible and decoupled design can best fit in for auto-scaling as they are much easier to create than virtual machines.

Why Autoscaling????

Capacity Scaling — Autoscaling

Scalability is one of the most important aspects to consider for modern container based application deployments. With the advancement of container orchestration platforms, it has never been easier to design solutions for scalability. Kubernetes-based event-driven autoscaling, or KEDA (built with Operator Framework), as the tool is called, allows users to build their own event-driven applications on top of Kubernetes. KEDA handles the triggers to respond to events that happen in other services and scales workloads as needed. KEDA enables a container to consume events directly from the source, instead of routing through HTTP.

KEDA works in any public or private cloud and on-premises, including Azure Kubernetes Service and Red Hat’s OpenShift. With this, developers can also now take Azure Functions, Microsoft’s serverless platform, and deploy it as a container in Kubernetes clusters, including on OpenShift.

This might look simple but assume a busy day with massive transactions and will it be really possible to manage the number of applications (Kubernetes Deployments) manually as shown below???

Managing Autoscaling at Production

KEDA will automatically detect new deployments and start monitoring event sources, leveraging real-time metrics to drive scaling decisions.

KEDA

KEDA as a component on Kubernetes provides two key roles:

1. Scaling Agent: Agent to activate and deactivate a deployment to scale to configured replicas and scale back replicas to zero on no events.
2. Kubernetes Metrics Server: A metrics server exposing multitude of event related data like queue length or stream lag which allows event based scaling consuming specific type of event data.

Kubernetes Metrics Server communicates with Kubernetes HPA (horizontal pod autoscaler) to drive the scale out of Kubernetes deployment replicas. It is up to the deployment to then consume the events directly from the source. This preserves rich event integration and enables gestures like completing or abandoning queue messages to work out of the box.

KEDA Architecture

Scaler

KEDA uses a “Scaler” to detect if a deployment should be activated or deactivated (scaling) which in-turn is fed into a specific event source. Today supports multiple “Scalers” with specific supported triggers like Kafka (trigger: Kafka Topics), RabbitMQ (trigger: RabbitMQ Queues) and have many more to come.

Apart from these KEDA integrates with Azure Functions tooling natively extending Azure specific scalers like Azure Storage Queues, Azure Service Bus Queues, Azure Service Bus Topics.

ScaledObject

ScaledObject is deployed as a Kubernetes CRD (Custom Resource Definition) which brings the functionality of syncing a deployment with an event source.

ScaledObject Custom Resource Definition

Once deployed as CRD the ScaledObject can take configuration as below:

ScaledObject Spec

As mentioned above different triggers are supported and some of the examples are shown below:

Trigger Configuration for ScaledObject

Event Driven Autoscaling in Action — On-Premises Kubernetes Cluster

KEDA as Deployment on Kubernetes

KEDA Controller — Kubernetes Deployment

RabbitMQ Queues Scaler with KEDA

RabbitMQ is a message-queueing software called a message broker or queue manager. Simply said; It is a software where queues can be defined, applications may connect to the queue and transfer a message onto it.

RabbitMQ Architecture

In the example below a RabbitMQ Server/Publisher is deployed as a ‘statefulset’ on Kubernetes:

RabbitMQ

A RabbitMQ consumer is deployed as a deployment which accepts queues generated by the RabbitMQ server and simulates performing.

RabbitMQ Consumer Deployment

Creating ScaledObject with RabbitMQ Triggers

Along with the deployment above, a ScaledObject configuration is provided which will be translated by the KEDA CRD created above with installation of KEDA on Kubernetes.

ScaledObject Configuration with RabbitMQ Trigger

ScaledObject on Kubernetes

Once the ScaledObject is created, the KEDA controller automatically syncs the configuration and starts watching the rabbitmq-consumer created above. KEDA seamlessly creates a HPA (Horizontal Pod Autoscaler) object with required configuration and scales out the replicas based on the trigger-rule provided through ScaledObject (in this case it is queue length of ‘5’). As there are no queues yet the rabbitmq-consumer deployment replicas are set to zero as shown below.

KEDA Controller on Kubernetes

Horizontal Pod Autoscaler created by KEDA

RabbitMQ Consumer — Replica:0

With the ScaledObject and HPA configuration above KEDA will drive the container to scale out according to the information received from event source. Publishing some queues with ‘Kubernetes-Job’ configuration below which produces 10 queues:

Kubernetes-Job to publish Queues

KEDA automatically scales the ‘rabbitmq-consumer’ currently set to ‘zero’ replicas to ‘two’ replicas to cater the queues.

Publishing 10 queues — RabbitMQ Consumer scaled to two replicas:

10 queues — 2 Replicas

Scale to : 2 — Scale down: 0

Publishing 200 queues — RabbitMQ Consumer scaled to forty (40) replicas:

200 queues — 40 Replicas

Scale to : 40 — Scale down: 0

Publishing 1000 queues — RabbitMQ Consumer scaled to 100 replicas as maximum replicas set to 100:

1000 queues — 100 Replicas

Scale to : 100 — Scale down: 0