Yottaa Blog

Can Entrepreneurs Be Made?

February 27th, 2010

What are the unique characteristics of entrepreneurs? It is a subject that I think about from time to time. Over the years, I identified a few patterns and I use such patterns in judging other people whether they are entrepreneurs or not.

Here are the patterns that I identified and use:

Strong will power: Someone who is persistent in his/her pursuit and won’t give up easily, whatever the pursuit might be. It is not entirely accidental that a lot of entrepreneurs are avid long distance runners because long distance running like marathon is more about having a strong mind than anything else.

Relentlessly resourceful: Someone who is able to figure out how to make things happen against all the odds. Someone who would try from many different angles and perspectives in order to achieve a goal and take failed attempts as input for finding better ways.

Passion. Starting a new business is hard, and you’d better love it for what it is. Having the passion for solving a particular problem and being compelled by the vision of how better the world would be if the business succeeds are the key reasons that one would get up every morning and fight against all the odds to make it happen.

Intelligence. Someone who is highly intelligent. Intelligence is the basic foundation upon which everything else is built. Passion without intelligence is called romance. And it is a good idea to stay away from those with strong will power but without the smarts.

Interesting that post from Vivek Wadhwa on TechCrunch about “Can Entrepreneurs Be Made”. I would disagree with Vivek. No, you cannot teach someone to have passion for something. You can not teach strong will power, intelligence or being relentlessly resourceful. I hear about “pattern recognition” from VCs and other people a lot as well. I have never seem anyone use “gene” as part of the pattern recognition. Nobody judges an entrepreneur by whether his father or mother started a business before or not. On this regard, Vivek’s study is flawed as his article is based on survey results related to family genes as evidence to dispute against pattern recognition.

On the other side, is there value to teach entrepreneurship and is there value for programs like Kauffman Labs as Vivek mentioned in his article? Yes, absolutely. There are millions of people who do have the intelligence, are resourceful, have strong minds and have passion for a certain things, but just haven’t made the jump yet. Surrounding them with other entrepreneurs, mentors and a startup atmosphere is the best way to light up their inner fire. For many reasons (not the least that Wall Street and Google hire tons of smart people to golden hand cuffs), only a tiny percentage of “qualified people” (those who have the ingredients to be entrepreneurs) would become an entrepreneur. So there is a large pool of people (in the order of millions) that entrepreneurship programs, ranging from MIT Sloan Entrepreneurship Center to Kauffman Foundation to TechStars, can make a big difference for.

Fred Wilson has a post on this subject as well: Nature vs Nurture and Entrepreneurship. He listed five attributes for entrepreneurs:

A stubborn belief in one’s self

A confidence bordering on arrogance

A desire to accept risk and ambiguity, and the ability to live with them

An ability to construct a vision and sell it to many others

A magnet for talent

These attributes are very much along the similar lines as mine, though I would disagree with the “stubborn” and “arrogance” thing. Vivek rightfully pointed out “Silicon Valley investors often have a picture in their heads of the type of person who is worthy of funding: young, brash, stubborn, and arrogant”. No. There are plenty of successful entrepreneurs who are very humble and very flexible. It is not about being stubborn. It is about having the strong will power to make something happen. In doing so, many entrepreneurs are perfectly happy for being the opposite of “stubborn” about a lot of other things. It is not about being “arrogant”. Arrogant people are those who haven’t seem enough yet. Good entrepreneurs are confident but also have keen ears and eyes to learn from other people.

Posted in entrepreneurship, startup | No Comments »

Converting instance-store instances to EBS instances (AWS EC2)

February 27th, 2010

A month or two ago, Amazon Web Services (AWS) announced that their EC2 instances will now be bootable from an elastic block store (EBS) volume. This seems like a small change, but in fact has opened up a world of possibilities in the Elastic Computing Cloud (EC2).

EBS provides “block level storage volumes for use with Amazon EC2 instances.” Keep in mind that prior to this, instances were limited to booting off of S3-backed Amazon Machine Images (AMI), which were not persistent images. This meant 2 things:

