I'm a member of a platform team that managed to change 3 service mesh solutions during the past 7 years. We did it seamlessly for other 1,500 engineers that work at Avito; our solution manages over 3,000 microservices and > 3 mln RPS. I will share difficulties and lifehacks how we achieved that.
Over the past seven years, our team at Avito has operated two self-implemented service meshes before completing a two-year migration to Istio. Today, our service mesh supports over 3,000 services across dozens of Kubernetes clusters, processing millions of requests per second. This solution is maintained by a single team, while more than 1,500 developers seamlessly work without needing to understand the internals of the service mesh or write Kubernetes manifests. This talk will delve into: - Our two-year journey migrating from one service mesh to another. - Challenges in organizing ingress communication rules. - Accelerating the adoption of Mutual TLS (mTLS) and service authorization. - Testing changes within a service mesh. - Should developers be aware of the service mesh? How we’ve made it transparent to them. - The new possibilities and advantages unlocked by adopting a service mesh. - What can you expect from a service mesh at scale, and how can you choose the right one?
Igor works at Avito, the largest classified advertisement website (MAU over 50 million).
A Platform Engineer who is strongly interested in Kubernetes, observability tools, service meshes, and other modern cloud-native approaches.
Before working as a software engineer, Igor studied distributed systems and participated in ACM competitions.
