Keda Bundle Laravel Package

Technical Evaluation

Architecture Fit

• Use Case Alignment: The dealroadshow/keda-bundle enables PHP-based definition of KEDA (Kubernetes Event-Driven Autoscaling) CRDs, bridging PHP and Kubernetes-native scaling logic. This is a niche but powerful fit for:
  • Event-driven PHP microservices (e.g., queues, HTTP triggers, cron jobs) where scaling is tied to external events (e.g., RabbitMQ, AWS SQS, or custom metrics).
  • Hybrid PHP/K8s workflows where developers prefer PHP for business logic but need Kubernetes-native scaling (e.g., scaling pods based on Prometheus metrics or external APIs).
  • Legacy PHP monoliths being decomposed into event-driven services with dynamic scaling.
• Abstraction Level: Provides a PHP-centric DSL for KEDA CRDs (e.g., ScaledObject, TriggerAuthentication), reducing YAML boilerplate but requiring familiarity with KEDA’s underlying concepts (e.g., scalers, triggers).
• Limitations:
  • Not a full KEDA replacement: Requires Kubernetes/KEDA to be the execution environment; PHP is only for CRD definition.
  • Tight coupling to K8s: Assumes KEDA is already deployed in the cluster (adds operational overhead).
  • Limited ecosystem: No stars/community suggests unproven adoption (risk of maintenance gaps).

Integration Feasibility

• PHP Stack Compatibility:
  • Works with Symfony/Kubernetes Framework (via k8s-bundle), implying compatibility with Symfony 6.4+ or standalone PHP 8.2+ projects using these bundles.
  • Requires Kubernetes API access from PHP (e.g., via k8s-client or in-cluster config).
• KEDA Dependency:
  • Hard dependency: KEDA must be installed in the target cluster (adds complexity if not already present).
  • CRD Validation: PHP-defined CRDs must still adhere to KEDA’s schema (e.g., valid scalers, metrics).
• Tooling:
  • Likely integrates with Symfony CLI or Kubernetes Framework’s tools for CRD deployment.
  • May require custom scripts for testing/validation of PHP-generated KEDA configs.

Technical Risk

• High Risk Areas:
  • CRD Validation Gaps: PHP-defined CRDs might fail silently or with cryptic K8s errors if not validated early (e.g., missing minReplicaCount).
  • KEDA Version Skew: Bundle may not support all KEDA versions (e.g., v2.x vs. v1.x triggers).
  • State Management: Dynamic scaling logic (e.g., cooldownPeriod) is defined in PHP but executed by KEDA; misconfigurations could lead to unstable scaling.
  • Debugging Complexity: Errors may span PHP (e.g., bundle misconfiguration) and K8s (e.g., invalid CRD), requiring cross-stack debugging.
• Mitigation Strategies:
  • Pre-deployment Validation: Use kubectl apply --dry-run or KEDA’s CLI tools to validate CRDs before deployment.
  • CI/CD Integration: Add steps to test PHP-generated CRDs against a staging K8s cluster.
  • Documentation: Create runbooks for common failure modes (e.g., "PHP CRD fails to deploy: check k8s-bundle version").

Key Questions

1. Why PHP for KEDA CRDs?
   • Is the team’s primary language PHP, or is this a one-off for a specific service?
   • Could YAML/Helm/Kustomize achieve the same goal with less risk?
2. KEDA Maturity:
   • Is KEDA already deployed in the target clusters? If not, what’s the timeline for adoption?
   • Are all required KEDA scalers/triggers supported by the bundle (e.g., prometheus, cron, aws-sqs)?
3. Operational Overhead:
   • Who will maintain the PHP/KEDA integration if the bundle’s upstream stalls?
   • How will scaling policies be tested (e.g., simulating high event loads)?
4. Alternatives:
   • Would a custom Helm chart or Kustomize overlays be simpler for this use case?
   • Are there PHP-native scaling solutions (e.g., Laravel Horizon for queues) that could reduce K8s dependency?

Integration Approach

Stack Fit

