Re:Simple Systems Have Less Downtime
by nickbauman on Tuesday March 03, 2020 @09:38AM
(#22474745)
They chose Erlang. A language built for communication and managing wire protocols at scale. Which describes WhatsApp itself. That was probably the biggest impact single decision for WhatsApp technically.
Re:Simple Systems Have Less Downtime
by ignoramous on Tuesday March 03, 2020 @09:59AM
(#22474914)
I am not sure if WhatsApp engs chose ejabberd because it was written in Erlang or because ejabberd was the defacto implementation of XMPP. They stumbled upon and fixed bugs in BEAM/OTP at their scale [0][1][2]. They also ran FreeBSD (for its superior networking?) on bare-metal hosts running customised system-images [3] and employed networking experts at some point.
[0] https://www.youtube-nocookie.com/embed/c12cYAUTXXs
[1] https://www.youtube-nocookie.com/embed/wDk6l3tPBuw
They ran FreeBSD because Jan came from Yahoo, and that's what Yahoo ran.
Re:Simple Systems Have Less Downtime
by vaingloriole on Wednesday March 04, 2020 @01:25PM
(#22486298)
'customized systems (kernel)..FreeBSD..bare metal': Which is what most of us still do if we care about performance for a single application. Running openmp fortran code for both host/accelerator on oversubscribed vmware or vanilla kvm/qemu for a good laugh and a lot of pain. Simple systems approaches are best even when what you are doing is complicated.
I could be wrong but I think freebsd allowed multiplexing connections per port before Linux? Please correct me I am mistaken about this.
Erlang is like Bugman from the Nightmare Before Christmas. It is literally made out of microservices at every level.
Microservices are a design philosophy that people confuse as a deployment strategy.
Re:Simple Systems Have Less Downtime
by cristaloleg on Tuesday March 03, 2020 @12:01PM
(#22476310)
> Microservices are a design philosophy that people confuse as a deployment strategy.
I'm going to print this and show everyone, great words, thank you.
Not necessarily, you can design erlang systems with more coupling than you'd expect in traditional microservices. Microservices mean that your codebase is segmented along business concern lines.
I would rather argue that microservices are best implemented when each service owns a bounded context in the lingo of domain-driven design. Business concerns might align with that, or they may not, depending on how technically complex (vs product complexity) the product is.
Yes, that is a better definition, but nonetheless you can design erlang systems with a single domain, or design erlang systems as a monolith, even if it has a billion actors running around underneath.
Kinda, yeah, except Erlang is microservices made easier. I've loved how the language makes building distributed systems so comparatively easy since I ran across it back in 2005.
Re:Simple Systems Have Less Downtime
by munchbunny on Tuesday March 03, 2020 @12:45PM
(#22476813)
That was probably the biggest impact single decision for WhatsApp technically.
As a rule of thumb based on my own experiences and the opinions of more experienced engineers I've had the good fortune to work with, language choice is far less important than the quality of the team using it.
While I have no doubt that trying to build WhatsApp in a language that would be the wrong tool for the job (say... PHP) would have been fatal, I have many more doubts that choosing Erlang was the key enabling decision.
Language choice I can perhaps agree with, but from what I've read, the biggest factor with Erlang is much more its runtime environment. BEAM + OTP is a very impressive piece of kit.
I don't know. Erlang is a "funny" language that can somewhat easily do certain things that would be much more time consuming to accomplish in a more mainstream programming language. The difference between building whatsapp in Erlang vs any other programming language is probably larger than building it in php vs any other mainstream language.
Converse: Can you imagine WhatsApp parallel universe serving with Node?
Yes :)
Success is more to do with user experience..
If you hit gold and scale you can almost always optimize the implementation later.
Iirc Slack's backend is PHP.
They've moved over everything to Hacklang, which is a derivative of PHP.
The engs they had were world-class, so really, I think, saying microservices (or latest-fad) get in the way etc is disingenuous since you also require world-class talent to begin with (if you're going to keep the team-size small and yet be able to manage crazy scale) and a competitor willing to pay through the nose for the acquisition.
[0] https://www.sequoiacap.com/article/four-numbers-that-explain...