3 ms·

I think that indeed the important thing here. The article try to focus a bit too much on some intrinsic qualities of the language as if it was the silver bullet

by gutnor 11y ago

I think that indeed the important thing here. The article try to focus a bit too much on some intrinsic qualities of the language as if it was the silver bullet of scalability while the real lesson is that they used the right tool for the job. 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.

GFischer 11y ago
Indeed. It's amazing :) . All the infrastructure-as-a-service stuff REALLY cuts down the overhead. 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?
- karmajunkie 11y ago
  > 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.
ManFromUranus 11y ago
From the article: * 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).

by gutnor 11y ago

GFischer 11y ago

Indeed. It's amazing :) . All the infrastructure-as-a-service stuff REALLY cuts down the overhead. 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?

karmajunkie 11y ago
> 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.

ManFromUranus 11y ago

From the article: * 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).