hot links

Stuff The Internet Says On Scalability For July 31st, 2015

High Scalability

High Scalability

— 5 min read

Hey, it's HighScalability time:


Where does IBM's Watson or Google Translate fit? (SciencePorn)

  • 40Tb/s: Bandwidth for Windows 10 launch; 4.04B: Facebook Q2 revenue; 37M: Americans who don't use the web;
  • Quotable Quotes:
    • @BoredElonMusk: We would have already discovered Earth 6.0 if NASA got the same budget as the DOD.
    • David Blight~ Something I've always believed as a historian and more and more it seems true to me is what really moves history, or brings about change in rather sudden and almost always unpredictable ways, is events. 
    • Quentyn Kennemer: Tom Brady replaces Android with iPhone, gets suspended 4 games
    • @BenedictEvans: Apple Maps has ~300m users to iOS GMaps 100m, of 4-500m iPhones. Spotify has 20m paying & 70m free users. And then there’s YouTube
    • Ben: Some scale problems should go unsolved. No. Most scale problems should go unsolved.
    • @mikedicarlo: 3.5 million Redis ops per/sec across our cluster. Wondering how that compares with other production deployments out there. 
    • @Carnage4Life: $1 billion valuation for a caller ID app with $800K in revenues? Unicorn valuations are officially meaningless 

  • Is shooting a trespasser filming a video of your potentially intimate moments considered a crime? Kentucky man shoots down drone hovering over his backyard. 

  • Death through premature scaling. Larry Berman determined this was the cause of death of RewardMe, his once scrappy startup. In the next turn of the wheel the dharma is:  Be a 1-man growth team;  Get customers online as oppose to through a long sales cycle; Don’t hold inventory; Focus on product and support. The new enlightenment: Don’t scale until you’re ready for it. Cash is king, and you need to extend your runway as long as possible until you’ve found product market fit. 

  • What about scaling for the rest of us? That's the topic addressed in Scaling Ruby Apps to 1000 Requests per Minute - A Beginner's Guide. A very good resource. It goes into explaining the path of request through Heroku. Dispels some myths like scaling up makes a system faster. Explains queue time. And other good stuff. 

  • Not quite as sexy as Zero Point energy, but 3D Xpoint memory sounds pretty cool: Intel and Micron have unveiled what appears to be the holy grail of memory. Called 3D XPoint (pronounced "cross point"), this is an entirely new type of non-volatile memory, with roughly 1,000 times the performance and 1,000 times the endurance of conventional NAND flash, while also being 10 times denser than conventional DRAM.

  • So what is 3D XPoint Memory really? Here's a great analysis at DailyTech by Jason Mick. More than analysis, it's a detective story. Jason puts together clues from history and recently filed patents to deduce that this new wonder RAM is most likely to be PRAM or Phase-change Memory, that stores data "in the form of a phase change to a tiny atomic-level structure." Jason thinks "any usage scenarios, it may be possible to run exclusively off PRAM." Forgetting just got even harder.

  • Damn. I may die after all. The Brain vs Deep Learning Part I: Computational Complexity — Or Why the Singularity Is Nowhere Near: My model shows that it can be estimated that the brain operates at least 10x^21 operations per second. With current rates of growth in computational power we could achieve supercomputers with brain-like capabilities by the year 2037, but estimates after the year 2080 seem more realistic.

  • It has always struck me that telcos who desperately want to get in to the cloud business, where they are just an also ran, control some of the most desired potential colo space in the world: cell towers. Turn those towers into location aware clouds and we can really get some revolutionary edge computing going on. Transiting traffic back to a centralized cloud is such a waste. Could 'Supercomputing at the Edge' provide a scalable platform for new mobile services?

  • What do you think of this analogy from aquadrop?: AWS is a giant construction store like Home Depot, where you can find everything. Rackspace is local home improvement shop, with good service, which was doing fine until Home Depot build it's store nearby. Now people have less and less reasons to visit it. Some folks like it for the old times sake, though. DigitalOcean is your buddy who works at "Hammer&Nails Manufacturing Inc.", he can get you nice hammers and nails pretty cheap if you ask him, but not much else.

  • It looks like Google is still obeying Moore's law in their cloud pricing. Pay Less, Compute Moore, reducing VM pricing by up to 30% and preemptible VMs are 70% cheaper than regular VMs. Will Amazon follow? Or does Amazon think they don't have to compete on price anymore?

  • There is another. Adventures in High Speed Networking on Azure: So far, we believe this more than validates that we are not compromising performance by running in Azure, using Windows or managed C# to get both the best performance and also the most developer productivity. 

  • Why Docker is Not Yet Succeeding Widely in Production. zaargy nicely sums it up: It's too damn complicated if you're not Google/Twitter/Netflix. Most people would be fine just deploying OS packages and keeping their stacks as simple as possible.

  • GopherCon 2015 are now available. 

  • Ticketmaster solves their problems the old fashioned way: with C++/assembly. The Tao of Ticketing: The demands of the algorithm (must be serialized; cannot be scaled; very high peak loads) requires it to be exceptionally fast, hence the C++/assembly core. The authors of the Core are long-time Ticketmaster Host assembly developers, who are used to maximizing tiny bits of memory and CPU. Each event is assigned exclusively to one Core, which loads it into memory and performs the search algorithm from there. The result of all this is low level search times measured in microseconds.

  • If data isn't going to be free, it should at least be available. Scientists Are Hoarding Data And It’s Ruining Medical Research. Data balkanization is costing us a lot of healing opportunities.

  • Awesome graphics. Performance Optimization, SIMD and Cache. A commenter said it best: fantastic video on an important subject. I think most people won't really internalize the speedup they get by accessing memory in a different way until they actually see it for themselves.

  • Valve shows how to query 50K game servers in Python. Nothing dramatic, but a nice little example.

  • How Google Translate squeezes deep learning onto a phone: To achieve real-time, we also heavily optimized and hand-tuned the math operations. That meant using the mobile processor’s SIMD instructions and tuning things like matrix multiplies to fit processing into all levels of cache memory.

  • Why are there so many programming languages? How about geographical isolation? Like Australia. Lots of programmers are in their own rooms so they naturally evolve their own languages.

  • Here's how Netflix fixed a problem where traffic spikes would cause  cpu starvation which caused unresponsive servers. Tuning Tomcat For A High Throughput, Fail Fast System. They got rid of Apache. The system was now simpler. Then they did a back of the envelope style calculation to determine how many threads Tomcat should be configured to use. When the number of requests reached the number of threads the requests were bounced. The also did a bunch of other fine tuning. 

  • CascadiaFest 2015 videos are now available. 

  • CQRS and Event Sourcing for dummies: CQRS is based in Bertrand Meyer’s CQS (Command-Query Separation) concept. CQS states that every method should either be a command that performs an action or a query that retrieves a result. The concerns shouldn’t be mixed.  

  • PINRemoteImage: a library we [Pinterest] use to download more than three billion images to the Pinterest iOS app every day and quickly render them back to tens of millions of Pinners. So if you have an image-heavy app, instead of writing new code, this technology allows you to download, cache (on disk and memory) and prefetch images to reliably display them to your users.

  • The Scalable Commutativity Rule: Designing Scalable Software for Multicore Processors: Whenever interface operations commute, they can be implemented in a way that scales. This rule aids developers in building more scalable software starting from interface design and carrying on through implementation, testing, and evaluation. 

Read more