instance-store AMIs cannot be “stopped,” only rebooted or terminated
rebooting an instance-store AMI reverted the instance back to the AMI defaults

Since EBS originally debuted as a high-performance attachable block device to a given instance, booting off of EBS AMIs has shown to be faster than the traditional instance-store boot as well.

Another benefit is that EC2 instances booted off of EBS volumes can be stopped, which effectively equates to shutting down a machine in the real world. You are still responsible for the charges incurred while this instance is reserved, but all of the changes made to said instance will persist after you start it again.

The last major benefit of booting off the EBS volumes is that AWS has made it easy for you to create a new EBS AMI from a running EBS AMI. In the Console, right clicking on an EBS instance will yield a new option, “Create Image (EBS AMI).” This will basically shut down your instance, and proceed to generate a new EBS AMI from the contents on the disk of your instance. This command seems to have a failure rate of ~40%, which can be a little frustrating. I’ve found that if you put an instance into ’stopped’ state before creating the EBS AMI, the process has a higher chance of success, but will still take anywhere from 20-45 minutes.

The rest of this article will focus on converting an instance-store AMI into an EBS AMI.

In order to perform this conversion, you will need to have an instance-store AMI that is the base OS you’d like to run (for the purposes of this article I used alestic’s Debian 5.0 base image), and access to EC2 via CLI as well as the portal (it’s all do-able from the CLI, but some of the tasks are a LOT easier and quicker through the web console). The stuff I did in the console will be suffixed with [console], and the stuff from CLI will be prefixed with #.

1) Booting an instance-store AMI – I executed the following to get a list of the images that fit my criteria (32bit, Debian, base install):

# ./ec2-describe-images –region eu-west-1 –all | grep -i lenny-base | grep i386

IMAGE ami-b13a6bf4 alestic-32-us-west-1/debian-5.0-lenny-base-20090804.manifest.xml
IMAGE ami-b33a6bf6 alestic-32-us-west-1/debian-5.0-lenny-base-20091011.manifest.xml

Note: ec2-describe-images outputs way more data than this, above is formatted for brevity.

Once you have the AMI (newer is better, generally speaking), boot an instance with this AMI:

# ./ec2-run –region eu-west-1 -k $keypair ami-b33a6bf6

Note: $keypair in this case is the name of keypair used to SSH into the server

2) Customizing the EBS volume – After the instance is up and running, look to see which availability zone the instance is in. If the region is eu-west-1, the availability zone is going to be either eu-west-1a, or eu-west-1b. In either case, find out which availability zone your instance is in, and then create a 10gb EBS volume is the same zone [console].

Why 10gb? 10gb is the maximum size for an S3-backed AMI, which makes a 10gb volume the largest any instance-store AMI will be. Obviously EBS AMIs can exist on larger volumes (all the way up to 1tb in size), and you can easily do so once you have an EBS-backed AMI.

After the EBS volume has been created, attach it to the running instance [console]. Remember what you chose as the device name the volume identified itself as (/dev/sdf for example).

In a root shell on the instance:

# mkfs.ext3 /dev/sdf

# mkdir /mnt/target && mount /dev/sdf /mnt/target

# rsync -avHx / /mnt/target

# rsync -avHx /dev /mnt/target

# sync;sync;sync;sync && umount /mnt/target

The above commands did the following:

formatted the entire volume /dev/sdf as an extended 3 filesystem
created directory /mnt/target and mounted /dev/sdf at /mnt/target
rsync’d the root instance-store filesystem to the ebs volume
synchronized the /dev directory from the instance-store filesystem
flush all pending write ops, and unmount the EBS volume

3) Creating the AMI – At this point, you should have a 10gb EBS volume that shows available [console]. Simply right-click on the volume and create a snapshot for the volume [console]. Once the snapshot has completed, select from the list of available kernels on ec2 with the following command:

# ./ec2-describe-images -o amazon | grep -i xenu

Store the AKI for the kernel you want to use in the environment variable AKI:

# export AKI=aki-xxxxxxxx

