Friday, March 27, 2009

Small clouds - Large clouds

So, I attended this seminar recently, in which the usual suspects were paraded in front of a saucer-eyed audience; There was Amazon, Salesforce, local hopes and established players in equal measures. The first presentation was by a Swedish guy named Joakim Lindbom, CTO at Cap Gemini in Sweden - a really sharp guy, by the way.

His talk was about Amazon EC2, and I had heard a lot of it before, but not everything. Joakim focused on the architectural choices that Amazon had made when creating their different services, being an architect himself. He argued successfully the common knowledge that it really isn't possible to scale a relational database to do what Amazon have to do, and that the same apply to services.

In general a cloud-based architecture means that you use a distributed queueing service both to store incoming requests and to communicate between system parts. Yes, a kind of ESB, if you will, but simple!

It also means using schemaless databases that don't mind adding another column even though there's already 1.0E9 items in the table. 

And then it struck me; If it is absolutely critical to use ___SIMPLE___ (meaning non-complex, OK?) services which are both asynchronous (queued, event-driven) and dynamically or non-typed, to be able to build a system over a certain size - why is this not critical when building smaller system?

Or, to phrase the questions differently; How comes it is possible to build systems that does not comply with these traits, since they have been proven to be just critical? Size, is the answer of course.

But to expand that answer is to get to the core of the problem; Smaller sized systems can skimp on doing things right, because it doesn't show up until they get larger. And what small system doesn't?

So, essentially, what has been discovered to be critical in building large-scaled 'cloud' systems is just as essential in building smaller system, it just isn't as evident. Which of course can be translated as saying that it isn't critical. And, no, sure, it isn't critical. But what I'm saying is that even smaller system will by necessity cost less to build, if built according to the same principles the larger-scale system use, if nothing else but the simple fact that they will grow over time.

One of the successes of Erlang has been the reational approach to distributed proecessing; Since interprocess communication in Erlang is message-based, putting those messages on a bus รก la Amazon's simple queue service, will be transparent to the processes using it, and also, those very processes need not know where they are and can so be safely dotted out in the cloud somewhere.

Imagine if someone would do that kind of stuff to another cool language, maybe one with first-class and anonymous functions, duck-typing (Simple, 'schemaless'), closures and late binding (i.e. easy to code in), like ... JavaScript? Maybe someone already has? :) 

No wait, nobody has to, right. It usable that way right off the bat. 

Have a nice weekend all y'all.


Tuesday, March 10, 2009

Google Friend Connect Public Key finally released :)

Yes! After months of general agonizing and a feeling that everything I knew about security *might* be wrong, Google releases the public key for the certificate that signs the signed requests coming from custom GFC gadgets back to your server.

Arne Rooman-Kurrik (at Google) posted the certificate to the OpenSocial mailing list yesterday, and it looks like this;


It was later verified to work by a guy called videomap (should work at Google).

For old readers of my blog the magnitude of this event is simple to understand, but just to be sure, it goes like this;

1) You think that GFC is kind of cool. You put a gadget (or several) on the pages of your site, Google manages login, authentication, friend management et.c and people can chat , rate and have fun on your pages.
2) You realize that allthoug people are having fun there is zero (0) interactivity between the GFC gadgets and your site, and/or
3) You would really like to know the unique user id of the GFC loggged in user that sees you page right now.

So, you..

4) Learn how to create a custom GFC gadget (Exactly like creating a custom OpenSocial gadgets. Just grab one of the smallest sample code files, and you're done. Well, you have to get the 'wrappin' HTML for it from the GFC admin console for your site. Whatever).
5) You put the gadget on your ite in a nice, shiny directory
6) You enter the wrapping code in your page that loads you custom gadget *through* Google's GFC servers.
7) You browse through the OpenSocial 8.x AP docs and realize that you need to do a makeRequest() call back to an url of your server, getting the usr id (and picture) is dead simple, so you have that already in the other hand.
8) Yay, Your custom gadget actually send back the info! Great.

But then you realize...

9) Anythion on your page could actually have sent back that info. A malign ad might inject some script which runs and just send back 0000 or something. Translation: You can't trust informatiuon sent from the client.
10) You find a great option to makeRequest in the OpenSocial API called SIGNED requests. This will make the container (the GFC server in this case) sign the data you send. But also add signed and correct user ids for the viewer and owner of the current data. Yay!

It doesn't work. Until..

11) It suddenly does, a couple of weeks ago GFC decides to activate SIGNED requests. Wild joy. Everything seems ok.


12) You realize you don't have the public key the GFC uses, so you can't actually verify that some *other* server on the internet tries to look like it is a GFC server and feed you false data. Eugh.

But then

13) They did publish the public key (Above), so now the circle is finally closed. We can now use GFC as a universal login mechanism, get a unique user id back to our server,a nd connect that to any data we choose.

Thanks Google!!!