Thursday, March 31, 2011

The MySpace decline and Microsoft

8 Lessons We Can Learn from the MySpace Incident - Balance, Vision, Fearlessness

I like to read http://highscalability.com/ and this is one set of articles I wanted to comment one. This article is a summary of a lot of reader comments. There are links at the bottom of this article that refer to the original articles.

One of the questions posed is "Did the Microsoft software stack kill MySpace?" The consensus seems to be no. A number of people brought up examples a high-traffic sites running a Microsoft stack. Curiously, all of the examples were Microsoft sites.

I'd agree with most people that it was the business culture that killed the popularity of the site. Specifically the lack of innovation that was driven by technical problems along with an outsourced infrastructure. It seems that MySpace really did not have a technical or innovation driven culture and that really hurt.

My comment about the Microsoft stack is that all of the well-known, high-traffic sites that I'm aware of really own their stack and make it do what they want despite the difficulties. Whatever stack you choose can completely own you. You buy into all of it's strengths and weaknesses. If your stack is not flexible enough or does not have the features you need, then you are either stuck or you need to go outside of that stack to get what you need. Some MySpace outsourced their stack to Microsoft to run, I think that really limited what MySpace could do. However, I think for this case, Microsoft is probably more of a savior than a hindrance. Unfortunately for big M$, MySpace is a lot of bad news and they are directly attached to it.

The point I really wanted to bring out as for as the NoSql world is concerned, is that Microsoft really is not a player here. Most NoSql data stores run very specifically on Linux/Unix platforms and do not target windows. Even Hadoop with it's huge ecosystem only runs on Windows with cygwin and then only for development, not production.

MySpace appears to be running everything MS Sql server which would make sense being a M$ stack. Google, Facebook, Twitter and others run multiple data stores depending on their needs. While you could set up any sql database to manage relationships between users. However, if you want to figure out the intersection between 2 users groups of friends, you want to use a graph database because it is designed to model relationships very efficiently.

My question is that is this a problem for M$ if they are not part of this space? There are only very few large sites that known to run a M$ stack. Most of the NoSql space is simply on in the M$ corner. Is NoSql a big enough space for M$ to even pay attention too?

My opinion is that it will be a problem. Some of this software is going to be ported to and strongly support on Windows. The mind share is still strongly elsewhere and where those leaders go, the rest will follow. Many companies are just becoming aware of this space and are intrigued by how this software can impact their business.

It will be incredibly interesting to see how all of this plays out so stay tuned ...

Monday, March 28, 2011

UUID key generation

Many times when you're inserting data into a NoSql style data store, you need to provide your own keys. There are several ways this can be done in Java.

Java 5 has java.util.UUID http://download.oracle.com/javase/1.5.0/docs/api/java/util/UUID.html
  • http://jug.safehaus.org/ seems to be popular and is what I’m using. You need to provide the hardware ethernet address on your own for type 1 UUIDs.
  • http://johannburkard.de/software/uuid/ seems like an interesting alternative as well. It uses some OS specific utilities to obtain the hardware ethernet address for use in the UUID.
UUID generation is pretty straight forward. These examples are for  JUG.

private UUIDGenerator uuidGen = UUIDGenerator.getInstance();
// Generate a type 1 UUID without a network interface reference.
String myUuid1 = uuidGen.generateTimeBasedUUID().toString();


That’s all that is needed to get your UUID to use as a key in your data store.
Next post we’ll look at using JDK 6 to get the network address to use along with the type 1 UUID.