Once redSling generates a Docker application image, it’s not just a container for local deployment — it is cloud-native by design, meaning it runs seamlessly on Kubernetes. You can deploy these images to any managed K8s service like:
• Google Kubernetes Engine (GKE)
• Amazon EKS
• Azure AKS
• Or even on-prem K8s clusters
This enables full orchestration, service discovery, load balancing, and rollout strategies.
Autoscaling, Horizontal & Vertical Scaling
Scaling is handled entirely by the infrastructure where the Docker image is deployed:
• Horizontal Scaling: Kubernetes HPA (Horizontal Pod Autoscaler) can spin up more pods based on CPU/memory or custom metrics.
• Vertical Scaling: Resource requests/limits can be adjusted per container spec.
The architecture is container-native, so scaling becomes a function of where and how you deploy — not a limitation of the app itself.
Log Management Across Multiple Instances
Logs can be routed to centralised logging tools as part of your deployment stack. Depending on where you host:
• In GKE, you can use Cloud Logging.
• In AWS/Azure, similarly, Fluentd, ELK, or Datadog integrations work seamlessly.
• redSling apps write structured logs and you can implement log-shipping friendly for observability stacks.
If you’re using Kubernetes, these logs can also be aggregated with tools like Prometheus + Grafana, Elastic Stack, or Loki.
Database Architecture: One or Shared Instances
redSling supports multiple tenancy patterns:
• Single DB per app (for stricter isolation or regulated industries)
• Shared DB with tenant separation at schema or row level
• External DB connectivity — your app can connect to a managed database (Cloud SQL, Cloud Spanner, PostgreSQL, etc.)
Database scaling depends on your deployment preference. For cloud-managed databases, scaling is automatic.
.
