This document includes several common scenarios in which this project may be deployed along with descriptions on why and how it could be deployed in each case.

In this use case, an application may be containerized running on a managed cloud platform that supports containers. Below is a non-exhaustive, alphabetically-ordered list of some examples:

• Amazon ECS
• Azure App Services
• Digital Ocean App Platform
• Google App Engine Flexible Environment

The platform may or may not be autoscaling.

Moving this application to Kubernetes may make sense for several reasons, but the pros and cons of that decision are out of scope of this document.

If the application is being moved to Kubernetes, you would follow these steps to get it autoscaling and routing with KEDA-HTTP:

• Create a workload and Service
• Install the HTTP Add-on
• Create a single HTTPScaledObject in the same namespace as the workload and Service you created

At that point, the operator will create the proper autoscaling and routing infrastructure behind the scenes and the application will be ready to scale. Any request received by the interceptor with the proper host will be routed to the proper backend.

In this use case, an HTTP application is already running in Kubernetes, possibly (but not necessarily) already serving in production to the public internet.

In this case, the reasoning for adding the HTTP Add-on would be clear - adding autoscaling based on incoming HTTP traffic.

Getting the HTTP Add-on working can be done transparently and without downtime to the application:

• Install the add-on. This step will have no effect on the running application.
• Create a new HTTPScaledObject. This step activates autoscaling for the workload that you specify and the application will immediately start scaling up and down based on incoming traffic through the interceptor that was created.

Go back to landing page