Presentation: Skype's Journey From P2P: It's Not Just About the Services
Share this on:
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.
What is the work that you do today at Skype?
I’m managing teams that handle the people infrastructure, contacts, identity, experimentation, and push notifications for Skype and Teams.
What's the focus of your talk?
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.
What do you feel is the most important trend in software today?
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.
Similar Talks
Tracks
-
Microservices: Patterns & Practices
Evolving, observing, persisting, and building modern microservices
-
Developer Experience: Level up Your Engineering Effectiveness
Improving the end to end developer experience - design, dev, test, deploy, operate/understand. Tools, techniques, and trends.
-
Modern Java Reloaded
Modern, Modular, fast, and effective Java. Pushing the boundaries of JDK 9 and beyond.
-
Modern User Interfaces: Screens and Beyond
Zero UI, voice, mobile: Interfaces pushing the boundary of what we consider to be the interface
-
Practical Machine Learning
Applied machine learning lessons for SWEs, including tech around TensorFlow, TPUs, Keras, Caffe, & more
-
Ethics in Computing
Inclusive technology, Ethics and politics of technology. Considering bias. Societal relationship with tech. Also the privacy problems we have today (e.g., GDPR, right to be forgotten)
-
Architectures You've Always Wondered About
Next-gen architectures from the most admired companies in software, such as Netflix, Google, Facebook, Twitter, Goldman Sachs
-
Modern CS in the Real World
Thoughts pushing software forward, including consensus, CRDT's, formal methods, & probalistic programming
-
Container and Orchestration Platforms in Action
Runtime containers, libraries, and services that power microservices
-
Finding the Serverless Sweetspot
Stories about the pains and gains from migrating to Serverless.
-
Chaos, Complexity, and Resilience
Lessons building resilient systems and the war stories that drove their adoption
-
Real World Security
Practical lessons building, maintaining, and deploying secure systems
-
Blockchain Enabled
Exploring Smart contracts, oracles, sidechains, and what can/cannot be done with blockchain today.
-
21st Century Languages
Lessons learned from languages like Rust, Go-lang, Swift, Kotlin, and more.
-
Empowered Teams
Safely running inclusive teams that are autonomous and self-correcting