> You have to understand that the technology underlying Skype at the time was very brittle and poorly designed. > When Microsoft acquired it Skype was routing its traffic over port 80 for example.

__I have to understand__ ?

Who is saying this? do you have any credentials / knowledge of Skype technology? My understanding is that you only report indirect discussion from "your friends who worked on it"?

Having been there, I would say quite the opposite.

Skype had pretty intricate means to bypass NAT to NAT clients. I would even go as far as saying that Skype P2P connectivity tricks were top notch, considering the incredible amount of different network setups that clients could face. Even in the weirdest conditions, you could trust your Skype client to somehow find a way to get the call through. This was through an immense collection of in-house-trial-and-error-STUN-hole-punching like techniques.

Now I can understand that for people outside of the peer to peer connectivity world, these techniques could seem completely foreign and brittle, but it's not. It's the world of internet clients we live in. It's not related to Skype, it's the route all peer to peer clients have to deal with. If you don't want that, don't go peer to peer.

> Google almost bought Skype before Microsoft did and backed out after they got a look at the code.

Where did you get that information? I had never heard of that interpretation of the story before.

My view on this is that Google considered buying Skype, but backed up because they wanted to have a cloud based service, instead of a p2p one. Microsoft was in the same state of mind, but decided to go along and migrate Skype to be a cloud service, which they did.

Now if you really want to discuss technical details and the state of Microsoft/Azure at that time, I would be pleased to do so.

Microsoft started the migration of Skype to the cloud at a time Azure was just a big beta test. Nothing was working properly, the tools were sub-par or in-existent. Nothing was reliable. You would deploy Azure services through remote desktop automated by PowerShell scripts. Managing databases was done through in-browser silverlight clients - yes, that was already EOL at the time, but that was the only way to perform DB queries with a UI.

When complaining about the deplorable half-baked status of the tooling and cloud services that we were required to use to migrate Skype, the only response was "Yeahhh, Eat your own dog food".

Thanks but no thanks.

All the great Skype engineers left in the two years after the start of the migration to Azure - mostly to join Twilio.

Here is an article from Wired with quotes from the Google Product Manager that did the due diligence when they considered buying Skype:

https://www.google.com/amp/s/www.wired.com/2011/05/why-googl...

Key points:

He did not think Skypes p2p communication was a good fit for Google, going so far as to say it ate up bandwidth and was like an old technology.

The PM's remarks could be summarized as saying the basic p2p communication architecture was overly and only used in order to avoid a cloud/server based architecture.

Basically, the PM thought Skypes architecture and code base couldn't effectively scale or meet real world business requirements that people would pay for.

It could be true (and frankly I certainly can believe it!) but an article from someone who didn't buy a company could also be a post hoc justification for why they didn't get the deal.

Like VCs who try to invest in a company but lose the deal (or never get to see it at all): "Oh FooBbarApp? Yeah, we passed"

Isn't using port 80 a trick to avoid being blocked by firewalls?

People would say that but most firewalls block _incoming_ port 80 connections so that logic never held much weight.

That isn't really relevant to the problem they were working around. The problem is that many firewalls block outbound ports other than port 80, 443, and some other very common ports.

Put another way, if both sides block 80 incoming, their only hope is fancy NAT-punching techniques.

But those NAT-punching tricks are useless if they are using a port that is completely blocked on the outbound side.

Many networks like in hotels and airplanes only allow out on port 80 or 443.

Port 80 isn't necessarily a problem? Sounds like a great way to get around restrictive network devices like firewalls. Encryption is a thing right?