Up to this point, we have booted an instance-store AMI, created an EBS volume, synchronized the instance-store filesystem with the EBS volume, and created a snapshot of the EBS volume. The only thing we need to do now is associate an AKI with the snapshot, and register the end result as an AMI in the EC2 repository.

# ./ec2-register –region eu-west-1 -s $SNAP –name $NAME –description “$DESC” –architecture $ARCH \

–root-device-name /dev/sda1

Where $SNAP is the ID of the snapshot, $NAME is the name of your AMI, $DESC is a description of the AMI, and $ARCH is either i386 (for 32-bit) or x86_64 (for 64-bit). The command will return an AMI, which will be yours to boot from once it finishes!

To track the progress of the AMI creation, you can do the following:

# watch -n 30 ‘./ec2-describe-images ami-xxxxxxxx’

This will execute the ec2-describe-images command for your new AMI every 30 seconds. You can stop the command once you see that the AMI is in available state.

Now that you have an EBS-backed AMI, any further customizations you make to this image can be preserved forever by simply right-clicking on the instance [console], and clicking “Create Image (EBS AMI).”

Enjoy!

Posted in AMI, Uncategorized, aws, cloud, ebs, ec2, instance-store | No Comments »

DNSSEC on the Root Zone: Are You Ready?

February 18th, 2010

According to the ICANN, US Department of Commerce, and VeriSign, DNSSEC will be implemented on the root zones by no later than May 2010 (source: http://www.root-dnssec.org/). For those of you who don’t know what this means, here’s a deconstruction of the sentence above:

DNS stands for the Domain Name System. DNS is a hierarchical naming system for the Internet (or private network) that translates human-meaningful domain names into machine-meaningful numerical identifiers (eg, www.winnersdontlose.com -> 74.52.192.250).

DNSSEC stands for the Domain Name Systems Security Extensions. It is effectively a suite of IETF-created specifications for securing certain types of data that is provided by DNS.

A root zone is the top-level DNS zone in the above mentioned hierarchy. Generally speaking, “the root zone” is the largest global DNS system on the Internet. IANA and ICANN manages this zone. Strictly speaking, this zone is where the authorities for gTLD (.com, .net, etc) and CC TLD (.uk, .us, etc) are configured and handed out to the world. The root zone is hosted on 13 clusters of root servers (a. to m.root-servers.net), which are the only servers in the world that are allowed to be authoritative for it.

So now, re-read what I typed.

According to the ICANN, US Department of Commerce, and VeriSign,
DNSSEC will be implemented on the root zones by no later than May
2010 (source: http://www.root-dnssec.org/).

So what does this really mean to you? Given that the majority of us don’t need to know much more than theory about the root zone, would ICANN, US Dept of Commerce, and VeriSign really risk implementing something that could break a lot of installations today? One would think that the majority of their decisions could be implemented in a transparent fashion, unbeknownst to the most of us. To better understand this decision, let’s look at it from two different perspectives:

What benefits does DNSSEC on the root zone really provide? Why is it necessary?
What is the impact to the rest of the Internet by implementing DNSSEC on the root zone?

1) DNS, like a whole lot of other protocols that were created decades ago, was designed for a different Internet (lower bandwidth, higher error rate, trustworthy users). The Internet as we know it today (including the misanthropes) has forced the creation and deprecation of many protocol specifications. DNS suffers mostly from the trust issue. For example, a DNS resolver currently sends a query for a resource record (RR) out to the Internet, and then will accept the first response it receives, without question. Obviously a malicious server could provide an incorrect response, forcing the original resolver to use this incorrect address until its cache expired. If this DNS server belongs to a major consumer ISP (like Comcat or RoadRunner), a major service interruption affecting tens of thousands of users could easily happen.

2) From a technology standpoint, the impact of signing the root zone has a minimal effect on end users and networks. Since DNSSEC uses a PGP-esque keypair setup, RRs that are sent and received all day long by nameservers will be a little larger. This will probably result in slightly larger network bills for companies managing large-ish installations, with the rest of us noticing little to no change in our operating costs.

