Cull.tv is “rebooting music videos for the 21st century” according to Co-Founder Katherine de León — though for those of us old enough to remember MTV back when all the network did was play music videos, the site is a refreshing throwback to the days when you could “turn it on, leave it on.” While NewTeeVee points out that the startup isn’t alone in trying to re-engineer the music video experience, it is unique in that the site is built with Node.js.

John Hurliman, Cull’s CTO, wrote a blog post describing the basics of putting the site together, and shares how Node.js shined even in a surprising place:

[O]ne area where we are treading new ground with node.js+JavaScript is with our real-time recommender. The common wisdom is to use node in computing-light, I/O-heavy workloads. Machine learning and recommendations are often thought of as very compute-heavy, CPU-bound tasks. In reality, when your working set grows large enough and you go beyond simple collaborative filtering to making content-based decisions (requiring access to more and more data) and applying several layers of rulesets as most production ready recommenders do, you are I/O-bound again and worrying more about building a massive data pipeline than shaving off the last 10% of clock cycles.

If you’re looking for an example of a well-designed, well-implemented web application built entirely using Node.js, check it out. Of course, it’s also great if you’re just looking to check out some cool new music!

Without going into too many details, I just wanted to share the highlights I took away from the conference:

“There is a panic to go mobile”

Everybody had mobile on the brain, whether building games or social apps or enterprise-focused tools, the ubiquitous request was “can I use it on my iPhone?” Developers in the audience were split 50/50 between designing for the mobile web via HTML5 (easier for cross platform development) or natively (better performance, better UX, better user experience). It’s still too early to tell if one approach will win over the other, but one thing is for sure:  Whatever you develop, it’s going to have to have a mobile version too.

“Don’t believe everything you hear about iOS and Android”

Numbers on conversion, engagement and monetization on the two platforms were often confusing and contradictory. The velocity of growth in both platforms sometimes probably leads to lagging and stale info, which leads to FUD. If you develop mobile apps, you’re going to have to develop on both. So figure out how you can leverage development platforms that are suited to your needs and support one or both lead platforms.

“If you have 4 minutes to demo your game/app, don’t waste 3 of it on how great your team is.”

I sat in on the gaming and mobile demos, and if I took only one thing away, it was the look of boredom on the judge’s faces when presenters wasted time talking about their “bench strength” or a long winded story about why they’re doing what they’re doing. The few demos that were done well followed a simple model: 15 seconds to tell us who you are and what you do, 45 seconds on what the product is, 45 seconds why its important and how its different, 15 seconds on who uses the app and how/why, and 2 minutes showing a demo or screen shots of your application. The best “new idea” presentation I’ve ever seen wasn’t powerpoint — it was Ryan Dahl’s 5 minute live demo showing how to write a working chat app in less than 150 lines of code.

“Hiring super talent is expensive, so leverage who and what you can, especially platforms”

Everyone was talking about Peter Thiel’s “how do you hire employee #20″ and grumbling about the high cost of talent in the Bay Area. That’s okay, because the conference was also buzzing with companies developing mobile and gaming platforms that could significantly reduce the cost, skill set required and time needed to develop, launch and market new ideas. One day IBM’s Watson may learn to code – until then, I’m going to put my money on platforms that simplify, automate and accelerate mobile/games development.

After two days of intense sessions, meetings and “socializing”, Steve and I left the conference with two big takeaways.

One: Doing mobile is hard and developers really need some tools to simplify and automate a lot of the back-end components such as messaging, API integration, email, single-signon, social network integration, synchronization, GEO-location and data storage.

Two: The major cloud vendors haven’t done a good job helping mobile developers find a good home in the cloud. In 4 years, there will be more mobile screens interfacing with cloud based apps than desktop/laptop devices. There is a HUGE opportunity here.

Over the next few weeks, we are going to take some significant steps to address the shortcomings we see in the marketplace relating to mobile development and hosting. Until then, keep your RSS reader firmly pointed to www.joyeur.com.

Photo by VentureBeat’s Chris Peri.

Every Friday, our resident mathematician, Tim Eller, puts out a math challenge to the company. Kudos to @kevinykchan and @erikcorry for finding the solution to last week’s quiz!

