At first glance, I might not seem like the typical candidate for the Founder Institute. I'm not a fresh entrepreneur. I've been doing it a long time and I've had both favorable outcomes (acquisitions) and failures (losing a lot of money). And I even serve as an advisor and mentor to a lot of other entrepreneurs. But, through it all, two things have remained constant: I'm an entrepreneur at heart, and I have a lot to learn.
And those two things are the key reasons that I'm excited that I just got accepted to be part of the Founder Institute's winter session in Seattle.
What is an entrepreneur anyway? I'm not giving anything away to tell you that the first question on the application form is why you want to be an entrepreneur. And I certainly hope I'm not giving anything away by saying I think it's a trick question. Maybe you can want to be a good entrepreneur, or a successful one, but I think being an entrepreneur in the first place, like being a writer, or a musician, or an artist, is about being true to yourself. Do you want to build things? I know I do! I love the challenges of figuring out the problem and figuring out the solution. And I love making something out of nothing. The opportunity to be around a bunch of other like-minded people over a three-month span would be valuable all on its own.
What do I have to learn? Tons, it turns out. Earlier this year, I wrote the absolute best business plan I had ever written. I created the best presentation decks I had ever written (although I didn't present them that well, ironic for someone who's a very good public speaker). I had a pretty good prototype to go with them. And it was for a business that I really think could make it and be hugely profitable. I'm a CTO, a product guy, and, yes, a visionary (though I don't really care for that term). But, I'm not a CEO and I was trying to start a company that really needed one. In looking at the Founder Institute curriculum, about 90% of the content is centered around the areas that I'm weak in, the places where I still have a lot to learn. If this were CTO camp, I could teach it. But it's a business camp and I'm happy to be a student.
And that brings up the third piece of the picture. I had the good fortune to run into Chris Early, the local person from FounderWise who's running the Seattle session, at an NWEN breakfast a week ago. I'd been thinking about applying but wasn't sure. Chris impressed me with his vision, understanding, and focus. He pushed me over the edge with information. They're looking for a wide range of people, from fresh entrepreneurs to veterans, they're hoping for a mix of talents, meaning both technical people and business people, and they're expecting a variety of representative industries, not just high-tech. But the common thread they're looking for is people who will take what they learn and run with it. All the mentors (aka instructors) are selected for the sessions they're teaching based on their specific knowledge. Each week, there are three different instructors who are best suited to the topic at hand. The sessions aren't those cattle call lectures we all remember from college. They'll be much more interactive and there's out-of-session "homework" every week. I can't predict exactly what all that means, but I loved how Adeo asked each person who asked a question at the UW session what they were passionate about. The Founder Institute isn't about one-way communication or lectures from on high. It's about guidance and learning. And that sounds good to me.
I don't know if the Founder Institute is right for you. It depends on who you are and what you want to do. But I'm really looking forward to it.
Tuesday, November 24, 2009
The Founder Institute
Wednesday, November 18, 2009
I Want To Like Microsoft Azure
I want to like Microsoft Azure. I really do. I've been using Google App Engine for more than a year now (Puzzazz, SeattleTechCalendar and the FriendMosaic front end run on it). I'm also familiar with Amazon's Elastic Computing Cloud or EC2 (the FriendMosaic back end runs on it). Both have advantages and disadvantages.
Google App Engine is a wonderfully scalable system that requires programming to a very specific, narrow API and use of Google's BigTable database rather than a more traditional SQL database. It's super easy to get going (literally, you can have an app running in the cloud within minutes of installing the SDK). Scaling is completely, totally automatic, and you pay for the capacity you use, when you use it. But, App Engine isn't appropriate for apps that require a lot of processing power, and you can't easily take the application elsewhere.
In contrast, EC2 is very flexible. You can run Unix, Linux, or Windows on virtual machine instances and you get pretty complete control of these instances, as if they were real servers. And, if you grow big enough to afford your own servers, its easy to move those instances to your own physical boxes. But, it's much more of a pain to get going and scaling is awkward. You have to allocate complete instances of different sizes as if you're deploying real hardware and to change your capacity to respond to changing needs, you have to add or remove instances. If an instance crashes, you lose any local storage on the machine. And, you pay for active instances even if they are sitting there doing nothing.
When I first heard about Azure, I thought it was a brilliant way to split the difference and get the advantages of both systems -- a wonderfully scalable system with great flexibility. Sadly, Microsoft has produced the exact opposite -- a poorly scalable system which requires developing to a special API that limits flexibility. In other words, the disadvantages of both systems.
Azure uses instances, just like EC2, which means that scaling is by instance, not automatic. At launch, apparently you'll be able to configure this to happen semi-automatically, but it's still the case that you have to run an entire instance even if you have no traffic for it and you have to decide when additional instances get added and what capacity they have, instead of having it just work, as Google has done with App Engine. And, Azure isn't Windows. You can't just take a Windows application and plop it onto the box. In fact, you don't control the virtual box. You can't install helper applications on it. Instead, you have to program to the Azure APIs, meaning can't easily take an Azure-based app elsewhere (or take a non-Azure app and just have it work, like you can with EC2).
It's not too late. Azure does have some of the advantages of both App Engine and EC2 (a simple model, flexible, powerful), plus Azure has some nice advantages all its own. The way they've defined roles is very nice (especially if they clean up the definition of the worker role, which I'm assuming they will) and potentially more flexible than the App Engine way of doing everything through a URL. A certain amount of sandboxing can be a good thing. And, of course, C# can be a joy to program in, with the best IDE and debugger on the planet (I'm still waiting for a decent Python debugger).
And, really, there's only one (big) change necessary. Azure needs to automatically scale, so developers just create code for the roles and everything else works, with as much hardware as necessary allocated on demand (and not allocated when you don't need it). With their architecture, Azure could accomplish this really well, if they choose to do so. Then they can add additional role types with different feature, performance, and scaling properties. But, if they don't do this, I don't know why anybody would use it over the competition.
Update: Microsoft has created a new site MyGreatWindowsAzureIdea tbat's worth taking a look at. It's a voting site using UserVoice. The current top votegetter is "Make it less expensive to run my very small service on Windows Azure," with twice as many votes as the runner-up.