So what IS the problem?

Part of the problem is that RFC 1035 (http://www.ietf.org/rfc/rfc1035.txt) set an upper-bound for the size (512-bytes) of a DNS response. Because of this, many firewalls and applications used this limit in their DNS implementations. This would not have been an issue until DNSSEC. Since DNSSEC responses will have a signature (RRSIG) as well as the RR itself, it’s not out of the question to assume that many responses will be bigger than 512 bytes in size.

In addition to the RFC, another issue is that larger DNS packets have never been well respected on the Internet. Most of the time, large UDP packets will get fragmented by routers along the way to the destination, and the destination either doesn’t, or can’t deal with fragmented UDP packets, and drops them. DNS clients will usually then retry the query with a smaller buffer size, and may even eventually fail back to TCP.

In a nutshell, most of the problems that come about as a result of DNSSEC being implemented on the root zone are caused by larger DNS packets. The two things you want to make sure of are:

Your server/network will allow in DNS packets larger than 512-bytes.
Your network/firewall will accept IP fragments, and your server knows what to do with them.

The DNS Operations Analysis and Research Center (DNS-OARC) has created a tool to help ease this process. See https://www.dns-oarc.net/oarc/services/replysizetest for more details.

Posted in Uncategorized, dns, dns-oarc, dnssec, ip fragment, root zones | No Comments »

Creating custom TCP monitors in Nagios

February 16th, 2010

Recently I had to configure nagios to monitor a non-standard port (9999/TCP). This is a service of ours that apparently decides to die at random times. In order to find out more about the issue (this service is not live yet), I configured an instance of nagios to monitor this port.

In order to do this, I used the pre-existing check_tcp with a specific run-time parameter (namely, -p 9999).

First, define a command for this service check:

define command{
     command_name check_tcp_9999
     command_line $USER1$/check_tcp -h $HOSTADDRESS$ -p 9999 -4
}

Note that we manually defined the -p (port) and -h (host) parameters to use the host using this command, as well as port 9999, respectively.

Once the command has been defined, create a new service for the host in question. If you haven’t set one up yet, below is an example to follow:

define host{
     use generic-host   ; template name, available by default
     host_name svr-001  ; unique name of the host being defined
     alias server 001   ; description of the host
     address 10.0.0.254 ; IP of the host
}

To get the service check we defined above running against this host, reference the following stanza.

define service{
     use generic-service                          ; template name, available by default
     host_name svr-001                            ; the host against which to run this check
     service_description 'tcp check of 9999/tcp'  ; self-explanatory
     check_command check_tcp_9999                 ; name of the command we defined earlier
     check_interval 5                             ; check this service every 5 minutes
     check_period 24x7                            ; time period in which to monitor
     retry_interval 3                             ; if a check fails, re-try in 3 minutes
     max_check_attempts 3                         ; the max number of times a failed service will be checked
     notification_interval 60                     ; reminder of alerts sent every 60 minutes
     notification_period 24x7                     ; time period in which alerts are sent
     notification_options w,c,u                   ; the conditions upon which to send alerts
     contact_groups contacts                      ; contact group to alert in the event of failure
}

Verify that the additions you made to the config file(s) were valid by executing:

# nagios3 -v /etc/nagios3/nagios.cfg

If the pre-flight check goes well, update your nagios installation by executing:

# /etc/init.d/nagios3 restart

That’s it!

Posted in 8080/tcp, 9999/tcp, Uncategorized, monitoring, nagios | No Comments »

EC2 filesystem performance

January 26th, 2010

I’ve been posting lately about a tool named bonnie++, which will run a suite of tests against your linux filesystem to determine metrics in 3 important areas: data read/write speed, max random seeks, and max metadata operations. Last time I posted about profiling one of Linode.com’s “Linode 360″ instances. In this article I will profile a m1.small instance on Amazon Web Services’ (AWS) Elastic Compute Cloud (EC2) service.

EC2 is the first legitimate cloud offering to market, and in many contexts they are the most developed, most robust, cloud provider. However, there are many companies quickly ramping up their offerings (GoGrid, Voxel, Flexiscale, etc), if only in one or two datacenters (Voxel is the leader of the group, with locations in NY, Singapore, and Amsterdam).

The m1.small instance comes with the following specifications:

1.7gb RAM
1 EC2 Compute Unit
160gb instance storage
“moderate” I/O performance

While these specs are mostly useful in comparison to other EC2 instance sizes, the performance of this particular size will provide a useful benchmark for baselining EC2 performance. Since this is the smallest instance, I’m assuming “moderate I/O performance” means that it’s as bad as it gets.

From the earlier post, we use the following command to invoke bonnie++:

# bonnie++ -u 0 -r 1700 -s 34000 -n 256 -b -d /

The above commanded failed to run, claiming that the filesystem was out of space. Checking the filesystem, I see that I only have /dev/sda1, which is 15gb and mounted at /. Since real-world testing involves what the customer actually gets and not what the marketing literature says, I adjusted the -S parameter to 3400, which should easily outpace/outpage the 1.7gb of memory in my instance.

Invoking bonnie++ with the new parameter yields me with the following result (click for larger image):

Server ip-10-226-125-238 was able to

sustain ~52MBS at 6% CPU for sequential block writes
sustain ~64MBS at 1% CPU for sequential block reads
max out at 939.8 random seeks per second
sequentially create 127 files per second
randomly create 174 files per second
sequentially read metadata from 158,584 files per second at 39% CPU
randomly read metadata from 203,851 files per second at 41% CPU
sequentially delete 121 files per second
randomly delete 158 files per second

As the results from running bonnie++ in various providers pile up, I will compile them into a spreadsheet which will (hopefully) ultimately shed some light on the performance boundaries of various VPS and cloud providers.

Posted in HDD benchmarking, Uncategorized, bonnie++, cloud, ec2 filesystem performance | No Comments »

Linode filesystem performance

January 19th, 2010

In a previous article, I wrote about using bonnie++ (http://www.coker.com.au/bonnie++/) to benchmark the performance of your hard drives and filesystem. We went through a sample command, explained all the parameters (most notably, -s).

In this post I’d like to display and summarize the results from running bonnie++ on two systems: a Linode (as the title suggests) and a physical server as the control.

Linode is a VPS hosting company with availability in the US and Europe. They strive for the best service possible, and are a very well regarded provider within the hosting community. The linode I chose for the purposes of this test is their “Linode 360″ which comes with 360MB RAM, 16GB of storage, 200GB of transit, and a price tag of $19.95 per month. This is their entry-level setup, and their instances can scale up to 2.8GB RAM, 128GB storage, 1.6TB transit (for $159.95/month).

The command we’re running to invoke bonnie++ is:

# bonnie++ -u 0 -r 360 -s 7200 -n 256 -b -d /

Note the new values for -r and -s from my last post.

Results (click for a larger version):

On the far left of the results, in bold, you will see the machine’s hostname. In my case, this is the Linode assigned hostname of li149-50. The next column is labeled “Size: Chunk Size,” which is basically the size we specified as the size to use for IO performance measurements (the -s flag).

As stated in my last post, bonnie++ offers three specific metrics:

Data read and write speed.
Maximum seeks per second.
Maximum file metadata operations per second.

Applying these three metrics to our results, the following correlations can be established:

Sequential Input and Sequential Output apply to 1
Random Seeks apply to 2
Sequential Create and Random Create apply to 3

Now, let’s summarize with real numbers.

Server li149-50 was able to:

sustain ~85MBS at 13% CPU for sequential block writes.
sustain ~180MBS at 0% CPU for sequential block reads.
max out at 167.9 random seeks per second.
sequentially create 2,236 files per second.
randomly create 2,001 files per second.
sequentially read metadata from 395,067 files per second at 99% CPU.
randomly read metadata from 503,021 files per second at 99% CPU.
sequentially delete 1,014 files per second.
randomly delete 610 files per second.

Running the same bonnie++ command (with different -r and -s flags) on a physical server with an 80GB PATA drive yields the following (for reference, the values were “1024″ and “20480″ for “-r” and “-s”, respectively):

# bonnie++ -u 0 -r 1024 -s 20480 -n 256 -b -d /

Results (click for a larger version):

Summarizing in a similar fashion from above, we get the following:

Server tp.eliminated.org was able to

sustain ~41MBS at 29% CPU for sequential block writes.
sustain ~50MBS at 10% CPU for sequential block reads.
max out at 71 random seeks per second.
sequentially create 447 files per second.
randomly create 2,001 files per second.
sequentially read metadata from 288,111 files per second.
randomly read metadata from 503,021 per second.
sequentially delete 225 files per second.
randomly delete 610 files per second.

Note that the metrics regarding file metadata operations are based off of the number of files on which we test (the -n flag). Since the value supplied to -n was the same on both servers (256), the results we get back are very similar (if not the same).

I will continue to benchmark various VPS and Cloud providers in order to ascertain IO performance from as many providers as possible.

Posted in IO, Linux, Uncategorized, bonnie++, filesystem benchmark, linode | No Comments »

Benchmarking hard drives and filesystems with bonnie++

January 18th, 2010

Bonnie++ (http://www.coker.com.au/bonnie++/) is “a benchmark suite that is aimed at performing a number of simple tests of hard drive and file system performance.” Bonnie++ outputs a 80-column display report (to fit on braille keyboards), as well as csv values that can be converted to text or HTML (with bon_csv2txt and bon_csv2html, respectively).

Bonnie++ provides performance metrics on the following 3 things:

Data read and write speed: This should be fairly obvious. This is how fast you can read and write to the drive(s) in question.
Maximum number of seeks per second: If the blocks that your computer needs are not sequentially stored (right next to each other), then the heads in the HD will have to do a seek (physically moves the heads to the right platter).
Maximum number of file metadata operations per second: Metadata operations include things like file creation, deletion, or gathering any other metadata about a file (permissions, size, etc).

In order to run all of the tests included, I ran the following command:

# bonnie++ -u 0 -r 1024 -s 20480 -n 256 -b -d /

Let’s break down the parameters passed to bonnie++:

-u 0: The -u flag is used to indicated the UID that the test should run as. UID 0, as we all know, belongs to the root user.
-r 1024: The -r flag is used to indicate how much RAM (in megabytes) is in the machine. As you can see I have 1gb (1024mb).
-s 20480: The -s flag is used to indicate the size of the file(s) (in megabytes) to be used for IO performance testing. More on this value later.
-n 256: Specifies the number of files for the file creation test. This is in multiples of 1024 files, so 256 = 252,144 (256*1024) files.
-b: The -b flag is used to disable any system-level buffering. Basically this means an fsync() is called after every write operation.
-d /: The -d flag is used to indicate the path on which to perform the tests.

Of all the runtime parameters, -s is probably the most important to define properly. This flag (in megabytes) defines the size of the files used for IO performance benchmarking. If the supplied size is greater than 1gb, then multiple 1gb files will be used until the value is reached. In order to get proper results, you will want to specify a number much larger than the amount of RAM you have. If possible, use a much higher multiple, like 20x. To be sure to bypass any caching done by the hardware, you want at least 2-3x the amount of RAM.

Posted in HD, IO, RAID, Uncategorized, benchmark, bonnie++, filesystem | No Comments »

Yottaa Looking for Rock Star UX Architect

January 15th, 2010

Yottaa is looking for a rock star UX architect who can help make deliver an amazing user experience for various web applications.

Yottaa Inc (http://www.yottaa.com) is a Boston and Beijing based cloud computing company building a new generation of cloud services revolutionizing what we know about the Internet. With venture backing from institutional investors and a cross culture team, Yottaa aims to build a new kind of software company that leverages the best of China and US.

We are building some amazing technology that would make life better for millions of web users. We need your help in making the millions of users amazed, by the experience, not by the technology.

Contact coach at yottaa.com if you are interested or have suggestions.

Responsibilities

Create the vision for the Yottaa user experience, including interaction design, information architecture, and visual design
Interaction design for various software-as-a-service web applications and web sites
Work closely with various entities, mark up product features into UI designs, coordinate and collect feedback
Think from user perspectives and listen to users to continuously enhance the user experience
Travel and work with cross culture teams in Beijing and Boston

Skills / Requirements

Experience in user interaction design and visual design
Background in web development and web design
Knowledge of various web technologies and their capabilities in supporting user interactions
Love to take charge of areas from concept to make it happen; Be entrepreneurial;
Well developed oral and written skills in English. Some knowledge of Chinese would be a big plus;
Willingness to travel as needed

Location: Beijing or Boston

Posted in Main Page, WebDev, Yottaa, jobs, startup | No Comments »

Boston Area Startups to Watch

January 3rd, 2010

Nine venture-backed startups IPO’d in 2009, but just one of them was based in Silicon Valley: Sunnyvale security firm Fortinet Inc. (Note that Fortinet is led by Tsinghua University alumni, also co-founder of NetScreen).

Close-by, San Francisco’s Open Table IPO’d in May.

Otherwise, it was all Massachusetts, Chicago, Seattle, and Texas. Massachusetts tops the list in 2009.

2010 should look different as we wouldn’t be surprised to see Silicon Valley-based startups Yelp, Zynga, Playdom, Tesla, Facebook and LiveOps IPO.

However, east coast does have a list of really good firms up and coming, not necessarily achieving stardom in 2010, but maybe in the next 2-5 years? Here is a short list of Boston based firms to watch for in the next few years in my humble opinion:

BrightCove: Internet video platform. Jeremy and co have done really well and BrightCove is on the way to stardom (Thanks Dharmesh for the suggestion)

Hubspot: marketing automation

VisibleMeasures: Internet video measurement. Brian Shin and the team have achieved a lot over the last few years. I’m sure 2010 will be another stellar year for them.

The following companies are fairly new. Some of them are still in stealth mode:

Akiba: Database virtualization. I expect nothing less than flawless exceution from my Nexaweb colleague David McFarlane

Sonian: email and other messaging archiving. After closing Series A financing in 2009, 2010 is going to be a great year for Greg and the folks at Sonian.

Performable: Stealth mode company led by my friend David Cancel. I know David well enough to know that this is going to be a great company.

Yottaa: “stealth mode” cloud computing company that I’m personally involved with. I’ve not been excited like this for a long time. There are so many amazing things at Yottaa. For example, this is the place that I have the smallest brain among all team members (but thank god, I found ways to enjoy being the dumb person. A couple of days ago I asked Tony for “business justification” on something he proposed – couldn’t believe how much I sound like the manager asking for TPS report cover sheet in the movie “Office”). I have a hard time catching up with them. Ok, time to really learn some Ruby:-)

What other firms in Boston area are interesting? My list above is fairly biased towards “software as a service” related companies. Please leave suggestions in the comment area. Thanks!

Disclaimer: Part of this post is not my writing, but rather re-posted from http://www.businessinsider.com/silicon-valley-no-longer-the-home-of-startup-ipos-2009-12.

Posted in Main Page, Yottaa, startup, startups | No Comments »

The World According to Americans and Chinese

November 25th, 2009

Happy Thanksgiving, everyone! Saw this cartoon in the morning today. It is really funny and couldn’t resist to re-post it here:
The World According to Americans

The World According to Americans

(Credit: http://www.ritholtz.com/blog/wp-content/uploads/2009/11/world-accordign-to-USA.jpg)
The next cartoon is also quite funny:
The World According to Ronald Reagan

(Credit: http://kelsocartography.com/blog/wp-content/uploads/2009/09/the-world-according-to-ronald-reagan.jpg)

Unfortunately I couldn’t find a good cartoon for Chinese. So here is one that I sorta assembled (I can think of tons of funny cartoon ideas. I wish i know how to draw them!):

The World According to Chinese

Posted in Main Page, humor | No Comments »