Take a checkerboard, and from two opposite corners remove one square (e.g. upper left and lower right). Take 31 dominoes, each of which could cover exactly two squares on the checkerboard. Can you cover the (cut) checkerboard with these 31 dominoes?

Have the answer? Leave it in the comments or post a tweet with the hashtag #FridayMathFun.

Photos by David Oliva and Steve Snodgrass.

Every Friday, our resident mathematician, Tim Eller, puts out a math challenge to the company. Starting today, we’re going to open this game up to our readers too. -Mark

In the black of night, four people come to a rickety narrow bridge over a chasm. The bridge can hold at most two people at a time. They have a dim flashlight whose battery has 17 minutes of life left, and because of the perils, anybody on the bridge must be traveling with the flashlight. (So if there are two people on the bridge, they must be together with the flashlight.) Each of the four people travels at a different pace. The fastest person could cross the bridge in 1 minute, the next in 2, the third in 5, and the slowest would take 10 minutes. How can all four of them make it across the bridge safely?

Original photo by Raelene Gutierrez.

This post is one in a series discussing storage architectures in the cloud. Read Magical Block Store: When Abstractions Fail Us and On Cascading Failures and Amazon’s Elastic Block Store for more insight.

By Bryan Cantrill

One of the persistent themes of my career has been something of a love affair with understanding systems failure — I fervently believe that systems have the most to teach us when they fail. And while this interest in failure hasn’t made my own any easier to stomach, my career has been blessed with plenty of opportunity for study: For an infrastructure provider, failures can be devastating, resulting in downtime, data loss and worse. And for a cloud provider, failures are not only just as devastating, but much more potentially widespread in their impact. As such, the massive, systemic failure in Amazon’s US-EAST-1 region (and the prolonged downtime that it induced), provides an occasion to reflect on the nature of failure on the cloud. While it is true that some level of systems failure is endemic (and that systems must be designed with these failures in mind), this cannot become an excuse for unreliable systems. Failures must be understood if we are to collectively learn from them.

For Joyent, this has been an opportunity to reflect back on some of our own failures — and specifically how they changed the way we think about the cloud. You may have seen Jason on cascading failure or Mark on the perils of abstraction. I wanted to add my own perspective on Joyent’s experience with network storage.

I knew Jason and Mark (and Dave and Ben) long before I came to Joyent in August, and I remember when they were not so jaundiced about network storage: I recall having a discussion with Jason in 2006 when he excitedly talked of his plans for using block-based network storage as the bedrock of a large-scale IaaS offering. He was enthusiastic — it all seemed so elegant and fool-proof! — and as I was developing a network storage appliance at the time, so (naturally) was I. I do remember us both wondering aloud if having a copy-on-write filesystem backed by a LUN that was in fact a remote copy-on-write filesystem was going to have new performance pathologies, but like doomed hikers ignoring a distant storm cloud, we collectively shrugged our shoulders and we each pushed on down our respective paths…

Five years later, we’re all older and wiser — and we each independently learned some very tough lessons about the peril of network storage in a multi-tenant environment. Jason summarized that lesson euphemistically:

While there are many strengths to network storage: Failure modes, particularly in a multi-tenant environment of unknown workloads, is not one of them.

Anyone who has stood anything up in this business knows that Jason’s admonishment practically drips with the cold sweat of a production nightmare; Mark provides additional detail:

After nearly 9 months of trying to make it work we decided to begin the engineering effort to re-work our provisioning architecture, server characteristics, and so on to be able to reliably support persistent data pools on the servers themselves while keeping as many of the features [...] as we could

For me personally, however, the lesson came not from trying to operate a cloud, but rather as one of the enterprise vendors that Mark refers to: The Fishworks appliances found quite a bit of traction in the cloud storage space, and we had several customers who enthusiastically hung eye-watering numbers of their cloud customers off of a single (clustered) head.

The problem was that the scale at which these boxes were operating — tremendous amounts of data churn over many, many virtual machines — meant that any hiccup would be felt across their entire fleet. And there were plenty of hiccups, often (but not always) due to operator error or operator misunderstanding.

