Google App-Engine “Doesn’t” Scale
I agree for the most part with your final conclusion: “no system that is
likely to become productionized at scale should be written on App Engine.”
This is a sad conclusion to arrive at after all these years, especially when
the original promise of App Engine was (essentially) “write your applications
against our strange, quirky API, and they’ll scale far more cheaply and
reliably than they could otherwise.”
[source…]
I’m going to have to add fuel to the fire here, 100% agreement.
GAE is “irreplaceable” in the sense that while the API has been mostly duplicated, the ability to scale that API to arbitrarily large workloads has not.
There was a blog article a long time ago that talked about designing a future language and came to the conclusion that perhaps even performance characteristics should be specified. For example, a language where sort might have n^2 vs. n log n performance characteristics will work fine for basic workloads but will wreak havoc when used at higher capacities. Specifically, after a certain point, performance expectations become part of the implementaiton.
So you have GAE, which has incredible “Superman” powers, faster than a speeding bullet, more powerful than a locomotive, etc. and irreplaceable for automatically scaling to arbitrarily large workloads. And therein lies the rub, as described in the linked article.
The one feature that GAE gives you, the reason you’re sacrificing everything to work in GAE’s world is the one feature you can’t count on. You can’t count on it due ENTIRELY to the mismanagement by Google of their GAE developer community. E-N-T-I-R-E-L-Y. It is a good thing Netflix made their pricing and customer-rlation screwups after Google did otherwise I would say they had “Netflix-level” poor planning and communication.
Actually there are two reasons. One is that GAE cannot be replaced (there is no alternate GAE provider that can scale to some arbitrary 1TB workload) and two is that GAE so poorly mismanaged the “transition to non-beta” product for GAE.
A few years ago I sung the praises of Google’s strategy with GAE and Adwords. I would tell people: “Where is autos.google.com?” And autos.google.com is actually google.com/search?q=autos because every auto forum is running Adwords against their content. And then they launched GAE and my expectation was that a lot of the autos websites (mysweetcorvette.com) would transition to using a GAE-based forum and google would make yet-even-more-money hand over fist.
They give you the tools to get started capturing users and generating content, the tools to monitize it, and the more users / monetizing you get you bump from the GAE free tier to the GAE pay tier. Of the $100/mo you get from Google Adwords, you start paying $1/mo to Google and earning $102 from Adwords. Then $10/mo to Google and earning $120 from Adwords as your userbase continues to grow.
But alas, this wasn’t meant to be. Google has a unique, challenging, irreplaceable developer product to use and the one thing it excels at (scaling) is the one thing that is impossible to trust.
At this point, I imagine that Amazon’s EC2 + “Individual Dumb Services” is far better compared to Google’s style (which doesn’t bode well for future Google acquisitions……). S3 is too expensive? Move to a different “I serve files from big hard-drives” provider. SimpleEmail not doing it for you? Get on board with a different “pay-to-spam” provider. EC2 doesn’t match your needs? Find a different cloud provider and have a minimal implementation up and running on them.
Amazon, by designing their services around commodity components that encourage competition and API duplication has paradoxically made their service more architecturally robust (in the sense that a customer has tons of options for migration, price, and performance competition). Downtime(s) notwithstanding, it looks like the original blog author has hit the nail on the head.
EC2-style implementations require a bit more work up front but leave you in a more price-competitive situation if your product takes off and gets a lot of traffic. And your product won’t. 99.9% of the time you’re gonna be fine with a single box or a 4-box setup (2 frontend, 2 database). And if you do reach the giddy heights of needing GAE’s scalabilty, you have to begin each SEC filing with: “Assuming Google doesn’t raise prices for app-engine by ∞% like they did last year …”
Enjoy the Ferrari, Google and I guess everybody else will stick with their daily drivers.
11:57 CST | category / entries
permanent link | comments?
Wealth and Wants
Wealth is not the same thing as money. If you want to create wealth, it will
help to understand what it is.
Wealth is the fundamental thing. Wealth is stuff we want: food, clothes,
houses, cars, gadgets, travel to interesting places, and so on. There is not a
fixed amount of wealth in the world. You can make more wealth.
People think that what a business does is make money. But money is just the
intermediate stage— just a shorthand— for whatever people want. What most
businesses really do is make wealth. They do something people want. Money is
a comparatively recent invention.
A surprising number of people retain from childhood the idea that there is a
fixed amount of wealth in the world. There is, in any normal family, a fixed
amount of money at any moment. But that’s not the same thing.
Suppose you own a beat-up old car. Instead of sitting on your butt next
summer, you could spend the time restoring your car to pristine condition. In
doing so you create wealth. The world is— and you specifically are— one
pristine old car richer. And not just in some metaphorical way. If you sell
your car, you’ll get more for it.
In restoring your old car you have made yourself richer. You haven’t made
anyone else poorer. So there is obviously not a fixed pie. And in fact, when
you look at it this way, you wonder why anyone would think there was.
[source…]
I took the liberty of de-Paul-Graham-ifying a bit of this to make some of the central points more clear.
10:55 CST | category / entries / links
permanent link | comments?
Programming Language Roundup
I guess it’s on everybody’s mind lately, but here is an excellent overview of “new” languages to come out in the past few years. Definitely a lot more than I thought there were at first.
In this post I will provide a list of fairly new languages (let’s say 5
years with a little flex) that display interesting features and display
higher-order thinking in the way that they tend toward an evolution of past
learnings in programming language thinking.
[source…]
The one that sticks out to me is Shen which has a few very interesting features.
- It is lispy, focusing in a very portable core instruction set
- It supports ML pattern matching
- It supports Prolog “question resolution”
Taking a look at each point in turn, once you get past the parenthesis, lisp syntax is very cool. If you try to do a good job of following functional / immutable / transormative programming you end up changing the way you write code.
// procedural style
var abc = 6;
double( abc );
triple( abc );
assert( abc == 36 );
// functional style
var abc = 6;
var def = double( abc );
var result = triple( def );
assert( 36 == result );
// "clean" functional style
var result = triple(
double( 6 )
);
assert( 36 == result );
Obviously the above is a contrived example (to be even “cleaner” you would do away with the temporary “result” variable), but you can see that as you get “more functional” you naturally tend to collect parenthesis, no matter the language you are working in.
The “pattern matching” aspect that I really liked from ML is pretty much syntactic sugar for if / else or case / switch but built in to the language.
I find that I’m often writing code like this:
// old style
function foo( a, b ) {
if ( 1 == a ) {
alert( 'foo ' + b );
}
else if ( 2 == a ) {
alert( 'bar ' + b );
}
else {
alert( "unknown action: " + a );
}
}
// new style
function foo( a, b ) {
var mapping = {
1: function( b ) {
alert( 'foo ' + b );
},
2: function( b ) {
alert( 'bar ' + b );
},
}
if ( mapping.hasOwnProperty( a ) ) {
mapping[a]( b );
}
else {
alert( "unknown action: " + a );
}
}
// "better" new style
function foo( a, b ) {
var mapping = {
1: doAlertWithFoo_ref,
2: doAlertWithBar_ref
}
if ( mapping.hasOwnProperty( a ) ) {
mapping[a]( b );
}
else {
alert( "unknown action: " + a );
}
}
// "hypothetical" pattern-matching style
function foo( 1, b ) {
alert( 'foo ' + b );
}
function foo( 2, b ) {
alert( 'bar ' + b );
}
function foo( a, b ) {
alert( "unknown action: " + a );
}
Again, an extremely contrived example, the point being that you treat conditionals as mappings instead of bare if/else clauses. Then, the only bugs you can have are “I am missing a mapping” or “My mapping is criss-crossed” or worst “My target action is buggy”.
The pattern-matching aspect of a language makes it easier (supposedly!) to reason about functions. Instead of having to read inside a function to determine how it behaves (for many if/else cases), you can promote that to the top level of function definition (in the above, read function foo( 1, b ) as: when foo is called with 1 as the first parameter).
The coup de grâce for me though is the inclusion of a version of Prolog core within the language. In the same way that regexes make string processing a million times easier, prolog makes logic processing a million times easier. And who would have thought… but logic processing turns out to be a useful thing to optimize from time to time.
You’ll have to bear with me on this one because it’s a little harder to explain. But let’s say we have a computer.
def isComputer( x ):
return x has memory and x has cpu and x has hard_drive
def 4gig_o_ram is memory
def 2gig_o_ram is memory
def 1gig_o_ram is memory
def amd_chip is cpu
def intel is cpu
def seagate is hard_drive
def western_digital is hard_drive
my_computer = 4gig_o_ram and intel and western_digital
def canRunWindowsVista( x ):
isComputer( x ) and has 4gig_o_ram
canRunWindowsVista( my_computer )?
=> true
Again, a really contrived, terrible example with incorrect syntax. But the idea is that you set out the facts and you let the computer (90% of the time) figure out all the boring crap of making sure your arbitrary constraints aren’t violated.
You run into this problem All. The. Time. when working with config files, validating function parameters, determining if a user has permission to perform an action, etc, etc, etc. Regexes are very information dense around a well-defined problem. “Prolog” is a bit more verbose around problems that you define yourself, which is my theory as to why there has never been a “like-a-regex-but-for-prolog” included in any languages.
I can tell you it excites me to see this Shen project try. Definitely worth paying attention to.
00:52 CST | category / entries
permanent link | comments?
On “Go” and “Dart” - Google Wants You
Inspired by Mr. KrestenKrab, I feel obligated to comment on Google’s language development activities.
Posit. They’ve released “Go” and “Dart” which are improvements to the “C-style” and “Javascript” languages respectively.
Posit. They’ve released GWT which is “Javascript for Java-devs” and they’ve mucked with “fixing” both Python and Java to run in a sandbox / secure environment.
Oh, and I almost forgot they’ve implemented a Javascript engine in V8.
Publicly they’ve talked about their internal tooling capabilities when working with source code (bytecode inspection, singleton detection, the ability to focus unit tests on potentially impacted code based on what lines were changed in a file / diff).
Unfortunately I don’t have all the references handy, but if you pay close attention to what google is doing, you begin to see that they are most definitely on the “other side” of the bell curve from most people in their ability to navel-gaze at their product code.
There are a lot of people who are slamming google and I can’t tell if it’s because they think it’s the cool thing to do, or they don’t understand what they’re doing, or maybe it’s because they are afraid of change?
I can’t tell what it is, but from my perspective, Google’s moves are interesting and fairly transparent.
Obviously they’ve written a lot of code and have a bunch of engineering talent. They’ve also spent a lot of time “cleaning up” other languages / language implementations (javascript-v8 / java-gae / python-gae). They also appear to have taken a hard look at their own code and found areas where C/C++ makes things difficult, as well as that red-headed stepchild: Javascript.
You might also have noticed that each of Go and Dart have “shipped” with online / live compilers exposed to the internet, pretty much from day one. That speaks volumes to their confidence in their ability to lock down the code for use with untrusted input.
Go and Dart both appear to be fairly pragmatic languages, focused on making it easier to write correct programs.
From the Go FAQ:
Go is an attempt to combine the ease of programming of an interpreted,
dynamically typed language with the efficiency and safety of a
statically typed, compiled language. It also aims to be modern, with
support for networked and multicore computing. Finally, it is intended
to be fast: it should take at most a few seconds to build a large
executable on a single computer. To meet these goals required
addressing a number of linguistic issues: an expressive but
lightweight type system; concurrency and garbage collection; rigid
dependency specification; and so on. These cannot be addressed well by
libraries or tools; a new language was called for.
[source…]
From the Dart FAQ:
Create a structured yet flexible programming language for the web.
Make Dart feel familiar and natural to programmers and thus easy to
learn.
[source…]
…and from their leaked document, you’ll also hear that Dart was designed to allow for more complete “tooling” (right-click => refactor) as a design goal compared to the 4-5 “basic” ways that javascript supports classes (bare objects, constructor functions, prototype inheritence, module pattern, etc, etc.).
So… why have Go and Dart “leaked” from the lab into the real world?
This is the interesting part of the Google story. In my day job, I regularly rail on people for inventing dumb libraries, NIH and the like. Right now I’m using a unit test library for perl that is in use nowhere else outside of my company.
The question I always ask: “Can I buy a book on it?” Followed immediately by: “Why is this different than what the blogs are telling me to do?” and “How long would it take somebody to ramp up if I hired them off the street?”
Sometimes there is a good reason, but more often there aren’t good answers to those questions.
So Google’s a smart company, and I’m a smart guy. That means that Google has some of those same concerns. Even if the new languages that Google has put together are materially better than the other languages out there, it still doesn’t help Google until outside people start using them.
They’ve already pushed Guice, GWT, their Java / C development standards, their testing blog, map reduce, everythingmany things they’ve learned internally they’re trying to share with the outside world so that it isn’t quite as big of a shock when fresh meat enters the grind.
If you look at how the existing programming languages were made, they each grew on a strong base (C++ on C. Java on C++. PHP on Perl [heh]. Python on Basic.) and tried to make incremental improvements yet be fundamentally “better” taking into account the shared experience that only real-world use can give.
I think that Google is following in the same tradition, and given their internal experiences, only a fool would dismiss it out of hand.
It was (kindof?) a stroke of genius when Yahoo! ditched their internal template system for PHP. I’m sure it had a profoundly positive impact on their hiring productivity “Oh, you know the most popular web scripting language? Good, that’s the one we use.”
In the same way, if we assume that Go and Dart are in fact materially improved languages (especially if they are materially better inside of Google), it is in Google’s vested interest to get as many people as possible using it. The more someone knows before joining a company, the lower their training costs are, the higher their productivity.
Their focus with these languages (at least with Go) appear to be laser-like on reliability, ease of programmer use, and ease of inspection / whole program manipulation.
I think that the leaked memo for Dart forced Google’s hand to get something out there quicker than they really wanted. I also think that looking at Dart briefly it would benefit from similar “bold changes while in flight” as they have made to Go based on community feedback (the basic one for Dart they’ve screwed up is not tagging functions with a simple keyword- “def / sub / func / function” so you can grep for things).
Go has been out for approximately two years (November 2009) and they are closing in on their own “Go 1.0” release and have made significant changes to the language during that process.
It will probably be a while before Dart reaches anywhere near the same relevance as “Go” has (which is to say: not that much outside of Google), but I have high hopes, especially if they steward the project well.
Based on the evidence of Go’s evolution and apparent benefits over C, I would hope that Dart follows a similar path. For Google, I assume it will see a lot of use (and quickly!) because they already support cross compiling to Javascript (GWT) and already have a cross-compiler from Dart to JS.
It is not surprising that Google has released these languages. As a matter of fact, they are just following with the tradition of corporations releasing languages they’ve invented and found useful (Erlang=>Ericcson, C=>Bell Labs, Java=>Sun, lots more programming language origins) but what is surprsing is that there are now so few Universities involved in advancing the state of the art in programming.
I wonder if we are entering a “new era” of Computer Science where pragmatism trumps expressing algorithms, or if they have somehow (necessarily) merged into one but now with corporations driving the bus.
21:14 CST | category / entries
permanent link | comments?
