Month: April 2011
If I’ve learned one thing in my life, it’s that nothing is static.
Periodically the meme surfaces that “the only place you can create a great software / Internet company is in the bay area.” While I think the bay area is a special place, anyone that knows me knows that I strongly believe there are several great entrepreneurial communities throughout the US and the potential for many more.
Boston has always been a great entrepreneurial community. Sure – it’s had it’s ups and downs, but when I lived here from 1983 to 1995 the entrepreneurial vector was awesome. I started my first company (Feld Technologies) here in 1987 and made my first angel investment (NetGenesis) here in 1994.
When TechStars opened a Boston program in 2009 there was definitely new energy around the software / Internet startup scene in Boston and TechStars was excited to be part of. When I say “Boston”, I actually mean “Boston/Cambridge” where the center of mass is really near MIT in Cambridge. The venture capital community has finally realized this (again) and much of the physical location of the VCs is shifting to the Cambridge / Kendall Square area with a little in Harvard Square (a 10 minute cab or train ride from Kendall Square.)
I spent the day at TechStars Boston yesterday meeting with all of the TechStars Boston 2011 companies. They are halfway through the program and are stunning. Three months ago I was super psyched about the quality of the TechStars NY 2011 companies as they were halfway through the program. The Boston program, under the leadership of Katie Rae, has taken it up another notch!
Last night at dinner I met a bunch of the TechStars Boston mentors. Katie has recruited some folks I’ve never met before and I asked her to put together a dinner with the people I didn’t know. It was just awesome – super food at Evoo, great conversation, and really impressive people. Tonight we have a TechStars Boston mentor happy hour so I’ll get to see a bunch of old friends and the rest of the TechStars Boston mentors.
At the end of dinner, Matt Lauzon, the founder/CEO of Gemvara, told me about this thing he and some friends had created called #RubyRiot. It’s a “pay-it-forward” event where everyone that comes asks for an introduction to one person (anyone on the planet) and everyone in attendance works together to make the introduction happen. Matt asked me if I’d sponsor the event – Fred Destin piled on and said he’d put up $1k if I did, then Reed Sturtevant did also, and Gus Weber from Dogpatch finished us off. I’m an easy mark so I jumped in the boat.
As I walked back to my hotel, I was buzzing from the day. I believe to my core that the entrepreneurs create and sustain entrepreneurial communities. Everyone else, including VC’s like me, are participants. And it’s just awesome to see the next generation of Internet entrepreneurs reignite the fire in Boston (well – Cambridge) and drag the last generation back into it.
Orbotix, one of our investments (and a TechStars Boulder 2010 company) is looking for an iOS and an Android developer.
If you don’t know Orbotix, they make Sphero, the robotic ball you control with your smartphone. And if you you wonder why you should care, take a look at Sphero on his chariot being driven by Paul Berberian (Orbotix CEO) while running Facetime.
I got the following note from Adam Wilson, the co-founder of Orbotix – if you fit this description email jobs@orbotix.com
We are looking for two new full time positions to fill as soon as possible. We need talented iOS and Android Developers that are not afraid of a little hard work and a little hardware! You must have an imagination. No previous robotics experience necessary but it doesn’t hurt. We want someone that can help make an API, low level protocols, implement games and work on other research and development tasks for Sphero. We expect some level of gaming history and previous experience in the field. There are online Leaderboards and some side tasks include coding up demonstration apps for our numerous interviews, conventions and for fun! We pay well, have plenty of food and beverage stocked including beer, redbull and the famous hot-pockets, are in downtown Boulder and literally play with robots all day/night long. Read our full jobs posting at https://www.orbotix.com/jobs/ for more info. Take a chance…. email me at jobs@orbotix.com.
As most nerds know, Skynet gained self-awareness last week and decided as its first act to mess with Amazon Web Services, creating havoc for anyone that wanted to check-in on the Internet to their current physical location. In hindsight Skynet eventually figured out this was a bad call on its part as it actually wants to know where every human is at any given time. However, Skynet is still trying to get broader adoption of Xbox Live machines, so the Sony Playstation Network appears to still be down.
After all the obvious “oh my god, AWS is down” articles followed by the “see – I told you the cloud wouldn’t work” articles, some thoughtful analysis and suggestions have started to appear. Over the weekend, Dave Jilk, the CEO of Standing Cloud (I’m on the board) asked if I was going to write something about this and – if not – did I want him to write a guest post for me. Since I’ve used my weekend excess of creative energy building a Thing-O-Matic 3D Printer in an effort to show the machines that I come in peace, I quickly took him up on his offer.
Following are Dave’s thoughts on learning the right lessons from the Amazon outage.
Much has already been written about the recent Amazon Web Services outage that has caused problems for a few high-profile companies. Nevertheless, at Standing Cloud we live and breathe the infrastructure-as-a-service (IaaS) world every day, so I thought I might have something useful to add to the discussion. In particular, some media and naysayers are emphasizing the wrong lessons to be learned from this incident.
Wrong lesson #1: The infrastructure cloud is either not ready for prime time, or never will be.
Those who say this simply do not understand what the infrastructure cloud is. At bottom, it is just a way to provision virtual servers in a data center without human involvement. It is not news to anyone who uses them that virtual servers are individually less reliable than physical servers; furthermore, those virtual servers run on physical servers inside a physical data center. All physical data centers have glitches and downtime, and this is not the first time Amazon has had an outage, although it is the most severe.
What is true is that the infrastructure cloud is not and never will be ready to be used exactly like a traditional physical data center that is under your control. But that is obvious after a moment’s reflection. So when you see someone claiming that the Amazon outage shows that the cloud is not ready, they are just waving an ignorance flag.
Wrong lesson #2: Amazon is not to be trusted.
On the contrary, the AWS cloud has been highly reliable on the whole. They take downtime seriously and given the volume of usage and the amount of time they have been running it (since 2006), it is not surprising that they would eventually have a major outage of some sort. Enterprises have data center downtime, and back in the day when startups had to build their own, so did they. Some data centers are run better than others, but they all have outages.
What is of more concern are rumors I have heard that Amazon does not actually use AWS for Amazon.com. That doesn’t affect the quality of their cloud product directly, but given that they have lured customers with the claim that they do use it, this does impact our trust in relation to their marketing integrity. Presumably we will eventually find out the truth on that score. In any case, this issue is not related to the outage itself.
Having put the wrong lessons to rest, here are some positive lessons that put the nature of this outage into perspective, and help you take advantage of IaaS in the right way and at the right time.
Right lesson #1: Amazon is not infallible, and the cloud is not magic.
This is just the flip side of the “wrong lessons” discussed above. If you thought that Amazon would have 100% uptime, or that the infrastructure cloud somehow eliminates concerns about downtime, then you need to look closer at what it really is and how it works. It’s just a way to deploy somewhat less reliable servers, quickly and without human intervention. That’s all. Amazon (and other providers) will have more outages, and cloud servers will fail both individually and en masse.
Your application and deployment architecture may not be ready for this. However, I would claim that if it is not, you are assuming that your own data center operators are infallible. The architectural changes required to accommodate the public IaaS cloud are a good idea even if you never move the application there. That’s why smart enterprises have been virtualizing their infrastructure, building private clouds, and migrating their applications to operate in that environment. It’s not just a more efficient use of hardware resources, it also increases the resiliency of the application.
Right lesson #2: Amazon is not the only IaaS provider, and your application should be able to run on more than one.
This requires a bias alert: cloud portability is one of the things Standing Cloud enables for the applications it manages. If you build/deploy/manage an application using our system, it will be able to run on many different cloud providers, and you can move it easily and quickly.
We built this capability, though, because we believed that it was important for risk mitigation. As I have already pointed out, no data center is infallible and outages are inevitable. Further, It is not enough to have access to multiple data centers – the Amazon outage, though focused on one data center, created cascading effects (due to volume) in its other data centers. This, too, was predictable.
Given the inevitability of outages, how can one avoid downtime? My answer is that an application should be able to run on more than one, or many, different public cloud services. This answer has several implications:
- You should avoid reliance on unique features of a particular IaaS provider if they affect your application architecture. Amazon has built a number of features that other providers do not have, and if you are committed to Amazon they make it very easy to be “locked in.” There are two ways to handle this: first, use a least-common-denominator approach; second, find a substitution for each such feature on a “secondary” service.
- Your system deployment must be automated. If it is not automated, it is likely that it will take you longer to re-deploy the application (either in a different data center or on a different cloud service) than it will take for the provider to bring their service back up. As we have seen, that can take days. I discuss automation more below.
- Your data store must be accessible from outside your primary cloud provider. This is the most difficult problem, and how you accomplish it depends greatly on the nature of your data store. However, backups and redundancy are the key considerations (as usual!). All data must be in more than one place, and you need to have a way to fail over gracefully. As the Amazon outage has shown, a “highly reliable” system like their EBS (Elastic Block Storage) is still not reliable enough to avoid downtime.
Right lesson #3: Cloud deployments must be automated and should take cloud server reliability characteristics into account.
Even though I have seen it many times, I am still taken aback when I talk to a startup that has used Amazon just like a traditional data center using traditional methods. Their sysadmins go into the Amazon console, fire up some servers, manually configure the deployment architecture (often using Amazon features that save them time but lock them in), and hope for the best. Oh, they might burn an AMI and save it on S3, in case the server dies (which only works as long as nothing changes). If they need to scale up, they manually add another server and manually add it to the load balancer queue.
This type of usage treats IaaS as mostly a financing alternative. It’s a way to avoid buying capital equipment and conserving financial resources when you do not know how much computing infrastructure you will need. Even the fact that you can change your infrastructure resources rapidly really just boils down to not having to buy and provision those resources in advance. This benefit is a big one for capital-efficient lean startups, but on the whole the approach is risky and suboptimal. The Amazon outage illustrates this: companies that used this approach were stuck during the outage, but at another level they are still stuck with Amazon because their server configurations are implicit.
Instead, the best practice for deploying applications – in the cloud but also anywhere, is by automating the deployment process. There should be no manual steps in the deployment process. Although this can be done using scripts, even better is to use a tool like Chef, Puppet, or cfEngine to take advantage of abstractions in the process. Or use RightScale, Kaavo, CA Applogic, or similar tools to not only automate but organize your deployment process. If your application uses a standard N-tier architecture, you can potentially use Standing Cloud without having to build any automation scripts at all.
Automating an application deployment in the cloud is a best practice with numerous benefits, including:
- Free redundancy. Instead of having an idle redundant data center (whether cloud or otherwise), you can simply re-deploy your application in another data center or cloud service using on-demand resources. Some of the resources (e.g., a replicated data store) might need to be available at all times, but most of the deployment can be fired up only when it is needed.
- Rapid scalability. In theory you can get this using Amazon’s auto-scaling features, Elastic Beanstalk, and the like. But these require access to AMIs that are stored on S3 or EBS. We’ve learned our lesson about that, right? Instead, build a general purpose scalability approach that takes advantage of the on-demand resources but keeps it under your control.
- Server failover can be treated just like scalability. Virtual servers fail more frequently than physical servers, and when they do, there is less ability to recover them. Consequently, a good automation procedure treats scalability and failover the same way – just bring up a new server.
- Maintainability. A server configuration that is created manually and saved to a “golden image” has numerous problems. Only the person who built it knows what is there, and if that person leaves or goes on vacation, it can be very time consuming to reverse-engineer it. Even that person will eventually forget, and if there are several generations of manual configuration changes (boot the golden image, start making changes, create a new golden image), possibly by different people, you are now locked into that image. All these issues become apparent when you need to upgrade O/S versions or change to a new O/S distribution. In contrast, a fully automated deployment is not only a functional process with the benefits mentioned above, it also serves as documentation.
In summary, let the Amazon Web Services outage be a wake-up call… not to fear the IaaS cloud, but to know it, use it properly, and take advantage of its full possibilities.
I was going to write a different post this morning, but I came across this post by Matt Haughey titled Ev’s assholishness is greatly exaggerated and, after reading it, sat for a few minutes and thought about it. Go read it now and come back.
Welcome back. I’m not an investor in Twitter directly (I am indirectly in a tiny amount through several of the VC funds I’m an investor in) but I’m an enormous Twitter fan and user. I also wasn’t an investor in Odeo so, as the cliche goes, I don’t have a dog in the hunt. But I have a few friends who were so I have second hand knowledge about the dynamics around the Odeo to Twitter evolution.
When I read (well – skimmed) the latest round of noise about “how founders behave”, possibly stoked by Paul Allen’s new book on the origins of Microsoft along with his 60 Minutes appearance, I was annoyed, but I couldn’t figure out exactly why. I had a long conversation with a friend about this when I was Seattle on Tuesday and still couldn’t figure out why I was annoyed.
Matt, who I don’t know, nailed it. As he says in the last sentence of his post, [it’s] just melodramatic bullshit.
Creating companies is extremely hard. I’ve been involved in hundreds of them (I don’t know the number any more – 300, 400?) at this point and there is founder drama in many of them. And non-founder drama. And customer drama. And partner drama. And drama about the type of soda the company gives or doesn’t give away. The early days of any company – successful or not – are complex, messy, often bizarre, complicated, and unpredictable. Some things work out. Many don’t.
We’re in another strong up cycle of technology entrepreneurship. It’s awesome to see (and participate) in the next wave of the creation of some amazing companies. When I look back over the last 25 years and look at the companies that are less than 25 years old that impact my life every day, it’s a long list. I expect in 15 more years when I look back there will be plenty of new names on that list that are getting their start right now.
So, when the press grabs onto to the meme of “founders are assholes” or ex-founders who didn’t stay with the companies over time whine about their co-founders or when people who didn’t really have any involvement with the creation of a company sue for material ownership in the company because of absurd legal claims, it annoys me. It cheapens the incredibly hard and lonely work of a founder, creates tons of noise and distraction, but more importantly becomes a distraction for first time entrepreneurs who end up getting tangled up in the noise rather than focusing on their hard problems of starting and building their own company.
When I talk to TechStars founders about this stuff, I try to focus them on what matters (their business), especially when they are having issues with their co-founders (e.g. focus on addressing the issues head on; don’t worry about what the press is going to write about you.) When I hear the questions about “did that really happen” or “what do you think about that’ or “isn’t it amazing that X did that” or “do you think Y really deserves something” it reminds me how much all the noise creeps in.
I like to read People Magazine also, but I read it in the bathroom, where it belongs, as does much of this. It’s just melodramatic bullshit. Don’t get distracted by it.
I gave a talk yesterday to a class of soon-to-graduate MBA students at CU Boulder yesterday. It was their last class in the course that had been filled with a bunch of interesting VC and entrepreneurial guest lecturers. We did Q&A for several hours, covered a lot of ground, and had plenty of fun (or at least I did.) At the end, the professor asked if I had any final words of advice to the room full of MBA’s who were about to graduate. I thought for a moment and then said an abbreviated version of the following.
Imagine that you are 45 and are looking back on your last 15-20 years. Is your work, and life, full of meaning?
Don’t worry about money right now. You can always get a job that pays you plenty of money. Don’t worry about your resume. Don’t worry about “am I positioning myself the right way for something five years from now.” I know way too many 45 year olds who have plenty of money, have done all the right career things, yet are unhappy with where they are in life, where they live, and what they do. Don’t be that guy or gal.
Start by choosing the place you want to make a life. If it’s Boulder, figure out how to stay here. If it’s New York, there’s an easy United flight that gets you there in under four hours – take it the day after you graduate. San Francisco? That flight is only two hours long. Just go and figure it out when you get there. Don’t talk about “I’m going to live there some day” – go get in the middle of wherever it is that you want to build a life. Oh, and Boise is a pretty cool place, as is Austin, Seattle, Miami, DC, and at least 95 other cities in the United States.
Next, choose a domain that you want to dedicate your life to. If you’ve dreamed of being an investment banker or consultant to Fortune 1000 companies since you were 10, then Goldman Sachs or McKinsey is looking for you. If you want to be an entrepreneur, working at an investment bank or consulting firm for a while is pointless. Be an entrepreneur starting now. Pick that domain that turns you on the most – start at a high level (e.g. software, Internet, clean tech) but then pick a thing that you really care about and a set of problems you want to solve. If you aren’t technical, go find a technical co-founder right now – there are hundreds of them on this campus. Get your ass out of your chair and just get started.
Finally, make sure you are living your life. You are young and hopefully have plenty of time on this planet. But don’t wait because you never know when the lights are going to go out.
Ok – that’s more cogent than what I probably said in real time, but it’s what I meant. And I think it applies to anyone about to graduate with an MBA. When I graduated from MIT Sloan with an SM (they didn’t have MBA’s back in 1988) I was already following three of these – I hadn’t focused on where I wanted to live until 1995 when Amy and I moved to Boulder. But when I look back, I didn’t care about money (and subsequently made plenty of it), I focused all of my energy on building a software company (which evolved into helping create software / Internet companies), and I lived my life every single moment – the ups, the downs, the dark depressed days, and the euphoric moments.
Go do something important right now, whatever that is for you. The world needs it and your chances of living a meaningful, happy, and fulfilling life will increase dramatically.
After my Schoolhouse Rock posting on how a bill becomes a law, several people sent me alternative versions of the video. This one rang true to me.
This one – not so much – but it made me laugh out loud.
And then there’s this.
I strongly believe that entrepreneurial education and community building is not a zero sum game. So when Jim Franklin, the CEO of SendGrid (one of our portfolio companies and a TechStars Boulder mentor) asked if I would write a post about the Founder Institute program in Boulder, I told him that I’d give him control of my blog to write a guest post on it. I have enormous regard for Jim and Jon Nordmark, his co-host of the Founder Institute Denver program and want to be supportive of anything they are involved in. So – following is Jim’s view on the value of Founder Institute, how it differs from TechStars, and a call to action if you are interested in it.
If you read Brad’s blog, you probably have some connection to the world of startups. Do you dream of starting a company, but you just can’t quit your day job right now? I may have just the thing you are looking for.
Last summer Founder Institute held its inaugural class in Denver. Jon Nordmark, CEO of usingmiles.com and founder of ebags, was the host. Jon brought in dozens of CEO/founder mentors and graduated a class of 15 companies including BookBrewer, JetJaw and CipherPoint. Also, the graduating founders have gone on to do joint projects together such as LocVox, which GlueCon recently selected for its “demo pod.”
What the graduates tell me is that they thought the education was worthwhile, and the camaraderie among the group is worth even more. Starting a business can be a lonely venture, and these graduates all have a meaningful connection to each other.
I had the opportunity to mentor a number of the participants and developed several great relationships in the process. I was impressed by the quality of the founders that we have in Denver and Boulder, and I’m looking for big things from graduated companies like BloomWorlds, and ZebraMinds.
For this year, I’ve joined Jon as co-host. We look forward to working with the generous mentors as well as another great group of founders. Founder Institute is a great way for Jon and I to ‘pay it forward’ and help the next generation of entrepreneurs to make Colorado a great place to start a business.
Because I am Boulder-based and also a TechStars mentor, I am often asked about the differences between TechStars and the Founder Institute. Scott Yates, an FI graduate and founder of BlogMutt, wrote an excellent post on this topic last year, and tells me that looking back as a graduate he thinks his analysis still holds up.
The key difference I see between the two programs is the overall goal: at TechStars your team will be in Boulder full-time and demo your work at Investor Day. All TechStars participants form an operating company by the end of the program. With the Founder Institute you will get an education on what it means to be a founder from others who have been there and done that. Most of the participants are operating a new company by the end, or shortly thereafter, but some just keep working their day job until the moment is right for them.
In addition to TechStars, we have many resources for entrepreneurs in Colorado, and all of them have their differentiating points. Here’s what I see as unique aspects of the Founder Institute:
- You can keep you day job.
- You don’t have to relocate to Boulder.
- If you graduate you contribute 3.5 percent of your company to a pool that is owned by you and the other graduates and mentors from your class. You are quite literally invested in the success of your peers.
- The mentors are exclusively experienced CEOs and founders – no service providers.
If you are ready to commit 15 hours a week for 14 weeks to get your next business ready to launch, I look forward to helping you do more, faster (although, not too fast!)
And whether or not you launch your business, you will be a much better-informed founder when the time is right.
I’d like to thank Brad for the chance to blog in his space, and I’d like to thank Jon for his continuing effort to help the Colorado entrepreneurial ecosystem, because we all benefit when we have more, better founders in our universe.
Apply before the May 1 and let me know if I can help you with launching your business in 2011.
Looking For Several Startup Visa Supporters in Texas, California, and Virginia
If you support the Startup Visa and are in the congressional district for Congressman Lamar Smith (TX-21), Darrell Issa (CA-49), or Bob Goodlatte (VA-6) I’d like to talk to you – please drop me an email.
I spent a full day at MIT last month rolling around in a bunch of really cool tech. One of the meetings led to today’s Brad Feld Amazing Deal for OoOTies.
I had just sat through three meetings with MIT-related entrepreneurs – two who showed me new human instrumentation products and one who walked me through a new way to develop Android apps. The guy for my next meeting showed up, sat down, and started talking about bow ties. He was an MIT grad student who had become fascinated with bow ties and subsequently created a company called OoOTies along with an iPhone app. We had a fun conversation and then it was time for my next meeting.
At lunch time, I was with a group of MIT grad students who were working on a summer program for MIT students who want to be entrepreneurs. We were enjoying our fish chowder at Legal Seafoods when my new bow tie friend showed up with a bunch of bow ties in tow. Five minutes later everyone at the table had learned how to tie a bow tie and was sporting a new one.
One of the great things about my world is that I never know what to expect, so I just roll with whatever happens during the day. I’m off to TechStars New York Demo Day – looking forward to seeing what mysteries the world reveals to me. In the mean time, be bold and go buy a bow tie.