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

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

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.

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.