As a concrete example, I found myself berated by one particularly angry cloud storage customer because the box was “misreporting” several thousand writes per second when the customer “knew” that any writes were impossible — that the particular LUNs being identified were “never” written to. While I was able to prove to the customer that the writes were indeed happening (DTrace FTW), I couldn’t take it any further: The network divided the symptoms of the problem from whatever was inducing them in their cloud, making it difficult to understand who was doing it or why.

Several days later, I happened to notice that the number of writes per second had dropped precipitously; I inquired if they had discovered the root-cause, and the customer sheepishly admitted that there had been a “configuration error.” Obviously not satisfied with that answer after the tongue-lashing I had received on this issue, I pressed for details — and it was revealed that the file systems had all been mounted on the networked LUNs without “noatime” set. That is, any access to a file updated the access time — the atime — on the i-node, turning a gentle read-only workload into a fire-breathing metadata-writing monster.

Now, this is a mistake that anyone could make (certainly), but that the storage system was distributed made it unnecessarily arduous to root-cause. Further, the performance ramifications of this were significantly more acute due to the scale of the system: Because they had consolidated so many virtual machines on so few (centralized) spindles, their operations per spindle were much higher than they would have been had the storage been local. And need I remind: These are disks that we’re talking about here. They are still operating under the same principle as the IBM RAMAC circa 1956 — and their seek times are still counted in the same time units! They do not like having load poured on them, and they punish such demands with queueing delays and non-linear latency. (And lest you feel like venting your frustration, they also don’t like being shouted at.)

This whole experience — and many others like it — left me questioning the value of network storage for cloud computing. Yes, having centralized storage allowed for certain things — one could “magically” migrate a load from one compute node to another, for example — but it seemed to me that these benefits were more than negated by the concentration of load and risk in a single unit (even one that is putatively highly available).

When I began to talk to Joyent, I was relieved to hear that their experiences so closely mirrored mine — and they had made the decision to abandon the fantasia of network storage for local data (root file systems, databases, etc.), pushing that data instead back to the local spindles and focussing on making it reliable and available. Yes, this design decision was (and remains) a trade-off — when local data is local, compute nodes are no longer stateless — and Joyent has needed to invest in technologies to allow for replication, migration and backup between nodes.

But in the end, the loss of functionality has been more than made up for by the gain in resiliency. Now when we have I/O performance problems (and, let’s be honest, where there’s I/O there are I/O performance problems), we know that the failure is contained to a single node and a bounded number of tenants — and we have rich tooling to diagnose the root-cause (which is often up-stack).

Moreover, by keeping local I/O local, we have all of the necessary context to make decisions around I/O scheduling to assure Quality of Service — which has enabled us to take a swing at multi-tenant I/O throttling. This is not to say that network storage doesn’t have its uses of course — but frankly, serving up virtual devices to a cloud just isn’t one of them: When local storage is consolidated, risk is consolidated along with it, and component failure is more likely to balloon into systemic failure.

More generally, network storage embodies a key design issue in architecting and operating a cloud: The tension between economies of scale and overconsolidation of risk. The challenge of the cloud is delivering enough of the former to be viable without so much of the latter as to be deadly. We at Joyent have learned much of this the hard way, and we reflect that wisdom not only in the way we operate our public cloud, but also in our SmartDataCenter offering. We will no doubt continue to learn ways in which we may better strike that balance, but we take solace in all that we have already learned — and hope that future education need not be forged in the kiln of unspeakable pain!

Visit http://www.joyentcloud.com/ to learn about how Joyent’s public cloud, Joyent Cloud, is different from Amazon’s AWS.

Photo by Michael Zimmer.

This post is one in a series discussing storage architectures in the cloud. Read Network Storage in the Cloud: Delicious but Deadly and On Cascading Failures and Amazon’s Elastic Block Store for more insight.

Like anyone who has anything to do with the business of running applications attached to the Internet, I can’t help but feel uneasy and stressed when an outage as severe and impacting as the one Amazon Elastic Block Store has just experienced happens. The fact that Amazon is a competitor doesn’t matter. It just sucks for everyone. This post, however, isn’t about EBS. Not really. It’s about abstractions. In particular, the abstraction of “the disk.”

