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.