We just launched a neat feature that we've been working on for months: the ability to have your own custom branded channel on slideshare.

This feature was initially inspired by the way youtube users can customize their profiles, but once we started showing it to customers it took on a life of it's own. With a branded channel you have total control over the look and feel of your slideshare profile and document pages. You can also organize your profile to highlight particular documents, and search within your documents.

Some high-profile profiles (sorry, couldn't resist ;->) include ogilvy, microsoft, and the white house.

This if you're interested in your own branded channel then fill out the form on this page and we'll get back to you within 24 hours.

I'm going to be participating in a fun event next week. The topic is "How to Run a Scrappy Startup", and Dan Martell (of the amazing FlowTown) and I will be sharing tips and tricks for launching and running your startup on a shoe-string budget.

The cool thing about these "Entrepreneurs Lounge" events is that they are held in a GREAT bar (the British Banker's Club), and it's a very informal (there was lots of give-and-take at the last one, which is something that events often promise but in my experience rarely deliver).

So join me for a pint at the British Banker's Club last week, and we'll talk about how to get your startup off the ground without going broke in the process!

The event is organized by the lovely ladyleet from liveumbrella. Here's the official blurb:

Learn how to do a startup for less money than it cost to buy an economy car, without burning through your cash and failing before you even get started. Is this "lean startup", or is it just old-fashioned thriftiness?  Also, tales of scrappy startup companies like PayPal, MySpace, Plaxo and how they made things happen using unconventional approaches.  It's going to be good!

Last weekend we had a Hadoop HackDay at the SlideShare office. Ten teams competed in all, including 3 teams from outside slideshare and 7 from slideshare. Nobody slept a wink (OK I may have dozed off for an hour or so, but the contestants kept cranking out code through the night). The hacks were uniformally impressive ... recommender systems, personalization engines, and classification systems, and operations monitoring / analytics were the most common themes.

Here's the top things I learned:
-Hack days rule as a way of learning new things. In a day, we were able to go from not knowing much about Hadoop to being able to build real systems with it. The competitive motivation + the ability to learn from each other really accelerated individual learning to an almost unbelievable extent. Everyone who competed produced working code that did something at least moderately impressive, even though only one team had any previous Hadoop experience!

-Infrastructure and Architecture are coming closer together, in that software engineers need to understand a LOT more about the core infrastructure in order to do their jobs. At times the hackday seemed as much an #awshackday as a #hadoophackday. Learning how to use ElasticMapReduce, EC2, S3, and Elastic Block Storage were as central to the experience as learning how to code in Pig and Hive.

-Pig and Hive, are very powerful languages for scripting Hadoop jobs. The final programs submitted by participants were often less than 100 lines long, yet performed very powerful transformations on large data sets. The learning curve was manageable, certainly much less than learning a new high-powered language like python or ruby.

-Elastic MapReduce (from Amazon) is the ultimate gateway drug for parellel computing. Every participant was able to start running simple hadoop programs in less than an hour, without installing anything on their laptops!). However, the versions of Hadoop and Pig that come with it are quite old, and given the number of nodes one will need in production, it will be much cheaper to run the cloudera distribution of hadoop on ec2 machines that you rent on the amazon spot market. For experimentation, it's hard to argue against Elastic MapReduce. The hosting bill for the entire hackday came to 22$!

-Hadoop is very resource-intensive! We started out using 1-node clusters to run our jobs against small subsets of data. Very quickly teams started upgrading to 5-node clusters due to the amount of time they were having to wait for results. Final runs against full data sets were powered by 10-node clusters of "medium" ec2 servers. You have no choice but to use cloud computing for these kinds of jobs, because it seems to me that production use could easily require 100s of nodes, and no one would want to buy that many servers for machines that they only use one hour a day.

-Moving data to the compute cluster was more of a limiting factor than we had anticipated. Most people wanted to work on BIG (at least 1GB) data sets, and copying that from the slideshare cluster to s3, then from s3 to the hadoop file sytem took a lot of time. If this is a limiting factor for your app, you'll need host your whole app in the cloud, or use a physical hosting provider who also provides cloud computing services (like softlayer or rackspace).

That's it! We can't wait to start diving into using hadoop in production, and we'll probably organize more public hackdays in the next few months, since this one was so successful.

Amazon Web Services announced a couple of days ago that they would be auctioning off excess compute capacity in their cloud. This is a huge deal for a bunch of reasons ... but I'm really interested in what's in it for entrepreneurs like me.

Here's the thing: the prices so far are bargain basement: a small EC2 instance that typically costs $.10 per hour fluctuates between $.026 and $.036 an hour. The price you pay is whatever the current spot rate is ... even if your bid is higher than that.

The use case Amazon suggests is bidding for this unused capacity to handle batch processing that is not time-critical. But since the price so far has never risen anywhere close to the "rack rate" of .10$/hr, placing a high bid (say for $.12/hr) should allow you to have access to amazon compute resources at drastically reduced rates (currently between 25% and 35% of current rates).

Of course, my perpetual high bid will help keep the prices from dropping too low on the spot market, and I'm sure Amazon appreciates that. From the perspective of the spot market, I'm a sucker. It's only from the perspective of someone who needs compute resources on a constant basis that I'm getting a good deal. But a 50%-75% discount on my servers in exchange for a simple change is nothing to sneeze at!

One caveat: I'm assuming that prices on the spot market will never rise much above the "rack rate" for servers. This seems like a good assumption, since if they ever do users can always instantiate those servers instead of the ones on the spot market. But these are early days for computing as a real-time commodity, and no one really knows what this market will be like.

I'll keep you updated as we at SlideShare experiment with this exciting new pricing model ... we're going to switch half of our conversion servers over to the spot market first, and see what happens over the next several weeks.

At slideshare we spend a LOT of money on Amazon Web Services, especially EC2. We love AWS because the pay-as-you go pricing model means that we never invest in servers that we aren't ready to use yet. But earlier this year, Amazon released the ability to prepay for a "reserved EC2 instance" (see my initial reaction here). In exchange for paying a fee, you get the right to consume instance-hours at 1/3 of the standard rate. You can do this for either one or three years (three years simply requires a larger fee). The pricing of both reserved instances and standard instances have recently been discounted.

I was curious whether this would be a good deal for slideshare, so I modeled out the cost over a three-year period for one large instance. I modeled 3 scenarios:
1) paying as you go (the way we do currently)
2) paying the 1-year reserved instance fee every year
3) paying the 3-year reserved instance fee

