It’s just data

Long Bets

Jerry Cuomo: I see several common threads:

Twenty eight months ago, this bordered on heresy.  And if that didn’t, this certainly did.

Now, it pretty much represents the baseline.  At least for 3 of the 5 (or possibly 4 of the 6 if you count the “subtle” background image).

I’m still hopeful that at some point, people stop being passive consumers of content, and take control over their user experience with tools like GreaseMonkey, but the adoption curve for that and similar technologies seems rather slow, and I don’t see that changing in the near term.

As for continuations, a specialized form, namely closures, is central to Ruby and JavaScript, (and in a somewhat less explicit form: Python), is a part of Groovy, C#, and early exploration is underway for adding closures for Java.

I don’t particularly care whether or not I can count partial credit for that one; and in any case, I certainly didn’t expect to be where we are a mere 28 months later.  But perhaps now would be a good time to look out the next 5 to 10 years.


Five years ago, the state of the art was app silos.  Installing a new application on such a silo was accomplished via drag and drop of a WAR or EAR file.  Now the focus is on Saas.  The apps don’t move, the data does.

The next domino to drop is data silos.  Which if you think about it is a bit ironic.  Just as we move towards desktops with multiple CPU “cores”, and with direct access to terabytes of data storage, we are starting to find the notion that all the data you want is all is one place, all you have to do is form the right query to be increasingly a quaint one.

This makes SQL and components like ActiveRecord the weak link.

So, without further ado, here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field.

Yes, I realize that I’ve duplicated one there.  I don’t believe that we have tapped that particular one sufficiently yet.


So you’re the one that’s been pushing Erlang so much lately, I guess I’ve waited long enough then.

Can you add more hours in a day to that list while you’re at it?

Posted by Billy Girlardo at

[from sogrady] Sam Ruby: Long Bets

“towards desktops with multiple CPU "cores”, and with direct access to terrabytes of data..., we are starting to find the notion that all the data you want is all is one place, all you have to do is form the right query to be...

Excerpt from del.icio.us/network/aheilbut at

links for 2007-08-13

Sam Ruby: Long Bets “towards desktops with multiple CPU “cores”, and with direct access to terrabytes of data…, we are starting to find the notion that all the data you want is all is one place, all you have to do is form the right query to be...

Excerpt from tecosystems at

Jeremy Zawodny : Long Bets - Long Bets: Sam is one of the smartest people I’ve ever met in computing. I suspect he’s right about most of these... Tags : links...

Excerpt from HotLinks - Level 1 at

“This makes SQL and components like ActiveRecord the weak link.”. Yup. But your list of long bets doesn’t offer a stronger one. Personally (as you’d guess) I’d add RDF. For direct weak link replacement, how about (distributed) [link] SPARQL and components like Active RDF? [link]

Posted by Danny at

But your list of long bets doesn’t offer a stronger one.

Actually, it offers two.  Map/Reduce and Mnesia.  Follow the Hadoop and Erlang/OTP links for more detail.

Personally (as you’d guess) I’d add RDF. For direct weak link replacement, how about (distributed) SPARQL and components like Active RDF?

Independent of RDF itself, I believe that late binding the distribution won’t work.  Imagine if a Google query were implemented in such a way that every request resulted in billions of pages being fetchted, even if those pages were fetched in parallel.

No, I believe that the query of the future has to be a bit anticipatory.  Google is constantly crawling pages, and produces some form of index, and that index is replicated and distributed using techniques that Hadoop attempts to replicate.

Whether or not RDF is appropriate for that internal index may be worth exploring, and I would guess that that would depend on how ad-hoc the queries are, and how structured the data is.  In many cases, given that this is a cache built up in anticipation of certain types of queries, it may make sense to heavily denormalize the data optimizing for the types of queries that are expected.

Posted by Sam Ruby at

Long Bets (Sam Ruby)

Long Bets (Sam Ruby) Sam Ruby’s bets on the foundational web technologies of the next 5-10 years....

Excerpt from bcm at