Abstraction levels are something that have fascinated me for my entire career. We (developers, operators, the whole lot of us) heavily depend on multiple abstraction layers in our respective stacks simply because the technology we’re putting into play is so incredibly complex that there’s no way we could progress without the ability to hide details.

The trick, of course, is getting the abstraction right. It has to be understandable, observable, and predictable. A fantastic implementation is worthless if the abstraction is wrong. Change the behaviour of the abstraction you’re implementing too much, and the abstraction becomes worthless. You can tell where I’m going with this – questioning whether or not the abstraction of a reliable, super cheap, performant network attached block storage device is viable.

Certainly there’s a lot of players in this space with a lot of skin in the game who want us to believe it is. I’m not talking about just Amazon – the top 5 storage vendors of EMC, HP, IBM, NetApp, and Dell shipped 3397 petabytes of the stuff last quarter.

Reality Check

There’s a phrase about abstractions (I honestly don’t know if it was myself or someone else who coined it) that I remind our engineering staff about on a regular basis. It goes something like this:

We need our abstractions, our black boxes. Black boxes are great and enabling when they work. But when something goes wrong, the walls of our abstractions need to go transparent as fast as possible.

There’s a reason we so fanatically drive at this goal at Joyent, and it’s not because we’re smarter or better than anyone else. It’s because we’ve been burned by invalid abstractions of our own doing so many times that we’ve programmed a Jabber bot to constantly berate us with reminders of how our hubris around abstractions led us to failure.

We still get it wrong, often. The most recent example that comes to mind wasn’t a storage product, but our Smart Platform. A pure Javascript Platform as a Service. For me at least, it was the proof point that server side JS was going to have a big role in the future of web and mobile applications. Yet, even though this was James’s (the lead architect and engineer) third time building a developer-focused application platform, and even though we wanted the platform to have far less magic than, say, Google App Engine, we still strayed too far down the magic path and pushed the abstraction level too high.

The object store and multi-tenant message routing architecture resulted in a body of code and interfaces that (it was open source from day one) nobody but us could really understand well enough to contribute to. Or debug it. In fact, the object store itself tripped us up so many times dogfooding the platform that we finally shook free of its hold and reevaluated our approach. The implementation had issues, but the real culprit was the set of abstractions that Smart Platform presented.

Today we’re the driving force behind NodeJS, which sits on a very different place on the abstraction curve than Smart did. We’ve pulled lots of ideas and lessons from Smart into our hosted NodeJS offering, no.de, but we did drop as much of the magic as possible. The end result is a service that’s tremendously simpler and in many ways less feature rich, but it doesn’t make promises we can’t fulfill and our customers can understand it.

In fact, when something goes wrong they can log right in with a shell and see exactly exactly what’s going on. We’ve paired the transparency with ground-breaking observability tools. NodeJS and no.de are huge successes, largely, I think, because we walked the fine line of abstraction level better this time. It’s only a black box when you want it to be. When you need to look inside, you can. You can evaluate the risk level of the technology and approach yourself.

Magical Thinking

The promise of network block storage is wonderful: Take a familiar abstraction (the disk), sprinkle on some magic cloud pixie dust so that it’s completely reliable, available over the same cheap network you’re using for app traffic, map it to any instance in a datacenter regardless of network topology, make it so cheap it’s practically free, and voila, we can have our cake and eat it too! It’s the holy grail many a storage vendor, most of whom with decades experience in storage systems and engineering teams thousands strong have chased for a long, long time. The disk that never dies. The disk that’s not a disk.

The reality, however, is that the disk has never been a great abstraction, and the long history of crappy implementations has meant that many behavioral workarounds have found their way far up the stack. The best case scenario is that a disk device breaks and it’s immediately catastrophic taking your entire operating system with it. Failure modes go downhill from there. Networks have their own set of special failure modes too. When you combine the two, and that disk you depend on is sitting on the far side of the network from where your operating system is, you get a combinatorial explosion of complexity.

To make matters far worse, you can’t easily flip the switch and make the walls of this Magic Block Store go transparent so you can see what’s happening under the covers. EBS is no different than the big storage vendors in this regard — neither Amazon nor EMC seem to want us to know what goes on inside their abstraction.

