Ethos
The internal cloud-native platform powering deployments across Adobe's Creative, Document, and Experience Clouds
The Problem
Before Ethos, hundreds of Adobe development teams had sprawled to the cloud independently — each with their own infrastructure designs, security approaches, and CI/CD pipelines. The result was predictable: manual one-off provisioning, inconsistent compliance controls, rising costs from undisciplined deployment practices, and the same foundational problems solved repeatedly across teams. Making any org-wide change was a coordination nightmare.
What We Built
Ethos is Adobe’s internal cloud-native platform for deploying and operating containerized applications at scale. Most microservices across Adobe’s Creative, Document, and Experience Clouds — including Photoshop, PDF, and Adobe Experience Platform — run on it.
The platform offers two paths: a “Do It Yourself” PaaS model for teams that want direct control, and an opinionated “paved path” CaaS model for teams that want automation and guardrails. Either way, Ethos owns the hard parts so product teams don’t have to.
Core capabilities:
- Simple provisioning — A config file and developer portal UI to onboard a new service in minutes
- Guard-railed CI/CD — Automated pipelines with image hardening, security scanning, and safe rollout to multiple Kubernetes clusters
- Multi-cloud — Deploys across Azure, AWS, and Adobe-owned data centers with unified API management and dynamic routing
- Built-in security — Hardened containers, runtime scanning, RBAC, and compliance controls (HIPAA, PCI, CCF) baked into the pipeline — not bolted on after
- Observability — Common logging, monitoring, and tracing across services, with self-service dashboards and automated diagnostics
On the paved path model
The goal was never to eliminate choice. Teams that needed flexibility could use the DIY path. But the paved path had to be so clearly better — more secure, more reliable, easier — that most teams chose it without being forced to.
Why It Mattered
The leverage from a shared platform compounds. Every security control we baked into the pipeline was one fewer thing 400+ teams had to build themselves. Every standardized deployment process made org-wide changes executable in days instead of months.
The hardest challenges weren’t technical — they were adoption. Getting hundreds of teams to trust a shared platform required serious investment in documentation, self-service tooling, and listening hard to developer feedback. The Ethos team used the platform itself to find friction and measure deployment times, which kept us honest.
What I Learned
Platform products are trust products. Developers only give up their bespoke setups when the platform is clearly better than what they built themselves. That bar is higher than most platform teams expect. Getting there requires tight feedback loops, high-quality documentation, and the discipline to not mandate adoption before the product deserves it.