Answer: because sending short messages from A to B is basically a solved problem. There is even a programming language (Erlang) that was made with this application in mind. The prototypical "Hello World" example for Erlang is a messaging application.
I really dislike the arrogant attitude behind these types of comments. Have you worked at WhatsApp? Do you have any idea what they spend their days doing, what their systems look like, what their requirements are like?
WhatsApp have close to a billion users, 50 engineers and they manage to produce a near flawless experience. This is not trivial, no matter how many armchair critics claim otherwise. It used to be the case that people dismissed FB as just another CRUD app ("not even written in RoR, but in PHP, yuck" ~ 2005-2010), but given the tools they have been pushing the last few years people seem to have stopped dismissing them as casually. Perhaps in a few years people will stop dismissing WhatsApp as casually as well.
Obviously, creating Whatsapp is nothing near a weekend project. But I think there founders should be commended especially for avoiding some classic mistakes: the NIH syndrome and going on a hiring spree once the investments started rolling in. Their managerial skills are at least as good as their engineering skills.
Not so long ago, maintaining hardware that could support 900M user would have required an IBM scale company. A single developer today can develop, deploy and maintain a medium scale ecommerce site using infrastructure like AWS, a myriad of OpenSource solutions, plenty of services to handle payments, ... yet he will probably be using the same language than 15 years ago when 20 times more developers were needed to achieve the same result.
* SoftLayer is their cloud provider, bare metal machines, fairly isolated within the network, dual datacenter configuration
Softlayer is an IBM Company, so ultimately it DOES require an IBM scale company to run this ( at some point in the chain).
I'm building a product that only a few years ago would have required a VERY significant investment, but now is basically stacking and connecting lego blocks of services :) - sales-as-a-service isn't mature yet, but if we had it, it would even sell itself :) .
Ok, it's probably a pain if one of the black boxes fails, and I do know enough about the underlying architecture behind the services I'm using - I could probably replicate (badly) most if not all of them given time and money, but why would I?
I don't think this is a possibility whose importance can be understated. In most of my apps running on IaaS/PaaS offerings like heroku, key pieces of the infrastructure tend to fail for short times (typically very inconvenient times) fairly frequently, on the order of once or twice a week. The relative cost of this is highly variable and business-dependent, but at best its mildly inconvenient and at worst can be crippling. Its definitely something that needs to be accounted for. That said, I've also been lead on apps that used the same pieces of server infrastructure that had far better uptime when I handle ops myself instead of delegating that to another provider. (Not to pick on the providers—they have a very difficult job to do in a cost-effective way, and I'm quite certain that they do it better at that scale than I would.)
The choice of Erlang for WhatsApp was strategic if for no other reason that that it allows them to dispense with some of those choices. Many of the typical use-cases of Redis, for example, are easily supported by OTP.
Do you? If yes, please enlighten us. Otherwise I don't see the point of your objection. No one said that it can be done in a weekend. All that the parent comment said is that the fundamentals of building WhatsApp are already solved. He/she didn't dismiss it. Just because something isn't rocket science doesn't mean it's not useful.
As for Facebook, people used to dismiss it not because it was seemingly too easy to build but because they failed to see its usage. Long before it became a platform it was pretty much a waste of time. Obviously anything with more than a hundred MM users is difficult to maintain.
Go watch this: https://www.youtube.com/watch?v=TneLO5TdW_M#
What I in _no_ way could do is rewrite fb or twitter at the scale these systems operate today with a billion users and even more posts and data points. I don't agree with the sentiment of the previous poster, but fb & twitter were initially basic CRUD apps.
And yes of course you will want to take a step back and change almost everything about it if you want it to scale to more orders of magnitude.
There's a ton of work involved in making a platform like WhatsApp a polished user experience. There's then a ton more work involved in making it _solid_. In choosing Erlang, they chose a platform that trivialises a large part (though not all) of the latter, allowing them to focus on the former.
Is this a simple 'solved' problem that anyone could do? No. But is it a super-human feet that only a handful of people could achieve? IMO, no as well. I think people in the latter extreme like to believe this as it's something they can aspire to - to say otherwise is to devalue their vocation. In the former camp, I think it's people pushing back against this too far in the opposite direction.
Maybe the backend. I couldn't write a Blackberry Java app though which was WhatsApp's initial value proposition.
From a technical standpoint, WhatsApp, the product, and the scale they operate at are nothing new.
(note that both google and facebook use proprietary chat protocols now i believe)
Don't forget WhatsApp has applications on all platforms.
- What if A has a Nokia and B has an iPhone?
- What if you want A, B, and C to have a chatroom?
- What if someone starts spamming random people?
- How do we QA the thing for all these platforms?
- How about someone to keep the visual design fresh?
- What about a million corner cases like when someone is not online, someone sends a message that's too big, one of the servers goes down, and so on?
Etc.
You're right that the scope is not as big as some other apps, and that's what makes 50 a sensible number rather than 5000.
It's easy to see what pieces you need. But there's still work in glueing them together and testing the result.
I think 50 is a sensible number of in-house engineers for this sort of thing. You want cover as well in case someone leaves or gets ill. You want people to be able to upgrade the system when things change. You want people to look ahead at future requirements. And you want to be able to do these things all at once, with slack built in for peak load.
WhatsApp did nothing technically challenging, but they did strap a business model (err, sort of) to something many others failed to capitalize on.
http://gagne.homedns.org/~tgagne/contrib/EarlyHistoryST.html
Also, let's not forget to give credit to Carl Hewitt who came up with actors in the first place [2].
Talking about ejabberd is admitting a core piece of the product is standing on the solders of giants. Something startups are often loathe to do.
That's a social problem though (the fact that 35 guys generate so much cash, while on the other side of the planet 350 millions are looking for a way to pay the rent), not a technical one :-)
Also, an army can only send so many messengers before you run out of soldiers (or operational readiness). Packets are free and plentiful. If you're on a network link so bad that you can't even occasionally receive a TCP ack, then you're very much an outlier.
Also make sure to support offline devices being sent text, audio, video and image files (and the client application on several platforms)