Parallelism On The Cloud And Polygot Programmers

I am very passionate about the idea of giving developers the control over parallelism without them having to deal with the underlying execution semantics of their code.

The programming languages and the constructs, today, are designed to provide abstraction, but they are not designed to estimate the computational complexity and dependencies. The frameworks such as MapReduce is designed not to have any dependencies between the computing units, but that's not true for the majority of the code. It is also not trivial to rewrite existing code to leverage parallelism. As, with the cloud, when the parallel computing continues to be a norm rather than an exception, the current programs are not going to run any faster. In fact, they will be relatively slower compared to other programs that would leverage parallel computation. Robert Harper, a Professor of Computer Science at Carnegie Mellon University recently wrote an excellent blog post - parallelism is not concurrency. I would encourage you to spend a few minutes to read that. I have quoted a couple of excerpts from that post.

"what is needed is a language-based model of computation in which we assign costs to the steps of the program we actually write, not the one it (allegedly) compiles into. Moreover, in the parallel setting we wish to think in terms of dependencies among computations, rather than the exact order in which they are to be executed. This allows us to factor out the properties of the target platform, such as the number, p, of processing units available, and instead write the program in an intrinsically parallel manner, and let the compiler and run-time system (that is, the semantics of the language) sort out how to schedule it onto a parallel fabric."

The post argues that language-based optimization is far better than machine-based optimization. There's an argument that the machine knows better than a developer what runs faster and what the code depends upon. This is why, for relational databases, the SQL optimizers have moved from rule-based to cost-based. The developers used to write rules inside a SQL statement to instruct the optimizer, but now the developers focus on writing a good SQL query and an optimizer picks a plan to execute the query based on the cost of various alternatives. This machine-based optimization argument quickly falls apart when you want to introduce language-based parallelism that can be specified by a developer in a scale-out situations where it's not a good idea to depend on a machine-based optimization. The cloud is designed based on this very principle. It doesn't optimize things for you, but it has native support for you to introduce deterministic parallelism through functional programming.

"Just as abstract languages allow us to think in terms of data structures such as trees or lists as forms of value and not bother about how to “schedule” the data structure into a sequence of words in memory, so a parallel language should allow us to think in terms of the dependencies among the phases of a large computation and not bother about how to schedule the workload onto processors. Storage management is to abstract values as scheduling is to deterministic parallelism."

As far as the cloud computing goes, we're barely scratching the surface of what's possible. It's absolutely absurd to assume that the polygot programmers will stick to one programming model and learn to spot difference between parallelism and concurrency. The language constructs, annotations, and runtime need to evolve to help the programmers automate most of these tasks to write cloud-native code. These will also be the core tenants of any new programming languages and frameworks. There's also a significant opportunity to move the existing legacy code in the cloud if people can figure out a way to break it down for computational purposes without changing it i.e. using annotations, aspects etc. The next step would be to simplify the design-deploy-maintain life cycle on the cloud. If you're reading this, it's a multi-billion dollars opportunity. Imagine, if you could turn your implementation-specific concurrent access to resources into abstract deterministic parallelism, you can indeed leverage the scale-out properties of cloud fairly easily since that's the guiding principle behind the cloud.

There are other examples you would see where people are moving away from an implementation-centric approach to an abstraction that is closer to the developers and end users. The most important shift that I have seen is from files to documents. People want to work on documents; files are just an instantiation of how things are done. Google Docs and iPad are great examples that are document-centric and not file-centric.

Photo courtesy: bass_nroll on Flickr

Plotting for serendipity

I rarely eat lunch at my desk. Eating lunch in a cafeteria is such a precious opportunity to waste. I plot for serendipity. That's right. Some of the best conversations that I have had with people — on my way to a cafetaria or in the cafeteria — are purely serendipitous, but they're not purely accidental. I even pick a cafeteria that requires me to walk a little more. I believe you can always create opportunities for good things to happen to you. When people say "It's a small world", they are so wrong. The world isn't small but they're at the right place at the right time to think it's a coincidence. The coincidences do happen but there's a larger force behind orchestrating the possibilities for such coincidences to occur.

The same applies to creativity. You can design an epiphany.

I have heard people say that they had an epiphany while they were in shower. It's not the shower but it's illumination followed by a prolonged incubation, two phases of creativity. The other two phases are preparation and verification. Preparation is a phase where you decide that you want to solve a specific problem. When you continue to work on a problem over a period of time, your brain, the unconscious, never stops working on it even if consciously you're not spending any time on it. This is called incubation. This lasts for a while. The "shower moment" is the illumination phase where you finally figured out a solution, after your brain unconsciously kept solving it for the entire night, and hence the metaphor of glowing bulb for innovation. What remains is the verification phase to prove that the solution works. We all do this, but we don't spend enough time on the incubation phase and hence many ideas don't go beyond that. You can plot for this epiphany by not letting a problem go for a while even though you think that you don't have enough time to work on it. I tell my students to start working on their projects early on for better results for that purpose. It feels counterintuitive that you could solve a problem by spending less time on it as long as you keep solving it for a longer duration off and on.