• Target Environments:
  • Symfony Applications: Ideal fit if using k8s-bundle or kubernetes-framework.
  • PHP Microservices: Works for event-driven services (e.g., queue workers, API gateways) where scaling is event-triggered.
  • Hybrid Stacks: Useful if PHP services interact with K8s-native components (e.g., scaling based on Kafka lag).
• Non-Fit Scenarios:
  • Non-K8s Environments: Useless outside Kubernetes (e.g., AWS ECS, bare metal).
  • Static Workloads: Overkill for services with fixed replica counts.
  • Go/Java/K8s-Native Teams: Teams already using KEDA’s native YAML/Helm may prefer those tools.

Migration Path

1. Assessment Phase:
   • Audit existing scaling logic (e.g., manual kubectl scale, cron jobs, or PHP-based retries).
   • Identify candidate services for event-driven scaling (e.g., queue processors, async tasks).
2. Pilot Phase:
   • Single Service: Migrate one PHP service to use the bundle for KEDA CRDs.
   • Validation: Test scaling behavior (e.g., simulate 1000 messages in a queue and verify pod scaling).
3. Rollout Phase:
   • Incremental Adoption: Roll out to other services with similar scaling needs.
   • Tooling Integration: Add PHP CRD generation to CI/CD (e.g., deploy CRDs alongside PHP code).
4. Fallback Plan:
   • Maintain YAML/Helm templates for services not migrated to the bundle.

Compatibility

• PHP Dependencies:
  • Requires symfony/kubernetes-framework and k8s-bundle (check version compatibility with the bundle).
  • PHP 8.2+ recommended (for named arguments, attributes, etc.).
• Kubernetes Dependencies:
  • KEDA v2.x (or specified version in the bundle’s docs).
  • CustomResourceDefinitions for ScaledObject and TriggerAuthentication must exist.
• CI/CD:
  • Needs Kubernetes context in pipelines (e.g., kubectl access for dry-run tests).
  • May require custom tasks to validate PHP-generated CRDs.

Sequencing

1. Prerequisites:
   • Deploy KEDA to the target cluster (if not already present).
   • Set up k8s-bundle in the PHP application.
2. Bundle Integration:
   • Configure the dealroadshow/keda-bundle in config/packages/keda.yaml.
   • Define KEDA CRDs in PHP (e.g., using bundle’s DTOs or annotations).
3. Testing:
   • Unit test PHP CRD definitions (e.g., validate ScaledObject properties).
   • Integration test with a staging K8s cluster (e.g., deploy and verify scaling).
4. Deployment:
   • Deploy PHP app + KEDA CRDs to production.
   • Monitor scaling behavior (e.g., metrics, logs, pod counts).

Operational Impact

Maintenance

• Pros:
  • Single Source of Truth: KEDA scaling logic defined in PHP (co-located with business logic).
  • Version Control: CRDs are code; changes are tracked via Git.
• Cons:
  • Bundle Maintenance: Risk if the package is abandoned (0 stars, unproven).
  • PHP/K8s Skill Gap: Requires team members familiar with both PHP and KEDA concepts.
  • Dependency Bloat: Adds k8s-bundle and KEDA as operational dependencies.
• Mitigation:
  • Fork the bundle if upstream stalls.
  • Document PHP-to-KEDA mapping for onboarding.

Support

• Debugging Challenges:
  • Errors may originate in PHP (e.g., invalid CRD DTO) or K8s (e.g., CRD validation).
  • KEDA logs are separate from PHP logs (requires cross-referencing).
• Support Paths:
  • PHP Layer: Use Symfony’s error handling for CRD generation issues.
  • K8s Layer: Use kubectl describe scaledobject and KEDA’s CLI tools.
• SLA Impact:
  • Adds latency to scaling-related incidents (e.g., diagnosing why a ScaledObject isn’t scaling).

Scaling

• Performance:
  • No Impact on PHP Runtime: Scaling logic is offloaded to KEDA.
  • CRD Generation Overhead: Minimal (one-time cost per deployment).
• Scaling Limits:
  • Bound by KEDA’s capabilities (e.g., max replicas, cooldown