I certainly don’t claim to know how EBS works, but of course people go to bars and have beers and talk. It’s commonly believed that EBS is built on DRBD with a dose of S3-derived replication logic. As a former boss of mine so demeaningly stated to me once, in grown-up land when your cheap home grown DRBD solution falls over and loses all your data you open up your check book and pay EMC or NetApp to do the job right. Maybe Amazon is different. Maybe they did what a dozen billion dollar companies before them tried to do and never pulled off. Or maybe EBS is indeed bandaids and chicken wire. I have no idea. Which is a problem, as a user of EBS.

Back to the abstraction instead of the implementation. Do we need block devices in the cloud? If we’re just asking too much of this ancient abstraction, as I believe we are, can we as developers and operators stop demanding the vendors make these Magic Block Store solutions? We certainly fear having to evolve our trusted abstractions, and the disk is about as old of an abstraction as we’ve got.

All is not lost, however. In my experience, it isn’t that we need “disks”, it’s that our apps need POSIX’s read() and write() and friends combined with behaviour that roughly approximates a physical disk. For the times we actually need a block interface vs. filesystem semantics, I would argue, the abstraction sitting on top (the filesystem, usually) is even more sensitive to the behaviour of the disk device than a POSIX application like a database is.

My opinion is that the only reason the big enterprise storage vendors have gotten away with network block storage for the last decade is that they can afford to over-engineer the hell out of them and have the luxury of running enterprise workloads, which is a code phrase for “consolidated idle workloads.” When the going gets tough in enterprise storage systems, you do capacity planning and make sure your hot apps are on dedicated spindles, controllers, and network ports.

It was fantasy believing it was possible to pull off a centralized network block storage service in a multi-tenant cloud without any of the architecture shenanigans our enterprise brethren do and think that applications, databases, and business could depend on its being perfect. Honestly, we should have know better. We the applications developers asked what is perhaps the crappiest of all abstractions in computers to solve all of our availability problems for us. We asked for magic. Clearly, the vendor never should have made the promise of magic, but everyone is to blame for this continued expectation that such magic is possible.

A Different Approach

At Joyent, when VMware and Amazon were preaching centralized network block storage as the salvation, we tacked the other way, for reasons I’ll explain below. (Hint: We tried and failed.) We simply provide a POSIX filesystem interface to storage, which happens to be sitting on local, not network, block devices. We lean on ZFS for durability and a fighting chance when things “go byzantine.” We use fast SAS drives in RAID groups with multiple parity stripes. We don’t pretend that this “disk” can never, ever go away or survive all failure modes. What’s more important, I believe, is the set of technologies we put in place so that our customers can transparently see exactly how our filesystems are holding up.

As an example, we provide tools and scripts that show you a distribution of how much latency your MySQL database is seeing from the abstraction directly beneath it, the filesystem.

You can run it yourself from the command line, the output looks like this:


# ./mysqld_pid_fslatency.d -p `pgrep mysqld`
Tracing PID 7357... Hit Ctrl-C to end.
^C
MySQL filesystem I/O: 21329; latency (ns):

read
value ————- Distribution ————- count
1024 | 0
2048 |@@@@@@@@@@@@ 3837
4096 |@@@@@@@@@@@@@@@ 4998
8192 |@@@@@@@@@@@ 3540
16384 |@@ 745
32768 | 95
65536 | 19
131072 | 3
262144 | 0
524288 | 0
1048576 | 1
2097152 | 1
4194304 | 0

write
value ————- Distribution ————- count
4096 | 0
8192 |@@@@@@@@@ 1902
16384 |@@@@@@@@@@@@@@@@@@@@@@@@@@ 5181
32768 |@@@@ 798
65536 |@ 184
131072 | 9
262144 | 1
524288 | 6
1048576 | 0
2097152 | 0
4194304 | 7
8388608 | 2
16777216 | 0

Or you can use our visualizations:

Either way, it’s pretty awesome. Being able to confirm your DB is seeing thousands of cache hits with microsecond latency and only a few disk hits in the 1-10ms range is the kind of insight that lets DBAs sleep at night. You can also easily ask and receive an answer to a question like “how many of my slow queries are because of filesystem/disk latency vs. a missing index?” Trying to use a tool like iostat against a shared, network provided block device to figure out what your level of service your database is getting from the filesystem below it is an exercise in frustration that will get you nowhere.