I have blogged about cloud being a natural platform to design tools that could create network effects. The tools that create network effects also offer an opportunity for digital serendipity. I have discovered many people through Twitter and learned quite a few things that I would have never explicitly made an attempt to learn. And, I'm not the only one who has had such an experience. I'm a big fan of social tools and platforms that enable opportunities for such serendipity to occur. There're only so many cafes and water fountains in the physical world; the digital world is far bigger in that sense.

Design your routine to plot for serendipity and epiphany and credit yourself instead of the shower. Creativity can be tricked. You will be positively surprised.

Cross-posted on my personal blog

Designing Terms Of Service Is As Important As Designing A Product

Dropbox revised their Terms of Service (TOS) over the long weekend. That triggered a flurry of activities on Twitter. Dave Winer even deleted his Dropbox account saying that he would revisit it once the dust settles. A lot of people concluded that there's nothing wrong in the new TOS and that people are simply overreacting. And then Dropbox updated their blog post, twice, explaining that there is nothing wrong with new TOS and cleared some confusion. I would let you be the judge of the situation and the new TOS. This post is not about analyzing the new TOS of Dropbox, but it's about looking at more basic issue in product design. What we witnessed was just a symptom.

Let me be very clear - your product design includes getting the TOS and End User License Agreement (EULA) right before you open up the service. The way the most TOS and EULA are worded, an average user can't even fathom what the service actually does, what information it collects, what it shares, and most importantly what's that it absolutely won't do. It's ironic that the simplicity element of Dropbox's design — there will be a folder and that will sync — made it extremely popular and when they designed the TOS, they had to publish a blog post with two updates and 3000+ comments to explain and clarify the new TOS to the very same users. There's something wrong here.

For a product or a service to have a great experiential design, it's absolutely important to get the TOS and EULA right upfront and even validated by end users. People release their product in beta and go to a great length to conduct usability study to improve the product design. Why exclude TOS?

I have worked with some great lawyers, but they don't make a good product designer. I'm a big fan of constraints-based design. Lawyers are great at giving you constraints - the things that you can and cannot do. Start there. Get a clear understanding of legal ramifications, ask someone other than a lawyer to write a TOS, get it signed off by a lawyer, and most importantly validate by end users. Then, start the product design using those constraints. If you feel too constrained, go back and iterate on TOS. Drafting a TOS is not different than prototyping a product.

I would rather have bloggers, thought leaders, and end users critique the product design on my blog instead of TOS. I would love to work on that feedback as against getting into a reactive mode to stop the bad PR and legal consequences. Thomas Otter says "law exists for a reason." Don't exclude lawyers but please don't let lawyers drive your business. Educate them on technology and end users and most importantly, involve them early on. The lawyers are paid to be risk-averse. As an entrepreneur, you need to do the right thing and challenge the status quo to innovate without jeopardizing the end users. It's a tough job, but it can be accomplished.

I don't want to single out Dropbox. There are other companies who have gone through the same cycle and yet I don't see entrepreneurs doing things differently. In this process, the cloud gets a bad rep. What happened to Dropbox has got nothing to do with what people should and should not do in the cloud. That would be a knee-jerk response. The fundamental issue is a different one. Treating symptoms won't fix the underlying chronic issue.

5 Techniques To Deal With Spam: Open Letter To Twitter

I love Twitter, but lately, I am getting annoyed by Twitter spam and I'm not the only one. I don't want Twitter spam to become email spam. I don't want to whine about that either, so I spent some time thinking about what Twitter could do to deal with spam. Consider this an open letter to Twitter.

Facebook's privacy settings are the new programming a VCR. Google has been criticized a lot about profiting from content farms. I believe that all the major players are playing a catch-up game. A lot of people have stared to complain about LinkedIn spam as well. Quora went into different direction — where they started out with a strict upfront policy regarding who can join Quora, ask questions, answer questions etc. — to maintain the quality of their service. Strict upfront policy hampers new user acquisition and adoption but could ensure better quality where as liberal policy accelerates the user acquisition with a risk of service being abused. I do believe that there's a middle ground that these services could thrive for by implementing clever policies.

Here are five techniques that Twitter could use to deal with spam:

1. Rely on weighted rank based on past performance: I ran a highly unscientific experiment. I kept a record of all the accounts that I reported as spammers on Twitter in the last few days. I went back every few minutes, after reporting an account, to see whether that account was suspended. It took Twitter some time before that happened. Every single account that I have reported so far has been suspended. I don't think Twitter is using that knowledge. If it did, my subsequent actions would have resulted into quicker suspension. Learn from Craigslist. Craig Newmark will tell you all about community-based flagging. Instrument the system to rely on reputation of power users — who are savvy enough to detect spam — to suspend a spammer's account. If it turns out that it's not a spam, give an opportunity to the account owner to appeal. Spammers don't waste time arguing; they simply move on.