Agile data?

Via Sam Ruby , a post from Jerry Cuomo who asks (rhetorically) : It is worth standardizing an agile platform for our generation’s dynamic web applications? Doesn’t sound unreasonable. He has in mind a particular stack of tools: Ajax, REST, Atom,...

Excerpt from Planet RDF at

This Week's Semantic Web

Selected links related to Semantic Web technologies for the week ending 2007-08-12 In the Media Aug. 7, 1991: Ladies and Gentlemen, the World Wide Web - the Web’s 16th year celebrated at Wired.com Using Wikipedia as a Web Database -......

Excerpt from Nodalities at

Would Scala fall into the ErLang/OTP category? Or would Concurrency Oriented Programming be a more general "long bet"?

Posted by Dave at

RE: Hadoop as a long bet

Is your bet that the programmatic approaches that underly MapReduce and BigTable  will become more widespread or that the the proliferation of the specific implementation in Hadoop which is based on papers about Google’s MapReduce, BigTable, GFS, Sawzall, Chubby, etc will become as widespread as memcached (for example)?

I can see the former, I probably wouldn’t bet on the latter. Some of design choices made in Google’s architecture make sense for their problem space (e.g.  “Moving Computation is Cheaper than Moving Data") but totally crap all over everything we’ve ever learned about decoupling services and isolation. A question to ask yourself is whether "EC2 instances running on the same machines as the S3 server their data is stored on” sounds like a good idea or not. It is , if you believe the Google way is always the right way. Me, I dunno yet. :)

Posted by Dare Obasanjo at

“ but totally crap all over everything we’ve ever learned about decoupling services and isolation.”

It just totally craps over a particular class of application.

“A question to ask yourself is whether "EC2 instances running on the same machines as the S3 server their data is stored on” sounds like a good idea or not. It is , if you believe the Google way is always the right way.”

[link]

there’s more than one right way; it depends on the problem space. If you follow that link, the book that quote is taken is the first place I saw a program in the style that is now called mapred. Review here:

[link]

I’d encourage anyone that’s interested in this corner of the computing world and wants to step back a bit from web specific noise to pick up a copy.

Posted by Bill de hOra at

Phat Data

Data trumps processing For the last few years, I’ve been hearing that multicore will change everything. Everything. The programming world will be turned on its head because we can’t piggy back on faster chipsets. The hardware guys have called time......

Excerpt from Bill de hÓra at

Would Scala fall into the ErLang/OTP category?

Perhaps.  Not knowing enough about the Scala, my fear is that it is just a language, i.e. without all the accoutrements.  Mnesia looks really cool, Erlang may simply be an enabler.

Some of design choices made in Google’s architecture make sense for their problem space (e.g.  “Moving Computation is Cheaper than Moving Data") but totally crap all over everything we’ve ever learned about decoupling services and isolation.

What Bill said.  I remember when REST seemed like total crap (at least to me).  And I wouldn’t call Google’s internal architecture RESTful.  Nor would I call Mnesia RESTful.

Oh, and Bill’s latest post is well worth a read.

P.S.  I corrected Dare’s errant signature line.  And since this weblog is totally Unicode enabled, Bill, you might consider spelling your name correctly here.  :-)

Posted by Sam Ruby at

Not So Far Off Bets

Sam Ruby’s “long bets” don’t seem so far off considering how quickly changes are happening on the internets.... So, without further ado, here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as...

Excerpt from Making it stick. at

Some Thoughts on Hadoop

... [more]

Trackback from Dare Obasanjo aka Carnage4Life

at

Prognostication

It seems to be in the air. Sam Ruby plants a stake in the ground , and isn’t too shy to point at his track record . My turn....

Excerpt from ongoing at

Gack, I typed a long response and seem to have closed the tab before doing the OpenId thing. Bit more concise this time...

“I believe that the query of the future has to be a bit anticipatory” - I agree. Triplestores (including RDF/XML documents) are caches of chunks of the Semantic Web.

