Rachel calls this “mellow” – I say “cogent commentary” :)
Wednesday, March 13, 2013
Primo on Politics...
Rachel Lucas' new dog Primo comments on politics:
Rachel calls this “mellow” – I say “cogent commentary” :)
Rachel calls this “mellow” – I say “cogent commentary” :)
Breaking Up Is Hard To Do...
This article about breaking up with an old car instantly resonated with Debbie and I. We recently traded in our old '96 LandCruiser – which we named “Siggy” (after the “8SIGMAS” on its plate). So many wonderful memories in that car; so many hours of companionship provided...
How's That War on Drugs Going?
The green line shows what we're spending, per capita, on the war on drugs. The blue line shows the drug use, per capita, over the same period. Chart is by Matt Groff.
What a stunning success!
Yes, that was tongue-in-cheek. Sure wish we hadn't wasted those billions of dollars...
What a stunning success!
Yes, that was tongue-in-cheek. Sure wish we hadn't wasted those billions of dollars...
Curiosity: Life-Friendly Environment on Mars...
Curiosity has finished analyzing the rock powder its drill produced a few weeks ago. The results show that ancient Mars had all the right attributes to sustain life. They're not claiming (not yet, anyway) proof that life actually did exist there; just that it could have...
15:1 Server Reduction...
Applications running at any significant scale typically execute on clusters of servers. These clusters are composed, generally, from multiple similar servers. These servers share the overall load of the app, allowing many more concurrent users than could ever run on a single server. You could think of the clerks in the grocery store checkout as a human equivalent. Having multiple servers also provides an arbitrary degree of redundancy, so that if one or more servers fail for any reason, the working servers remaining can pick up the load. Building big clusters (if big enough, often called “server farms”) is the brute force way to scale up almost any modern web application. It's the standard, “out-of-the-box” way to scale up to large loads; it's what everybody does.
Well, almost everybody.
Depending on the business model of the application in question, the cost of the additional servers may be significant. In other words, if your application doesn't make a lot more money than the servers cost, you're going to care about that server cost. How can you reduce the number of servers required to handle the load?
The answer to that is very specific to the precise nature of each application. There are several general approaches one can take, ranging from the traditional iterative bottleneck identification-and-destruction technique to the raze-and-rebuild technique.
In the latter category is this: figuring out that you made a poor choice of programming language, and rewriting your entire application from scratch in a new language. In our real-world equivalent, it's as if you replaced the ordinary checkout clerks with supermen who worked many times more quickly. That's what these folks did, moving from Ruby to Go – and their reward was a reduction from 30 busy servers to 2 idling servers (and only 2 in order to provide redundancy!).
As one of the commenters points out, probably moving from Ruby is the important part of the exercise – most likely nearly any choice of a “normal” programming language (C, C++, Java, Erlang, etc.) would have achieved similar gains. The author, however, makes some interesting points about Go – to me, most especially concerning its support for concurrency...
Well, almost everybody.
Depending on the business model of the application in question, the cost of the additional servers may be significant. In other words, if your application doesn't make a lot more money than the servers cost, you're going to care about that server cost. How can you reduce the number of servers required to handle the load?
The answer to that is very specific to the precise nature of each application. There are several general approaches one can take, ranging from the traditional iterative bottleneck identification-and-destruction technique to the raze-and-rebuild technique.
In the latter category is this: figuring out that you made a poor choice of programming language, and rewriting your entire application from scratch in a new language. In our real-world equivalent, it's as if you replaced the ordinary checkout clerks with supermen who worked many times more quickly. That's what these folks did, moving from Ruby to Go – and their reward was a reduction from 30 busy servers to 2 idling servers (and only 2 in order to provide redundancy!).
As one of the commenters points out, probably moving from Ruby is the important part of the exercise – most likely nearly any choice of a “normal” programming language (C, C++, Java, Erlang, etc.) would have achieved similar gains. The author, however, makes some interesting points about Go – to me, most especially concerning its support for concurrency...
Cheap, Simple, Small, Safe Nuclear Power...
Molten-salt fission reactor technology sounds compelling to me, the more so every new time I read about it. In a rational world (that would be some other planet, most likely in some other space-time continuum), environmentalists would be demanding the use of technology like this in place of coal- or gas-fired electrical generation. I've only seen them railing in mostly mindless opposition, though...
Lakes Entertainment, Cleaning Up the Mess Edition...
Lakes Entertainment has posted its 2012 Q4 and Y results, which prominently features the wind-up of it's agreement with the Jamul Indian Tribe. There no real news here, just an opportunity for some schadenfreude and satisfaction...
How I Wish Congress (or Obama) Behaved...
This brilliant clip lampoons Congress and Obama for ratcheting up the national debt – and it does so in a way that absolutely anyone can comprehend. The facial expressions of the banker eloquently convey the reactions that any fiscal conservative would wish that Congress and the executive branch would have when asked to raise the debt limit. I know, I know, it isn't going to happen. But I can still hope, can't I?