« swipe left for tags/categories
swipe right to go back »
As a part of Startup Phenomenon, I’m going to spend a half hour with Jason Illian, the CEO of BookShout!, on Thursday, November 14th at 4:30pm. It’ll be at the Boulder Public Library, which is right across Boulder Creek from the St. Julien and downtown Boulder.
I’ve been a fan of BookShout! for a couple of years now.
As an author, I’m always looking for ways to connect with my audience. I spend time with the people from the local startup scene all the time but connecting with aspiring entrepreneurs from around the country, and around the global, is an entirely different beast. Comments on Amazon are one-directional, and definitely do not encourage reader-to-reader interaction. Buying a book in a bookstore is an individualistic experience. Getting a book at a conference means reading it after the conference is over, which doesn’t leave any time for in-person discussion or engagement.
Enter BookShout!. First glance, it’s nothing special. Simple but effective distribution of books. All the goods when it comes to commenting and rating. Where BookShout! really shines is how it brings an audience and an author together, on the same page – both literally and figuratively – and allows them to have an unfiltered conversation around the content of the book.
It’s a powerful tool for authors and an interesting site for readers. If you’re either, check it out.
And if you’re in Boulder tomorrow afternoon, for Startup Phenomenon or not, come on by the Boulder Library and hang out with me and Jason.
See you there!
RSVPs are requested. Please do so here. While you’re there, check out some of the Master Classes that Startup Phenomenon is offering.
The Second Edition of Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist just started shipping. It’s new and improved, fixes a bunch of little mistakes that we listed on the Ask the VC site, and adds a chapter on Convertible Debt which builds on the posts on Ask the VC. I’m happy it’s out, but really annoyed by the mess that is created by the second edition.
Before I bash Amazon and the traditional publishing industry, I want to give Amazon some love. I bought a Kindle Paperwhite 3G a month ago. Every time a new Kindle comes out, I buy it. After struggling to like the Kindle Fire HD, which now sits dormant in my laptop bag, I am absolutely in love with the Kindle Paperwhite- it’s stunningly good for a high volume reader like me.
Ok – back to the mess of a second edition. Writing the second edition is pretty easy – you get the final Microsoft Word files from the publisher. I would have loved to fix the mistakes earlier in the ebook, but that wasn’t part of the process. So Jason and I just tossed up an Errata page on the website and pointed people at it when they found a new, or old, mistake. We wrote the new sections (the chapter on convertible debt and a few appendices), fixed some other stuff we felt could be improved, and sent it back in to the publisher.
Given the success that we’ve had in academic settings, where Venture Deals is now being used by over 100 undergraduate and graduated courses as a textbook, we also created a teaching guide. Jason and Brad Bernthal wrote this as a completely separate book which we expected would be published. Instead, it’s ends up being on Wiley’s Instructor Companion Site which I just spent 10 minutes trying to get a login for an failed (grrrr). In addition, we are now working on an Inkling edition version of it which is desynchronized from the release of the book – mostly due to miscommunication about what was required to create it.
The normal copy-edit production loop ensued that I’m now used to. Jason and Brad Bernthal submitted the teaching guide separately – the first pass of the copy-edit loop happened, but had more gear grinding as we struggled to understand what was actually going to be produced. We eventually figured it out and everyone ended up happy. Then we got the new cover designs since apparently a second edition gets a new cover design. We are going to put this into the Startup Revolution series so it’s got the little Startup Revolution logo on it.
A few weeks ago I noticed that Amazon had Venture Deals: Be Smarter Than Your Lawyer and Venture Capitalist (2nd Edition) available for pre-order. I was perplexed that it was an entirely new page on Amazon with a different ISDN number. None of the 123 reviews moved over with it and the work we put into the page for the first edition was gone. I checked with Wiley on this and quickly found out that Amazon considers 2nd Editions to be completely new books.
So – here I sit on 12/29 with a new Amazon pages for the 2nd Edition in physical and Kindle form, excitingly with zero reviews on a book that has a 4.8 of 5.0 on 123 reviews, light weight Amazon pages, and no access or links to the Instructor Companion Site. Remember, writing these books is a hobby for me, not my full time role in the world, so when I see this I immediately think “there must be a better way.”
In this case, I’m perplexed by Amazon. It seems like they should be focused on making this stuff awesome from a user perspective and and author perspective. Even if there is a new ISBN number, wouldn’t it be so much better to have Venture Deals all connected together, with all the history, made beautiful and awesome for everyone involved? Who cares that the traditional publishing industry has a new ISBN number for 2nd Editions – end users don’t really care about this. And authors who want to spend all of their time writing and as little time as possible fighting with this crap must want to blow their brains out when this happens.
Fortunately, all of this amuses me. I enjoy the people at Wiley I work with – they are working their butts off on many different fronts to be successful. They are dealing with a complex environment that is changing quickly on them. And they are working as hard as they can to stay relevant in this environment. I respect them a lot for this. But it’s still a completely mess.
I just found out that Startup Communities: Building an Entrepreneurial Ecosystem in Your City made the Amazon Top 10 Business Books of 2012.
I’m not a huge “made that list person” but as a writer this is a very cool thing, especially when I look at the other books, and writers, on the list. I’m downloading all of the other books right now and taking them on my two week vacation which is coming up.
I’m at Defrag this morning listing to Kevin Kelly explain how the global super organism already exists and why it is different than the Kurzweil defined Singularity. Awesome – and extremely consistent with how I think about how the machines have already taken over. Kevin’s intellectual approach is clearer and deeper – which I like, and will borrow heavily from. Kevin’s book, What Technology Wants, is also in a swag bag and I’ll be reading it next week.
One of the powerful concepts is that the “city is the node.” As I’ve been talking about Startup Communities, I’ve been explaining the power of “entrepreneurial density” and why everyone is congregating around cities again (intellectually referred to as the reurbanism of American). It’s really cool that he’s using the Degree Confluence Project to “show” (rather than simply “tell”) this.
A few of the books on the Amazon Top 10 Business Books of 2012 touch on this theme – I’ll be looking for it as I read a lot on the beach the next few weeks.
Thanks to all of you who participated in Operation Pre-Order for Startup Communities. I got a bunch of fun emails and am excited to share my newest book with you.
The Amazon winner is Jess Bachman. He’s from Bowmanville, Ontario which Google shows me is an hour east of Toronto. Hopefully we can connect during my Toronto trip in October.
The BarnesandNoble.com winner is Chris Rill from Mamaroneck, NY. I’ll catch him on my next NY trip.
The ratio of Amazon to B&N started out about 10:1 but ended up at 6:1. Later entries thought about it and figured out that odds were better if they bought from B&N since they guessed that more people would buy from Amazon. They were correct!
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.