ROSA vs Yalla
A comparison between Red Hat OpenShift Service on AWS (ROSA) and Yalla, bp's Internal Developer Platform, to help teams evaluate which platform best fits their needs.
Summary Comparison
| Dimension | ROSA | Yalla |
|---|---|---|
| Platform type | PaaS (Red Hat OpenShift on AWS) | IDP (Internal Developer Platform on AWS EKS) |
| Cluster management | ROSA HCP (Hosted Control Plane, Red Hat managed) | EKS (managed by Yalla automation) |
| Control plane | Red Hat managed via AWS PrivateLink | AWS managed (EKS) |
| Tenancy | Multi-tenant namespaces or dedicated tenant | Multi-tenant shared cluster or federated (BYO AWS account) |
| Onboarding | Accelerate form → NLS repo + AD groups auto-created | Yalla CLI bootstrap → platform.yaml PR to Yalla repo |
| Config-as-code | NLS Git repo synced via GitOps | Yalla Git repo (platform.yaml, service.yaml) + ArgoCD |
| Deployment | GitOps via ArgoCD | Automated promotion flow via Yalla deployments + ArgoCD |
| Access control | Namespace RBAC, AD groups, elevate job for prod edit | platform.yaml access block, AD groups, PR-based approval |
| Infrastructure provisioning | PaaS team managed (VPC, IAM, SGs, DNS) | Self-service via Crossplane compositions (S3, DynamoDB, etc.) |
| Observability | Grafana (team-managed dashboards) | Grafana (auto-provisioned per platform) |
| Secrets | OpenShift Secrets | AWS Secrets Manager via Yalla CLI |
| DNS & TLS | PaaS team managed | Automatic provisioning by Yalla |
| CI/CD | Team-owned pipelines | ADO pipelines + Yalla deployment service |
| Cloud provider | AWS only | AWS + Azure support |
| DR / HA | App team managed, PaaS team assists | Multi-AZ, automated by platform |
Platform Architecture
ROSA uses Red Hat OpenShift Service on AWS with a Hosted Control Plane (HCP) model. The OpenShift control plane runs in a Red Hat-managed AWS account and connects to your worker nodes via AWS PrivateLink. Red Hat manages the control plane lifecycle including upgrades, patching, and availability. Teams interact with standard OpenShift APIs and tooling.
Yalla is built on Amazon EKS, with cluster provisioning and lifecycle management handled by Yalla's automation layer. Infrastructure beyond the cluster (S3 buckets, DynamoDB tables, ACM certificates, etc.) is provisioned declaratively using Crossplane compositions. The entire platform configuration lives in Git, making it fully auditable and reproducible.
Onboarding Process
ROSA: Teams onboard by submitting a request through the Accelerate portal. This triggers the creation of a dedicated NLS (Namespace Lifecycle Service) Git repository and the associated AD groups for RBAC. The PaaS team provisions the namespace and supporting resources.
Yalla: Teams onboard using the Yalla CLI, which bootstraps a platform.yaml configuration and raises a PR against the Yalla GitOps repository. Once merged, ArgoCD reconciles the desired state and provisions the platform resources automatically. Self-service is a core principle — teams can onboard without raising tickets.
Tenancy Models
ROSA: Supports multi-tenant namespaces within a shared cluster or dedicated tenants for teams requiring stronger isolation. Namespace-level RBAC enforced through AD groups controls who can access what.
Yalla: Offers two tenancy models. Multi-tenant places your workloads on a shared EKS cluster managed by the Yalla platform team. Federated gives you a dedicated AWS account with its own EKS cluster, managed by Yalla automation but isolated at the account boundary. Both models are configured through platform.yaml.
Deployment & Promotion
ROSA: Deployments follow a GitOps model using ArgoCD. Teams manage their own deployment pipelines and promotion workflows. Environment promotion is typically handled through pipeline stages or manual approvals.
Yalla: Deployments are fully automated through the Yalla deployment service. When code merges to main, the CI pipeline builds the image and calls yalla deployment create. The deployment service orchestrates promotion through environments (e.g. int → prod) automatically, gated by ArgoCD health checks. No manual intervention is required for standard promotions.
Access & Security
ROSA: Access is controlled through namespace RBAC bound to AD groups. Production access uses an "elevate job" pattern where developers temporarily gain elevated permissions for debugging or incident response. The PaaS team manages cluster-level security policies.
Yalla: Access is defined in the platform.yaml access block, mapping AD groups to roles. Production changes go through PR-based approval workflows in the Yalla GitOps repository. IAM roles and policies are provisioned automatically by Crossplane based on the platform configuration.
Infrastructure Management
ROSA: Infrastructure such as VPCs, IAM roles, security groups, and DNS records is provisioned and managed by the PaaS team. Teams raise requests for new resources, and the PaaS team fulfils them.
Yalla: Infrastructure is self-service. Teams declare the resources they need (S3 buckets, DynamoDB tables, secrets, ACM certificates, etc.) in their service.yaml and Crossplane compositions provision them automatically. The full catalogue of available infrastructure is documented in the Infrastructure Docs.
Observability
ROSA: Grafana dashboards are available but typically set up and managed by individual teams. The PaaS team provides the base Grafana instance and data sources.
Yalla: Grafana is auto-provisioned per platform with pre-configured dashboards, data sources (Loki for logs, Mimir for metrics, Tempo for traces), and alerting. Teams get observability out of the box as part of the platform onboarding.