The client-server protocol was simply JSON. XMPP was not involved. (Well, we translated protobuf messages to JSON, so it was ugly JSON, but still JSON).
we translated protobuf messages to JSON
aside, any opinions on others choosing that as a standard way of communicating between internal services on disparate runtimes? (golang<->python, for example)
--
I think they meant the scale of Google (total) compared to the scale of just messaging.
i.e: If you could spend a year's worth of working cutting the costs of <sevice X> by 30%, that would be fairly meaningless if it was .000001% of the total cost of operation.
I don't know what Google's operating expenses are[1], but I'll use the public income numbers as a proxy, and you can adjust from there.
If you look at Google's first quarter 2013 numbers, they pulled in 13.97 billion in revenue, and I'll subtract the 2.96 billion in traffic acquisition costs to come up with 11.01 billion. We'll multiply by four[2] to get a rough estimate of yearly income: 44.04 billion.
If we assume that messaging is millionth of a percent = one hundred millionth[3] of Google's expenses, then the total cost to google is $440 per year, so saving 30% just doesn't make sense.
If, however, it's one hundred thousandth of Google's expenses (still a ridiculously small amount), then you're talking about $440k of yearly expenses, and you now need to compare a year of salary to 30%, or $146k.
At this point, depending on the availability of engineers (whether or not you have to factor in hiring costs) it starts to make a lot more sense.
Cheers, Doug
#1 and I probably wouldn't be able to divulge them if I did. :-)
#2 Each quarter is different, but x4 is a good rough estimate.
#3 Your numbers.
I'm not offering an opinion for or against the decision to drop XMPP, but I wanted to offer some corrections to what is being said.
I think you've misunderstood how scale works. At scale, problems do not shrink, they grow.
I do not work on anything even closely related to Hangouts, but I used to run an ejabberd server myself, and I've worked with SIP a bit.
XML does have problems, both with bandwidth, (even compressed), high CPU utilization, parsing code is more complex (which leads to more security issues). XMPP also has issues, and I'm not just talking about how hard it is to get multiple Audio/Video clients to communicate[1]. (e.g. kernel resources, the incredible number of failure states, etc.)
Cheers, Doug
#1 At least early versions of iChat used XMPP with SIP. For those who don't know SIP, it stands for Session Initiation Protocol, which means that it doesn't transfer the audio/video, it's just a language for making connections. You have to negotiate a transport layer (which was often but not always RTP or SRTP). You have to exchange connection ports via SDP. If you're lucky and manage to get by all firewalls at this point, you now have to hope you're able to use compatible codecs. Interoperability was a nightmare.