As far as I’m aware, there is no obvious mapping between Map/Reduce or Mnesia and the resource-oriented structure of the Web. Of the Web or on the Web?

When using Google I often find that the immediate results aren’t what I’m after, I have to follow links manually (or run a fresh query). With a system where dereferenceable resources are exposed (i.e. as URIs in RDF), this “follow your nose” activity stands a better chance of being automatable.

One approach in this space (which I’ve in the process of doing a proper write-up on) is to use message-oriented agents which can, if both ends of the wire have the capability, use dedicated low-level comms for perrformance. But if the agents have a resource-oriented (REST+RDF) baseline comms facility, they will still have an interface compatible with the rest of the Web. Something like: slow things should be easy; fast things should be possible.

(btw, I ordered a copy of the Erlang book just the other day ;-)

Posted by Danny at

Sam Ruby's Long Bets

An interesting posting from Sam here. He asserts, for next gen web architectures, the following are the long terms bets (with my commentary, in italics): REST (yes) Hadoop (yes. Map/Reduce (which to my biased database eyes is just group by......

Excerpt from Anant Jhingran's Musings at

Long Bets: Where are we going in the next 5 years?

[link] [more]...

Excerpt from reddit.com: programming - newest submissions at

Long Bets Apologia

My Long Bets post attracted some interesting reactions.  A number of supporters of various items in my list, as well as a few pushbacks.  There’s not much to say about the former, except thanks for the validation.... [more]

Trackback from Sam Ruby

at

Bye bye vacations

I’m back from vacations. I was in Gaspésie, a wonderful region of the Québec province in Canada, with my family. We had a really great time. But it’s over. Now back to work! I noticed that Erlang is getting more and more attention . Even Sam Ruby is...

Excerpt from (The Scheme Way) at

Sam Ruby: Long Bets

[link]...

Excerpt from del.icio.us/tag/insightful at

Fantasy IT

Sam and Tim are peering into the future to place their bets on what technologies will be hot. It’s like Fantasy Baseball for the Insanely Geeky. So… what the hell, here are mine: I rarely get excited about any specific technologies; when I do, it’s...

Excerpt from snellspace.com at

REST as a long bet?

I have to say, I’m with James in his response to Sam’s long bets; To say, as Sam and Tim both do, that REST is important is like saying the fan in my laptop is “important”. There’s really nothing to discuss about it. RESTful services are...

Excerpt from Web Things, by Mark Baker at

The Next Big Thing in Tech

Two of my favorite bloggers select technologies to keep an eye on for the future. Sam Ruby REST Hadoop Erlang/OTP Jabber Microformats Tim Bray Green infrastructure The Atom Protocol, and REST Ruby and Python AJAX Jabber Ubiquitous functional...

Excerpt from Jason Delport's Mobile Observations at

Concurrency trends

Sam Ruby has a post up about his long bets and Tim Bray replied with comments and his own set of prognostications. Tim’s comments around concurrency trends (particularly with respect to Erlang and Hadoop) were interesting as I think there is...

Excerpt from Pure Danger Tech at

PS. Paul Gearon [link] is looking at using Hadoop to build a massively-scalable triplestore (mentioned near the end of this podcast [link] ).

Posted by Danny at

establishing an agile platform

found some interesting posts today on the notion of “standardizing an agile platform.” jerry cuomo and sam ruby have some pithy comments about the following set of tools: Scripting based programming methodology Constrained around simple web...

Excerpt from mca blog at

what do you reckon

Sam Ruby’s “long bets”...

Excerpt from marsha knows at

Servlets+JSP design answers

Earlier I asked: “I’m wondering how would one produce a URL space for a blog style archive, using Servlets+JSP, and do so in a way that isn’t a CGI/RPC explicit call?” I got some answers, all good: Sam Ruby: "Perhaps......

Excerpt from Bill de hÓra at

Cheap Bets

We complain when we see valentine’s chocolates in January, halloween costumes in September and Christmas stuff mid-November, yet here we are already making bets on the next year or future early August. I usually skip the five songs, five things...

Excerpt from Elias Torres at

Erlang on IBM blogs

I was checking up on Anant Jhingran’s blog and noted that he mentioned Erlang so going back up to the top realized that he was discussing a post from Sam Ruby . Sam is discussing a set of “long bets” although some seem pretty short bets to me. It...

Excerpt from Simon Johnston at

Sam Ruby: Long Bets

[link]...

Excerpt from del.icio.us/zvizvi/tikal-blog at

Erlang/OTP, Mnesia

1. Download [Erlang][erlang] 2. Setup [TextMate][textmate] with a [bundle for Erlang][erlang-bundle] 3. Read the [white paper][whitepaper] and the [book][programming-erlang] 4. Understand what [the]([link])...

Excerpt from Jeff Mesnil's Weblog at

The future is messaging

Sam Ruby and Tim Bray have each picked messaging systems as a trend to watch in the future. In particular, they are naming Jabber/XMPP as something to watch. While I think XMPP is a great way to connect people to systems or other people, I think...

Excerpt from saladwithsteve at

Peter Saint-Andre: Betting Long

Sam Ruby includes Jabber in his recent long bets for the five technologies that will be especially influential over the next five to ten years. Tim Bray concurs . Sam further explains : Jabber I didn’t get much pushback here, but I’m finding that...

Excerpt from Planet Jabber at

Rates of decay: XMPP Push, HTTP Pull

Mike Herrick: "Clearly Atom can’t replace ALL pub/sub use cases, but for every day integration architecture where you want business events / EDA why can’t we use Atom feeds? In an extreme case, you might have an event sink......

Excerpt from Bill de hÓra at

Jabber Technology, Here To Stay

Chesspark.com is built on a Jabber platform, fyi. Sam Ruby includes Jabber in his recent long bets for the five technologies that will be especially influential over the next five to ten years. Tim Bray concurs. From https://stpeter.im/?p=2030...

Excerpt from Chesspark.com at

9 Links for 8/26/07

The professional architect, Part 2: Overcoming professional challenges in data architectureAgileEvents - A group calendar for posting/finding Agile-related events.GPASS: A generalized publish and subscribe solution using WS-Notification...

Excerpt from Architect's Linkblog at

Recent Code and the Culture of Code Links for Sept 5th

Accordion Magic Will has taken stickman’s accordion and added the ability to close panels, and code to keep contents hidden while page loads. Outstanding!!! Common Prototype mistakes and how to avoid them : Here’s another list of things that...

Excerpt from False Positives at

Blogosphäre (aus JavaSPEKTRUM 05/07)

Mashups als EAI 2.0, Atom, REST, Hadoop, Jabber und Erlang/OTP — dieses Mal wagen wir mit der Blogosphäre einen Blick in die Kristallkugel. Sam Ruby zeigt, wie man auch ohne XML und SOAP elegant “Web Services” bauen kann. Der...

Excerpt from JavaSPEKTRUM Blogosphäre at

Sam Ruby occasionally does an article about his long bets and I really respect his ability to predict the future. This time I feel that he was focusing too close and forgot the long part of the ‘long bet’. REST is already important, and...

Excerpt from The Burlap Sack at

Sam Ruby - Long Bets : “Here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field. REST Hadoop Erlang/OTP Jabber Microformats ”...

Excerpt from Tim's Weblog at

Currently I am adding APP support to JSR 279.
APP is as restful as it can be and has everything needed
and nothing more, a perfect fit to be promoted
also in a mobile world.

I also see a value in having a formal description of a service(such as a WSDL). APP defines a specific service document that provides means for service discovery, that is categories.

Anyhow, I’d like to see something more to aid automatic service discovery, so that e.g. geographic location and the special keywords to find the service. It might be that agreed vocabularies, e.g. dc:author and using agreed extensions, e.g. georss, are enough. But these are details I see only while using the service (AFAIK) and not in service discovery phase.

In the book “RESTful Web Services” there were two approaches illustrated:
1.) platonic URI + metadata in HTTP headers
2.) URI with structure and predictability
The latter was recommended practice to ease the nesting the services and not to be dependant on various ways HTTP headers are treated. Having all the meaning in the URI does not expose semantics to get lost in transition.

