You are viewing content from a past/completed QCon

Presentation: Skype's Journey From P2P: It's Not Just About the Services

Track: Architectures You've Always Wondered About

Location: Broadway Ballroom North, 6th fl.

Duration: 4:10pm - 5:00pm

Day of week: Wednesday

Level: Intermediate

Persona: Architect

Share this on:

This presentation is now available to view on InfoQ.com

Watch video

Abstract

Skype is known for P2P but today runs its third calling architecture, fourth contacts service, and is about to deploy its fourth chat architecture.

Client changes have been as dramatic as service changes. Bruce addresses why Skype moved away from P2P and the strategies used to make the migrations successful.  Key to safe migrations was robust online experimentation, used to evaluate the impact of both client and service migrations. 

The initial P2P architecture allowed Skype to launch in 2003 and become the de facto standard for Internet voice and video calling.  Over time, however, servers became cheaper, clients began running on phones, and Skype began a gradual evolution from P2P to service-based architecture. But the story isn't as simple as a transition from P2P to services. The P2P architecture always had crucial services, but those services weren't designed for the demands of supporting lightweight clients.   

Experimentation to support the transition from P2P to service-based architecture required addressing the nature of Skype’s client population. With thousands of combinations of client releases and hardware platforms in use, robust scorecards and support for the entire client lifecycle is essential. Building clients based on configuration by focusing on “what” instead of “why” allows clients to continue to work as the overall service evolves to support scenarios unanticipated when the client was designed.

Bruce will discuss the evolution of Skype's architecture and tradeoffs in design made along the way. He will discuss lessons learned and the improvements that are still in process as Skype continues to evolve.

Question: 

What is the work that you do today at Skype?

Answer: 

I’m managing teams that handle the people infrastructure, contacts, identity, experimentation, and push notifications for Skype and Teams.

Question: 

What's the focus of your talk?

Answer: 

The focus of my talk is really tracing the evolution of both Skype's software and organizational architecture.

Skype was originally founded by an engineering team based in Tallinn, Estonia. Over time, we built engineering offices in Stockholm, Prague, London, and Palo Alto. Then, after being acquired by Microsoft, in Redmond. Today, we have a distributed organization and that organization has transitioned Skype from where it started out as a purely peer-to-peer product to now being server based.

We learned a lot of lessons working with these different architectures. It’s not just technical lessons about how you build clients (what the pros and cons of peer to peer versus service based are) but also organizational. How you track this sort of evolution. Some of the talk is focused on how you manage a higher degree of evolution with a diverse team. I’ll talk about where it's benefited us and where I really wish we had done things differently.

In terms of the actual software, there are some classic lessons in the talk. For example, Skype was “cool” to much of the engineering team because it was peer to peer. The reality is to our user base, Skype was “cool” because grandma could call her grandkids. The peer-to-peer technology gave us certain advantages that let us really take off in those early days when servers were expensive. So we made certain engineering decisions based on peer to peer, but the difference between “where has the client experience benefited from that?” versus “what is a purely technical geek desire” weren't as visible to the engineering team. I’ll spend a bit of time talking about features that were easier in peer to peer and which ones made more sense in a server-based approach.

What does the current architecture of Skype look like today?

The current architecture of Skype is primarily server-based. Obviously, we do peer-to-peer media, as it's usually best for audio & video to go directly between the two callers. Of course, if that isn’t supported, we can also relay through servers. But call signaling and chat messages are relayed through servers. Offline messaging and other features are only possible through services.  But our architecture is continuously evolving.

What do you think the big takeaways for your talk is?

As Skype has transitioned from P2P to server-based, it’s interesting to look back now at the pros and cons of both approaches. From an architectural and implementation perspective, they enable completely different things. For example with the peer-to-peer system (in terms of CAP model), we actually run CP services. The clients were self-sustaining. It was the backend where consistency was most important. The clients were fine if the backend wasn't available. Whereas to support lightweight clients, phones, web browsers and things you need a completely different paradigm and you need AP.

Getting from P2P to server-based required lots of migration, both on client- and server-side.  In particular, because many of our clients have very long life cycles, we needed to adopt strategies that let us evolve the new services while preserving the old ones, and in some cases, we built dual-head clients and in other cases, we handled the migration server-side.

We also built an experimentation platform to support ongoing evolution, and I’ll describe how that system works and some of the features we built in to support client lifecycle.

Question: 

What do you feel is the most important trend in software today?

Answer: 

Anything that moves us closer to true Continuous Delivery is a win for me. That’s where I see the biggest problems with our software development. I mean we have lots of engineers working on new technologies. Being Microsoft, we have .NET, and we can evolve that as fast as we want. But for me, the consistent conversations I have with the teams are when they run into problems, they're not deploying as fast as they can. So it’s very much ‘motherhood and apple pie’ but I'm actually a big believer that anything that lets you ship faster and measure what you built is a huge win for agility and productivity.

Speaker: Bruce Lowekamp

Principal Architect for Skype's Cloud Infrastructure Portfolio @Microsoft

Bruce manages teams responsible for People Infrastructure, Transport, and Experimentation supporting Skype and Teams.  He enjoys the challenge of building highly available, low-latency global systems using commodity cloud services and has even more fun understanding failures.  Prior to Skype, he was cofounder of communications startup SIPeerior Technologies and did research in network performance measurement and adaptive applications.  Bruce is co-author of several IETF RFCs in the area of P2PSIP and NAT traversal.  When not on calls with or flying to various office locations, he gets on a bicycle to clear his thoughts. 

 

Find Bruce Lowekamp at

Proposed Tracks

  • Trouble-Shooting in Production

  • Disrupting Technology on Wall Street

  • Resilience vs Failure in Architecture

  • The Weeds of Distributed File Systems

  • Organizational Agility

  • Product & Customer Focused Teams

  • Just Culture (Blameless Culture)

  • Modern CS in the Real World

  • Architectures You’ve Always Wondered About

  • Machine Learning and AI in the New Decade

  • Evolving Java - Including K8s/Containers, Kotlin and Impact on AOT

  • Ethical Considerations in Software

  • Microservices and Scalability

  • Container Slinging

  • Native Compilation Is Back (A Look at Non-Vm Compilation Targets)