Building distributed systems with containers

Five questions for Brendan Burns: How containers and cluster management have changed systems development, and common patterns for building distributed systems.

By Mary Treseler and Brendan Burns
August 24, 2017
Cluster Cluster (source: geralt via Pixabay)

I recently asked Brendan Burns, director of engineering at Microsoft Azure and co-founder of the Kubernetes open source project, to discuss distributed systems patterns and obstacles. Brendan is the author of Designing Distributed Systems and co-author of Kubernetes: Up and Running. He’s also speaking at the O’Reilly Velocity Conference, taking place Oct. 1-4 in New York.

1. What prompted you to develop Kubernetes?

I had personally experienced the power and flexibility of containers and container orchestration as a distributed systems developer. As I saw containers becoming increasingly mainstream, I wanted to ensure that all developers had access to a sophisticated production-grade container orchestrator. That meant it had to be open source, and that led to the development of Kubernetes with Joe Beda and Craig McLuckie.

Learn faster. Dig deeper. See farther.

Join the O'Reilly online learning platform. Get a free trial today and find answers on the fly, or master something new and useful.

Learn more

2. How have containers and cluster management changed how systems are developed?

The world was already trending toward immutable infrastructure, but containers radically accelerated that transition. I think, additionally, they’ve been a catalyst for a transformation toward “cloud-native” development from more traditional machine-centric approaches. Perhaps more importantly I think they’ve made people take a step back and think about their infrastructure differently, to separate machines from management and management from application orchestration. I don’t think any of these things required containers to happen, but often technology serves as a catalyst for the development of new ideas. It happened with object-oriented programming, and it’s happening with containers and orchestration.

3. What are the toughest obstacles developers face in moving to building distributed systems with containers?

Well, beyond simply building a distributed system? I think that’s a pretty big challenge in general, but it doesn’t really have anything to do with containers. For containers, I think the big challenges are learning new tools, forgetting about machines, and generally forgetting about making little imperative changes to your application in favor of rolling things out via new container images, new configurations, and continuous integration / continuous deployment (CI/CD).

4. What are some of the common patterns for building distributed systems?

I think the most common patterns are still frontend/backend or frontend/middleware/backend. What is changing is that people are learning to de-couple these pieces with service discovery and load balancing. Additionally, one of the most common patterns is sharding, where different requests from different users or different data are load-balanced to specific machines that contain that data. This is especially common with caches or other storage layers. I think people are starting to weave newer technologies like event-driven functions to handle webhooks from periodic or asynchronous events.

5. What other parts of the program for Velocity NY are of interest to you?

The most exciting part of any conference for me is meeting and learning from customers and users. I can’t build useful products if I don’t know how people are using the things I have built, what problems they are running into, and where the pain points are in their current workflows.

Post topics: Operations