Adding semantics to URI is not easy. You are not that free to express yourself within the max length of URI and prevented from using reserved chars. The beginning of the string - domain name and path are system specific, and there are static parts you are not able to influence. Having a long query string with different key-value pairs does not sound so restful.

So, my question is, are there any more means to do yet smarter service discovery of APP services?

- Pia Niemela

Posted by Pia Niemela at

are there any more means to do yet smarter service discovery of APP services?

Per section 6.2, “Foreign markup can be used anywhere within a Category or Service Document unless it is explicitly forbidden”.  JSR 279 could therefore either define, or point to, a standard Atom Publishing Protocol extension for discovering the information required to interact with identity based services, discovery, and authentication.

If this is something you wish to pursue, I’d recommend joining the atom-protocol mailing list.

Posted by Sam Ruby at

Sam Ruby - Long Bets : “Here’s my long bets for the moment, with the only caveat that in some cases I pick specific implementations as exemplars of a larger field. REST Hadoop Erlang/OTP Jabber Microformats ”...

Excerpt from Tim's Weblog at

Disruptive Innovation (Worse is Better)

Erlang looks more and more like a candidate for Disruptive Innovation in the multi-core system programming area....

Excerpt from Boxes and Glue at

What's on my mind: Trends 2007

I Recently a took stock of items in the world of technology and computing that were occupying my attention. Looking at things like my feed subscription list, I attempted to boil the list to a managable few — to further capture the ideas/items, I...