2. Expand categories to match how people consume: Create a separate "unsolicited" category to receive mentions and replies from people whom you don't follow. This could be a separate window in a Twitter client that replaces the current "replies and mentions" window. Require Captcha for direct replies (and not mentions) for the conversations where both the accounts don't follow each other to stop automated spam. Everything else, including real spam, goes into "mentions", which is now a new category, that can be consumed in a separate window leaving the "replies" window clean.

3. Remove spam tweets from the stream: Many users don't consume their mentions or replies in real-time or even in near real-time. Mark the tweets spam once you suspend the account and require the Twitter clients to remove them from users' stream in real time. No API restrictions and no throttling. If you do it right and spam gets detected within a few seconds, the account can be suspended in no time, and the tweets are removed even before the most users would even see them. Emails can't be recalled, the tweets can be, if Twitter wants it to. Let's do it.

4. Focus on new accounts: Set a reasonably low limit on number of tweets per hour on a new account. A first-time genuine Twitter user doesn't go from 0-100 in a day, but a new spammer certainly would. Focus energy on new accounts; spammers don't wait for a few weeks or months to start spamming. The current "verified" account feature is a black magic. Open it up to all the people and use standard means such as cell phone, credit cards, and other identities to verify their Twitter accounts. These accounts enjoy the benefit of doubt - an upfront requirement of multiple signals before their accounts are suspended. Spammers don't want to verify themselves.

5. Find and fight bots with bots: There are a bunch of bots out there that look for the words such as iPad, iPhone, and XBOX in your tweets and then they spam you. Twitter can crate their own bots to tweet these words to catch these spam bots and more importantly harvest the links that they are tweeting to detect other spammers. Twitter's own bots would obviously be far more intelligent than the spam bots since they would have access to a lot more information that the spam bots don't.

The spammers do catch up, but if Twitter spends a little time and energy, they can stay ahead in this game. They can even lead the pact of social media companies on how to deal with spam.

Update: As soon as I published this post, I tweeted it and copied Del Harvey on it. She immediately responded to the post. You can read her response here. I really appreciate Twitter responding to this. My take on the response is that they seem to understand what the issues are and how they might solve them, but they haven't fully managed to execute on it, so far. I don't agree with their feedback on issue #2 calling it non-safety. Users see Twitter as one integral product where spam is very much part of it. Personally, I don't think of spam as a security issue for me. It's just plain annoyance. Executing on these ideas will matter the most. Let's hope Twitter gets behind this with full momentum and it doesn't become a "project".

Social Shaming

An interaction designer, Joshua Kaufman, had his MacBook stolen a few days back. He is a smart dude. He had installed an app called Hidden on his MacBook before it was stolen. He tracked down the thief and asked the Oakland PD to catch him. They said no. He was frustrated, obviously. He published all the details regarding the theft including the picture of the guy who stole his MacBook on his blog. This story went viral on Twitter and Facebook and made it almost impossible for the cops to ignore it. Oakland PD found the guy and arrested him. Since then the story has been picked up by many major media outlets and became sort of a sensation.

Social shaming works.

There's a fine line between peer pressure and social shaming. Many car dealerships in the US have a whiteboard that tracks which sales reps sold how many cars. They also ring a bell every time someone sells a car. It's a cheesy thing to do, but it sends a clear message to other people to be more aggressive; it's indeed a form of peer pressure. It's also an efficient technique to motivate the kids.

In fact, it's one of the most important gamification elements.

Public shaming has been used in many different ways e.g. send an email out to all the sales people with a list of people highlighted in red that haven't updated the CRM system. I know of a company that had a practice in place to publicly give a "D'oh! award" to a developer who broke the nightly build. Social shaming is essentially public shaming using social media. During my discussion with many enterprise social software vendors, analysts, and thought leaders I have repeatedly argued that changing end users' behavior is less likely to succeed unless there's a significant upside for the end users. What is more likely to work is codifying the real life end user behavior in the software that they use. Social shaming is one of those. One of the ways to achieve this could be by designing software that promotes radical transparency, signals one's successes to the other, and nudges them to excel without embarrassing them.

Disruptive Cloud Start-Ups - Part 2: AppDirect

Check out the first post of this series on NimbusDB, if you haven't already seen it. This post is about AppDirect. I met with Nicolas Desmarais, a co-founder and the CEO of AppDirect and had a long discussion regarding their current solutions and future strategy. AppDirect is an app store for small businesses. The developers can integrate their applications with AppDirect and AppDirect manages the experience of selling, provisioning, and billing with a 70-30 revenue split with the developers. They also have a white label app store solution that they sell to large customers such as ISPs who can sell these same applications to their customers.

