Haisum's Blog It's not a bug, it's a feature.

Using RPC for message passing in distributed systems

My last post discussed about distributed systems and their problems. The most important and fundamental requirement in distributed systems is message passing between different processes so they can coordinate on a single task. We want such communication to happen in an standardized and reliable way. Fortunately, because of years of research and real world usage we have a number of reliable protocols to meet our needs. SOAP, Thrift, REST APIs, message queues such as RabbitMQ, key value stores such as Etcd are examples of tools and protocols we may use to enable two processes to communicate. One of reliable and frequently used protocols is RPC.

A Primer on Distributed Systems

Days of Moore’s law, that number of transistors in an integrated circuit double every two years, are arguably numbered. Our modern world grows and demands computing needs faster than Moore’s law. We have complex applications and big data which simply can not be processed and stored by a single computer, no matter if that’s the fastest computer in world or has maximum possible hard drives attached. A modern scalable application consists of several processes. A process, as I use here, may represent a physical computer, a virtual machine, a container, or a thread in a concurrent system. A fundamental problem in such a hybrid architecture is that each process needs to communicate and coordinate with other processes to work on some task. Such processes may be distributed as containers or virtual machines on same server or be on separate server nodes in same datacenter or even distributed to separate distant datacenters connected with secure networks. We call such systems by names such as Distributed Software Systems, Distributed Architecture and Microservices etc.

Getting into Google's knowledge graph

Google tables pygments jekyll highlighters

Writing makes science possible

Years ago, I was forced to go through a series of audio lectures by Professor Steven L. Goldman on Great Scientific Ideas That Changed the World. It was part of a undergraduate course, so I had to listen, read and understand the lectures. Turned out, it was one of best things I did during graduation. I recommend anyone interested in learning history of science and how it evolved and shaped our modern world to go through the lectures. If you are more of a reader than listener, transcript of those lectures is available in PDF which you can read on your kindle or print out and read on paper. It will be one of best things you’ll read about our modern world and how science played an elementary role in building it.

Relief of knowing the bug isn't your fault

I wrote a vagrant file for local setup of jekyll for this blog last week. One really annoying bug that bothered me was that in spite of installing ruby2.0 package, bundle install command was failing on different bundles again and again with very obscure errors. Digging in deep revealed in spite of installing ruby2.0 only, /usr/bin/ruby was pointing to ruby1.9. I thought I was at fault first, but after some retries concluded, either of ruby, ubuntu or jekyll screwed up. Ruby 2.0 is requirement for jekyll, so symlinking /usr/bin/ruby2.0 to /usr/bin/ruby solved the issue, but if anything else depended on ruby1.9 in ubuntu, it would break. I didn’t really care because all I wanted with my ubuntu/vagrant vm was running jekyll so I could preview my blog before pushing it. Today after some google search I found it was indeed a bug by Ubuntu itself. You can see a lot of bashing going on at Bug#1310292: installing ruby2.0 results in ruby 1.9.3-p484 as default version. It feels good to find bugs in such big scale, quality software. You find satisfaction in knowing you aren’t the only one introducing stupid bugs in production.