For Joyent, keeping the network out of the storage solution and safely persisting those filesystems across reboots on the servers added some complexity to our provisioning. We don’t have the luxury of treating local disk as ephermeral when selecting nodes to place workload on, for example. We lose some nice features like quick re-mounting to arbitrary vm instances, too. But it allowed us to present a usable, observable abstraction that we’re continuing to improve with innovative I/O throttling and QoS. We’re building a better building block, in our opinion. The complexity of tackling this work with an oversubscribed network in the middle would have been, in our opinion, an impossible engineering challenge.

Joyent, like always, arrived at the conclusion that we could not build a multi-tenant cloud on network block storage the hard way: We tried to build a multi-tenant cloud on network block storage. When we launched the Joyent IaaS product, it was in fact built on replicated storage nodes that presented iSCSI targets to the server hosts that then in turn implemented RAID1 mirrors of the network block devices. The hosts then carved up the LUNs into ZFS datasets which mapped to the virtual machines.

It’s worth explicitly pointing out that we had none of the flexible provisioning APIs and features that EBS currently exposes. I’m certainly not pretending we had an EBS competitor back then. But on the backend, the implementation was probably not wildly different, and the core abstraction we attached our customers virtual machines to was nearly identical. Our MBS implementation was originally built on the StorEdge Availability Suite, a product that came out of StorageTek/Sun that works very similarly to DRBD. We were never able to get it to work well enough, largely a function of us not having enough resources to pour into enhancing the base product to cope with scenarios we were seeing a lot when competing I/O from multiple hot tenants caused the replication to fall behind and never catch up. We instead invested in filers from NetApp and EqualLogic (we didn’t want all our eggs in one basket) and that bought us time to take engineering and ops resources off keeping the storage nodes running and work on other parts of our stack.

Ultimately, however, the approach suffered the same fate as the homegrown and the performance curve would degrade so badly over time that we were at times only attaching and handful of servers to a replicated filer pair. Obviously, this was not only uneconomical but unviable from a predictable performance point of view; Our customers hated the I/O experience. After nearly 9 months of trying to make it work we decided to begin the engineering effort to re-work our provisioning architecture, server characteristics, and so on to be able to reliably support persistent data pools on the servers themselves while keeping as many of the features commonly associated with MBS as we could (snapshots we have today, async replication isn’t that far off).

I still believe that it was the right decision, and as we have grown up as a company and increased our engineering capabilities we’re only now really beginning to see how liberating the decision to drop network storage out of the Joyent cloud was. I believe that applications can rise to the task and not require perfect, always on block storage, for the simple fact that they’re going to have to do it anyways to get to the goal of global deliverability and availability. We just can’t lean on the false abstraction of a perfect disk forever.

-Mark

Visit http://www.joyentcloud.com/ to learn about how Joyent’s public cloud, Joyent Cloud, is different from Amazon’s AWS.

Photo by mcbarnicle.

Everyone loves listicles — sites love to publish them because people love to click on them! Joyeur is certainly no exception. Recently, we’ve been featured in a number of lists, so here they are in order of exclusivity — along with some tips that might help you get past some editorial velvet ropes.

5. 2011 OnDemand 100 Top Private Companies
Nobody produces listicles quite like AlwaysOn, which besides including Joyent on the OnDemand Top 100 as a leader in Cloud Infrastructure is also currently working on the OnMobile 100 Top Company Competition and the AlwaysOn Global 250 Top Company Competition. So if your company hasn’t made a list yet, might be time to find Founder and Editor Tony Perkins at one of AlwaysOn’s many networking events and hand him a business card.

4. CRN: The Top 20 Cloud Infrastructure Vendors of 2011
One way to make lists is to appeal to a niche audience. CRN Technology News focuses on our industry audience — technology integrators and solution providers. We read them, and naturally they keep a close eye on us — and our competition — so it’s rewarding to be honored with a selection. 

3. O’Brien: 11 Predictions for 2011
There is absolutely nothing wrong with rampant speculation in the press, especially when it’s from the likes of Chris O’Brien from the San Jose Mercury News. He predicts that “2011 will be the year that many larger players swoop in and start buying up these racehorses,” and calls us out as a “hot name” in the business. You’ll have to be a site subscriber to see into the rest of O’Brien’s crystal ball of a column. But we certainly like the view from his perspective.