The discounting is identical across different instance types (I spend a little time double-checking this), so my conclusions should be relevant to you even if you use small or medium instances.

Here's the spreadsheet.

The results surprised me quite a bit. Some quick observations:
1) Amazon bills at the end of the month (after usage). But the prepay happens at the beginning of the month (before usage). This pushes out the "break-even" point for an investment in a dedicated instance 1 month further than you might think. For the 1-year plan (the only one worth considering IMHO) this happens in the seventh month.

2) Discounts are not as generous as they appear. As a result, it ONLY makes sense to consider a dedicated instance for a machine that will be running 24 hours a day, 7 days a week.

3) Amazon pricing is rapidly being discounted. Locking your prices in for 3 years is almost certainly not beneficial to you at this point, given the small spread between the discounts (the difference is 18%. Given Amazon's track record, betting that they will not discount their services by 18% in the next three years is very risky).

4) A 30% a year discount (which is what you get with the one-year prepay option I model) will certainly be attractive to many small businesses or larger companies. After all, a 30% yearly return on an investment is pretty good. But a startup will almost always have something else it can invest in that will pay better than 30%/year. For us it's engineering: the faster we can improve the slideshare experience, the more money comes in the front door for us. The cash flow properties of amazon's core pricing model (paying for the infrastructure you need after you use it) are pretty darned hard to beat.

Conclusion: 1-year instances may be a good choice for many customers. But most venture-backed, bootstrapped, or rapidly growing companies should just stick with the default Amazon pricing. So we won't be investing in Amazon Reserved Instances right now. We'll just rely on the steady discounting from Amazon to drive our infrastructure costs down over time.