Andrey Rybka

Andrey Rybka’s work at Bloomberg connects compute architecture to the demands of delivering financial information: fast deployment, reliable services, and infrastructure that engineers can use without configuring every machine themselves. He headed the company’s Compute Architecture Team in the Office of the CTO in 2019. The October 2026 AI Engineer New York program listed his role as Head of Architecture & Emerging Technologies in the same office.

From virtual machines to a self-service platform

Bloomberg’s move toward cloud-native infrastructure addressed a practical limitation of its virtual-machine platform: application teams needed to scale faster and deploy consistently across the company’s network. Engineers began evaluating orchestration frameworks in 2016, and Bloomberg put its first production applications on Kubernetes in early 2017. Rybka described the goal as making the private cloud as easy to use as a public cloud, with reusable infrastructure components and automated deployment. The 2019 account of Bloomberg’s Kubernetes adoption also records his insistence on gradual migration, with failure handling and resilience built into applications.

Autoscaling made the benefit concrete. Rybka used the example of a service that needs more CPU and memory when financial markets open: a team could specify a minimum of two instances and allow it to grow to twelve as demand increased, without requesting more servers or scheduling the change manually. Developers could compose infrastructure from existing building blocks, while Kubernetes handled more of the scaling and recovery work.

By November 2020, Rybka described his team’s responsibilities as researching and implementing compute technologies, developing Bloomberg’s compute strategy, and helping guide internal infrastructure offerings. That remit included storage, middleware, and application technologies alongside compute. He connected the work to faster product delivery, higher availability, and better use of Bloomberg’s data-center hardware.

Bloomberg’s platform had developed from OpenStack-based virtualization into a Kubernetes application platform, with a data-science platform supporting GPU-backed training and inference. Supporting services mattered too: Consul provided service discovery, while managed database offerings gave developers options for workloads that needed persistent state. The aim was developer self-service—letting engineers obtain the services they needed and deploy applications without taking responsibility for every operating-system choice, proxy setting, or machine.

Portability, open source, and the work after deployment

Rybka’s 2020 discussion of Bloomberg’s infrastructure strategy explains several principles behind that platform:

• Use consistent packaging across environments. Containers gave teams a common way to package applications for private data centers, public clouds, and edge locations closer to customers. Kubernetes added scaling and workload recovery. For Rybka, portability served a developer-facing goal: making deployment faster and more reliable across those destinations.

• Build on open source and invest back into it. He advocated evaluating existing projects before building internal alternatives, then supporting the communities behind them through engineering contributions or financial investment. Bloomberg’s internal services drew on projects such as Solr for search, Redis for caching, RabbitMQ for queuing, and Kafka for event streaming. He also described partnering with companies that understood a project’s internals to help resolve early operational problems and improve its maturity.

• Treat ongoing operation as part of the platform. In 2020, Rybka identified monitoring, alerting, troubleshooting, and security across multiple clouds as continuing challenges. He also wanted stronger open-source storage support for stateful Kubernetes workloads: capabilities available within a public-cloud provider were less useful to Bloomberg if they could not also work in its private environments. His concern extended beyond successfully launching an application to keeping it observable, recoverable, and reliable afterward.