2. Top 10 Cloud Computing Providers of 2011
For the second year in a row, we’ve stayed in the top ten of SearchCloudComputing’s top list. Hey, is that Microsoft at number nine?  Check out Jo Maitland and Carl Brooks’s reasoning for the rankings on CloudCoverTV.

1. 5 Cloud Software Vendors Dell Should Buy
Last and most exclusive, Derrick Harris gives us a nod as a business fit for our friends at Dell with a handful of other companies. We certainly enjoy working with them to help provide their Dell Cloud Computing Solution. And now we know how celebrities must feel when, after working closely together on a project, suddenly the tabloids are full of gossip. All our publicist is saying for the record is that no, we are not dating Angelina Jolie or Brad Pitt. Or both Angelina and Brad Pitt. Get those cameras out of our face!

Bonus: CRN also selected us for their “$10 Million Cloud Club: 10 Well-Funded Cloud Computing Vendors” list.

So while we may not be on the guest lists at actual trendy nightclubs — we are nerds, after all — we’d much rather be with this sort of quality company in these industry VIP rooms, anyway!

Photo by Jeff Maysh.

If you’d like to subscribe, here’s the feed. Otherwise, here’s a direct link to the mp3.

This month, David was eagerly awaiting the drop of the new Lupe Fiasco joint Lasers. So the podcast kicks off with a sample of the single, “Words I Never Said,” featuring the hook voiced by Skylar Grey.

If you’d like to subscribe, here’s the feed. Otherwise, here’s a direct link to the mp3.

David’s enthusiasm for Kanye West’s My Beautiful Dark Twisted Fantasy is, apparently, indefatigable. For reference, that’s Gil Scott-Heron‘s voice you hear in Who Will Survive in America.

By Carly Guarcello

After working with hundreds of companies, including some of the largest social gaming firms, we’ve identified the top 10 essential tips to maximize your game’s success. So while you are brainstorming for the next big hit, keep these in mind.

10. Know your competition
Do your research. See what’s out there. It’s likely that your first few ideas, or something similar, have already been done. But, there is always room for a new twist. What’s important is how you differentiate your game from the rest. That is what will make it succeed.

9. Identify and set your goals
Whether you’re going for profit or for number of users, have numbers in mind to help you establish a timeline for your game’s success.

8. Pick a monetization strategy
With a monetization strategy in place you can calculate the usage required to achieve success. You will be able to maximize the return and meet the goals you have set for your game.

7. Marketability
Create a strategy and tactical plan that you can implement to promote your game and attract as many players as possible. Your plan needs to include advertising, news mentions, and a presence on one or more social networks since that is where your audience will be found. So make sure you get the word out and make your game “The Game” that users want to play.

6. Blazing speed
Your game has to have phenomenal performance and no latency. The fastest way to lose players is with a game that takes five minutes to load or freezes in the middle of an exciting moment.

5. Inviting look and feel
The game experience should be even better than described in components of your promotion plan. Keep text to a minimum. Players won’t read it because they want to play the game, not read a novel.

4. Achieve success on one platform and then, expand to others
Although you want to reach as many potential players as possible, the most successful games focus on one platform to start and then expand to others. By getting the kinks out of game logistics on one platform you will be able handle issues cost-effectively. Your focus will create a great game experience and you’ll be able to grow a loyal, rabid fan base. Expanding to additional platforms and devices should be your end goal.

3. Provide great player rewards
Your game has to be rewarding in some way. Rewards can be emotional, social, or financial. The rewards have to compel gamers to keep playing. Be sure to monitor key metrics including duration and frequency of play. Understanding these metrics will help you keep engagement and retention rates high.

2. Cultivate all players
Successful games welcome new players as well as nurture existing players. Social media platforms should play a large role in player cultivation. The most successful games have consistent player engagement both in the game and in discussions about the game.

And the number one success tip…

1. Keep the space between your ears open
After you release your game, listen to the feedback from players. Not only will you get some great ideas for enhancements, but you’ll grow player loyalty.

Photo by Flickr user terren in Virginia.