Excerpt from Mindchunk at

Erlang on IBM blogs

I was checking up on Anant Jhingran’s blog and noted that he mentioned Erlang so going back up to the top realized that he was discussing a post from Sam Ruby . Sam is discussing a set of “long bets” although some seem pretty short bets to me. It...

Excerpt from Simon Johnston at

Scaling out messaging applications with Scala Actors and AMQP

We have been sandboxing various alternatives towards scaling out Java/JMS based services that we implemented for our clients quite some time back. The services that form the stack comprise of dispatchers and routers meant to handle heavy load and...

Excerpt from Ruminations of a Programmer at

Beyond REST, or Beyond XMPP? Both? The Q&A

One of the presentations I was most disappointed to miss at OSCON was Evan Henshaw-Plath and Kellan Elliott-McCrea’s talk entitled “Beyond REST? Building Data Services with XMPP PubSub.” Not because I’ve somehow given up on the REST architectural...

Excerpt from tecosystems at

Non-Newtonian Reading

if you enjoyed Kellan Elliott-McCrea and Evan Henshaw-Plath’s presentation “ Beyond REST? Building data services with XMPP ”, here’s a dose of links: Extensible Messaging and Presence Protocol - Wikipedia ActiveMQ+XMPP : ( "We have support for XMPP...

Excerpt from Bill de hOra at

Three Things That People Get Wrong About Cisco’s Jabber Acquisition

Another week, another RedMonk client acquired. This time around it was Jabber, acquired by Cisco. In doing so, they follow in the footsteps of other RedMonk Graduates like Covalent (SpringSource), IONA (Progress), MySQL (Sun), OpenedHand (Intel),...

Excerpt from tecosystems at

9 Links for 8/26/07

The professional architect, Part 2: Overcoming professional challenges in data architectureAgileEvents - A group calendar for posting/finding Agile-related events.GPASS: A generalized publish and subscribe solution using WS-Notification...

Excerpt from Architect's Linkblog at

Automatic concurrency management is the new thing, like automatic garbage collection was in the 90s

This is a great interview between Bill Venners and Rich Hickey. Hickey is the guy behind Clojure, the new JVM language that brings Lisp to the world of Java. I have so far only heard good things about Clojure. Hickey makes the argument that what is...

Excerpt from Closer To The Ideal at

Add your comment