Extreme DevOps Automation Report from Revolut on QCon 2025 (Category PlatformEngineering)
Interesting. report c QCon 2025 From Sérgio Amorim about their DevOps team. The bottom line is that the guys at Revolut have a practical approach to their development platform -- they're tight. sitting on Google CloudAt the same time adding custom automation from above. With this approach, they are able to 15 Engineers can maintain the scale of the order 1.3k engineers, 1.2k microservices and 1.1k databases (What the guys on the platform team support themselves). As a result, it turns out a little less. 1 service 1 bd per engineer:)
Three pillars are used to manage all this. The directory of services in the form of an internal Tower solution is the main source of truth Patterns and standards for unification of approaches Automation of GitOps with internal Rhea system
Now let's take a closer look under the hood. 1. Tower (catalogue) There is a minimum set of parameters for the service: stack (Java/Python/Scala/ML), owner, links with database / services, environment, criticality (tier)SLO, cost, quality of metadata, etc. In the end, this is not a “static CMDB”, but a portal from where management begins and to which feedback returns. (quality, uptime, cost). Fewer fields – higher data occupancy and accuracy → the more reliable the automation. 2. Patterns as "narrowing freedom" for speed and conformity A small number of supported stacks and deployment patterns. This improves repeatability, simplifies ownership, and brings value to compliance – standardization automatically implements corporate and regulatory rules. 3. Automation as Control Plane Rhea 'transpiles' data from Tower to commits (Implementing the GitOps approach): Generates TeamCity Pipelines and Deploy Rights for the Right Teams (~10k of controlled piplins) Create policies for access to secrets (Vault) exactly according to the registered links serviceнымbase (~37K Politicians of Secrets) Creating resources in Kubernetes/Cloud
- forms template allerts / dashboards / rules (~20k standard allerts and ~3k castom alerts) All this without the manual actions of the teams.
For services, the issue of observability is also important - everything begins with SLOs, which are also configured in Tower, then automation generates standardized allerts for services and databases, and the internal dispatcher sends uniform messages to Slack to owners' teams. Too "noisy" systems are recognized as technical debt: when accumulating bug tickets, the stopper of changes is switched on until stability is improved. (Error budget implementation). By the way, services have everything. 4 standard levels of availability (99.99/99.9/99.8/99.5)
Separately, the author of the report told about the management of databases, or rather Postgres, for which managed solutions from Google are not used, and the DevOps team itself operates them to roll calmly major updates of the DBMS + play with replicas as you want.
If you analyze the device of the platform, it can be noted that this works due to a number of factors. Minimum platform on top of the cloud - you can use the cloud infrastructure of the provider, and on top of it do only the necessary things. Governance is sewn right into the happy path platform - important rules (SLOs, allerts, secrets, rights) They are used automatically because the only convenient way to start the system is through the catalog and patterns. There is no need to “do it with your hands” and often it is impossible.
- System catalog + GitOps. Tower becomes the company’s “API” for the entire engineering landscape. One set of artifacts generates piplins, policies, resources, and monitoring. This reduces the discrepancy between reality and declarations. Standards at scale speed up, not slow down. Stack restriction + deploy templates remove variability, speeding up onboarding and reducing operational risk. SLO/allert as a product management mechanism. The unified sound meter and error-budget freeze force teams to maintain stability, rather than being “squeezed” by releases at any cost. The focus of the DevOps platform is not hand support, but tool engineering and product work on DX.
#Software #Engineering #Management #Architecture #Processes