Microservices
Moving past decomposing the monolith, companies are discovering there are many changes in running Microservices. Everything from observability to team structure is changed in the long term when it comes to successfully running microservices. Operationalizing Microservices is all about running and maintaining services.
Position on the Adoption Curve
Presentations about Microservices
Connecting, Managing, Observing, and Securing Services
Service Ownership @Slack
Netflix Play API - An Evolutionary Architecture
Airbnb's Great Migration: From Monolith to Service-Oriented
How to Make Linux Microservice-Aware With Cilium and eBPF
What We Got Wrong: Lessons From the Birth of Microservices
Redis for Microservices Using Kubernetes
Autonomous Microservices
3 Common Pitfalls in Microservice Integration
Architecture Without an End State
Getting Started With Kubernetes and Container Orchestration (Friday Section)
Microservices Full-Day Build Spring
Microservices Full-Day Build Spring
Microservices Security (Afternoon Section)
Microservices Security (Afternoon Section)
Build Event-Driven Microservices with Apache Kafka (Morning Section)
Building and Architecting Web APIs with ASP.NET Core 2.1
Microservices Security (Morning Section)
Microservices Security (Morning Section)
Build Event-Driven Microservices with Apache Kafka (Afternoon Section)
Getting Started With Kubernetes and Container Orchestration (Thursday Section)
Interviews
Netflix Play API - An Evolutionary Architecture
QCon: What is the focus of your work today?
Suudhan: I work on the Playback API team whose identity is to deliver Playback Functionality 24/7. I, along with a team of stunning colleagues, own and operate the critical Play API service which orchestrates playback functions like deciding the best playback experience, authorize every playback and collect playback data for business intelligence. For the past 2 years, i lead the initiative to re-architect this service to significantly improve our scalability, availability and developer velocity.
QCon: What’s the motivation for this talk?
Suudhan: Our API service have gone through 3 architectures. With Netflix scale, we often hit limitations of our architecture every 3 or so years. In this third iteration, we have architected a solution to optimize for evolvability. We fully expect things to change in 3-5 years time and we want an architecture in which each aspect of the architecture can be replaced with minimal overhead. My motivation for the talk is to share our learnings with this architecture and have an exchange of ideas with the qCon audience. I am particularly interested in hearing opinions about aspects which we might have overlooked or how some elements of our architecture can be applied to different domains.