Let's get the things out of the way that I didn't like about them.

The downside:

The target market that comprises of small businesses is extremely difficult to reach to and to market to. This gets even more difficult when the company trying to market is a young start-up and the customers are "S" in SMB. These customers have very different kind of requirements. They look for simple solutions that are not very expensive and have predictable SLA with a clear local support model and not the ones that come with enterprise grade features such as end-to-end integration, single sign on etc. Intuit has owned this channel for a while via Quickbooks and their SMB marketplace (the partner platform) is a great example of selling go-to-market services to other ISVs. AppDirect will have to work much harder if they want to work this channel.

So, why do I think they are disruptive?

The upside:

AppDirect is platform-agnostic. The developers can write applications in any language and run it on any platform as long as they integrate with AppDirect's end points (the APIs). The ISVs or PaaS providers have traditionally locked developers into their platform. That lock-in now goes away.

Even though the telcos are not the most innovative companies, they are laggards with a pile of cash, a ton of customers, and good margins. I believe that telcos can be great enterprise software vendors for SMB. Instead of spending money on the marketing efforts, if AppDirect can convince the Telcos and ISPs to bundle their white label solution, it's a win-win situation. This business alone can make them profitable. What you need is a small number of large customers. Long tail can always be an added bonus.

The team is talented and they have got a good product with some early customers. If they can execute on their vision and pivot as necessary, they're on to something,

Check out their slides and presentation:

Disruptive Cloud Start-Ups - Part 1: NimbusDB

Being at Under The Radar (UTR), watching disruptive companies present and network with entrepreneurs, thought leaders, and venture capitalists is an annual tradition that I don't miss. I have blogged about disruptive start-ups that I saw in the previous years. The biggest exit out of UTR, that I have witnessed so far, is Salesforce.com's $212 million acquisition of Heroku. This post is about one of the disruptive start-ups that I saw at UTR this year - NimbusDB.

I met with Barry Morris, the CEO and Founder of NimbusDB at a reception the night before. I had long conversation with him around the issues with legacy databases, NoSQL, and of course NimbusDB. I must say that, after long time, I have seen a company applying all the right design principles to solve a chronic problem - how can you make SQL databases scale so that they don't suck.

One of the main issues with the legacy relational databases is that they were never designed to scale out to begin with. A range of NoSQL solutions addressed the scale-out issue, but the biggest problem with a NoSQL is that NoSQL is not SQL. This is why I was excited when I saw what NimbusDB has to offer: it's a SQL database at the surface but has radically modern architecture underneath that leverages MapReduce to divide and conquer queries, BitTorrent for messaging, and Dynamo for persistence.

NimbusDB's architecture isolates transactions from storage and uses asynchronous messaging across nodes - a non-blocking atom commit protocol - to gain horizontal scalability. At the application layer, it supports the "most" of SQL 99 features and doesn't require the developers to re-learn or re-code. The architecture doesn't involve any kind of sharding and the nodes can scale on any commodity machine on a variety of operating systems. This eliminates an explicit need of a separate hot back-up since any and all nodes serve as a live database in any zone. This makes NimbusDB an always live system, which also solves a major problem with traditional relational databases - high availability. It's an insert only database and it versions every single atom/record. That's how it achieves MVCC as well. The data is compressed on a disk and is accessed from an in-memory node.

I asked Barry about using NimbusDB as an analytic database and he said that the database is currently not optimized for analytic queries, but he does not see why it can't be tuned and configured as an analytic database since the inherent architecture doesn't really have to change. Though, during his pitch, he did mention that NimbusDB may have challenges with heavy reads and heavy writes. I personally believe that solving a problem of analytic query on large volume of data is a much bigger challenge in the cloud due to the inherent distributed nature of the cloud. Similarly, building a heavy-insert system is equally difficult. However, most systems fit somewhere in between. This could be a great target market for NimbusDB.

I haven't played around with the database, but I do intend to do so. On a cursory look, it seems to defy the CAP theorem. Barry seems to disagree with me. The founders of NimbusDB have great backgrounds. Barry was the CEO of IONA and Streambase and has extensive experience in building and leading technology companies. If NimbusDB can execute based on the principles it is designed on, this will be a huge breakthrough.

As a general trend, I see a clear transition, where people finally agree that SQL is still a preferred interface, but the key is to rethink the underlying architecture.

Update: After I published the post, Benjamin Block raised concerns around NimbusDB not getting the CAP theorem. As I mentioned in the post, I also had the same concern, but I would give them benefit of doubt for now and watch the feedback as the product goes into beta.

Check out their slides and the presentation:

Slides:

Presentation: