What is a good software?

One of answers is doing the right things, with as little cost in operations as possible.

How can we reduce operations costs?

We can use autoscaling

Autoscaling, also known as automatic scaling, is a cloud computing feature that allows you to automatically adjust the capacity of your resources based on actual workload. This capability ensures that you have the right amount of computing resources available to handle varying levels of demand without manual intervention. Auto Scaling is commonly used in cloud environments, like Amazon Web Services (AWS) and Microsoft Azure, to maintain high availability, optimize costs, and improve system performance.

Types of Autoscaling

• Vertical Pod Autoscaling — VPA (Up and Down)
• Horizontal Pod Autoscaling — HPA (Out and In)
• Dynamic Autoscaling
• Predictive Autoscaling
• Event-Driven Autoscaling

Event-Driven Autoscaling

Event-Driven Autoscaling allows you to trigger scaling actions based on specific events or conditions. For example, you can scale your application in response to increased user traffic, the arrival of new data, or the launch of a specific job.

KEDA

KEDA stands for Kubernetes Event-Driven Autoscaling, is an open-source project that provides event-driven auto-scaling for container workloads running on Kubernetes. It enables Kubernetes applications to scale based on external events, such as messages arriving in a queue, the number of HTTP requests, or custom event triggers. KEDA helps make your applications more efficient, cost-effective, and responsive to changes in workloads.

Why Event Driven with KEDA

Kubernetes allows you to autoscale in various ways: horizontally, vertically, or by nodes.

Disadvantages of another solutions

• Supporting only standard Kubernetes objects (deployment, stateful set, replica set) and relying on the metrics server
• There isn’t a way of observing their behavior, so you need to devise your own set of KPIs to see if they’re behaving as expected. So, if HPA or VPA aren’t working as expected for some obscure reason, you won’t receive precise alerts.
• There is not a metric adapter compatible with your data source to build autoscaling rules based on custom metrics. If you have no metric adapter available, you need to stick to resource metrics (CPU or memory).

KEDA vs Traditoinal Autoscalling

Why Event Driven with KEDA

KEDA fills two gaps which you will face while building distributed, cloud-native application at

massive scale.

1. KEDA gives you more control. More control over your instances in contrast to running them

in the public cloud. You can leverage existing Kubernetes cluster and run your, i.e. Azure

Functions, right next to other application building blocks of your overall architecture. KEDA

allows you to specify custom boundaries for scaling behavior.

2. On the other hand, KEDA lets you scale deployments in Kubernetes based on external

events or metrics. In Kubernetes, you can use Horizontal Pod Autoscaler (HPA) to scale

Deployments based on metrics generated inside of the cluster. Especially when running

Kubernetes in combination with external, cloud-based services such as Azure Service Bus,

your application artifacts have to scale on those external metrics.

KEDA provides a structured, streamlined strategy of how to address those needs without adding

much complexity to your overall architecture.

Key Benefits of KEDA

• Efficient Resource Usage
• Event-Driven Architecture
• Cost Optimization with scale-to-zero
• Flexible Integration (50+ scalers)
• Improved Performance

Potential Cost Savings

• Traditional HPA: always keeps minimum pods → higher cost
• KEDA enables idle apps to scale to zero
• Reduces compute resources
• Example: batch processor scaling from 0 to 10 saves up to 70%

KEDA architecture 

KEDA monitors your event source and regularly checks if there are any events. When needed, KEDA activates or deactivates your pod depending on whether there are any events by setting the deployment's replica count to 1 or 0, depending on your minimum replica count. KEDA also exposes metrics data to the HPA which handles the scaling to and from 1.

Key components of KEDA

• Scaler: Connects to an external component (e.g., ServiceBus) and fetches metrics (e.g., queue depth)
• Operator (Agent): Responsible for “activating” a Deployment and creating a Horizontal Pod Autoscaler object
• Metrics Adapter: Presents metrics from external sources to the Horizontal Pod Autoscaler

Use Case example. WebApp, ServiceBus, Azure Function

Recap

• KEDA is a thin layer built on top of Kubernetes to allow scalable message processing using Azure Functions and other development models. It gives you more fine-granular control over scale-in and scale-out operations, which generally happen behind the scenes when running Azure Functions directly in Azure.
• Although KEDA has first-class Azure Functions support built-in, it is not limited to Azure Functions. The concept works for all kind of message-driven applications that has to be scaled based on metrics such as messages in an Azure Service Bus.
• Reduce costs, improve responsiveness
• Ideal for bursty, event-based workloads
• Works across cloud and on-prem