As I noticed quotes from the Code Conference dominate my Twitter feed yesterday, I saw a few from the Jeff Bezos interview that made me say out loud “Jeff Bezos is amazing.” I love his use of the phrase “cultural norms” (it’s one of my favorite phrases) and I particularly thought his comments on Donald Trump and the Peter Thiel / Gawker situation were right on the money.
The interview prompted me to think about how biases affect my thinking. I’ve been struggling with the Peter Thiel / Gawker stuff and have asked a few friends closer to the situation and the people involved to give me their perspectives as I’ve tried to determine whether my biases are overwhelming my perspective on it. As a result, I haven’t discussed it publicly, and instead have thought harder about it at a meta-level, which is actually more interesting to me.
I don’t know Jeff Bezos and have never met him, so my strong positive reaction to the interview reinforced this notion around unscrambling my biases as part of better critical thinking. If we use Amazon as an example, my relationship with the company, and my corresponding experiences over the years, have created a set of biases that I map to my impression of Bezos. And, as you read though the list below of my experiences / viewpoints, you’ll quickly see how the biases can create a chaotic mind-mess.
Following are the quick thoughts that come to mind when I think about Amazon.
- Love it as a customer
- Frustrated with how they have handled relationships with companies I’m an investor in
- Delighted with how they have handled relationships with companies I’m an investor in
- Moments of misery with interactions around difficult things
- Brilliance and clarity of thought from Bezos
- Wasted money on Amazon products that sucked
- Amazing delight with Amazon products that I use every day, including my Kindle
- Sucky experience as an author
- Distribution that otherwise wouldn’t exist for me as an author
- Many friends at Amazon
- Sympathy for the stupid way Colorado has dealt with them around affiliates and sales tax
I could probably come up with another 50 bullet points like this. Given that Bezos is the CEO and public face of Amazon, I map my view of the company to him. I know that is only one dimension of him – and his experience as a human – but it’s the one that I engage with.
Then I remember we are all human. Shit is hard. We make lots of mistakes. And, when I sit and listen to Bezos talk to Walt Mossberg, I have an entirely new level of amazement, appreciation, and intellectual affection for him, and – by association – Amazon.
I know that many different kinds of biases get in my way every day. I’ve learned the names for some of them, how they work, and how to overcome them through various work of mine over the year. But at the root of it, I realize that a continuous effort to unscramble them when confronted with something that has created dissonance in my brain is probably the most effective way to confront and resolve the biases.
For those of you in the world who tolerate me saying “what do you think of thing X” and then give me a thoughtful response, thank you, especially when you know I’m wrestling with trying to understand what I think about X. Now you know that part of what I’m asking you to help me with it to unscramble my biases around the particular person or situation that is represented by thing X.
I expect most of you know the fable of the scorpion and the frog, but if you don’t, it goes like this (quoted from Wikipedia):
“A scorpion asks a frog to carry him over a river. The frog is afraid of being stung during the trip, but the scorpion argues that if it stung the frog, both would sink and the scorpion would drown. The frog agrees and begins carrying the scorpion, but midway across the river the scorpion does indeed sting the frog, dooming them both. When asked why, the scorpion points out that this is its nature. The fable is used to illustrate the position that no change can be made in the behaviour of the fundamentally vicious.”
Over the weekend, there was some commentary on AWS in fight of its life as customers like Dropbox ponder hybrid clouds and Google pricing. Amazon turned in slightly declining quarter-over-quarter revenue on AWS, although significant year-over-year quarterly growth, as explained in Sign of stress or just business as usual? AWS sales are off slightly.
“Could Amazon Web Services be feeling the heat from new public cloud competitors? Maybe. Maybe not. Second quarter net sales of AWS — or at least the category in which it is embedded– were off about 3 percent sequentially to $1.168 billion from $1.204 billion for the first quarter. But they were up 38 percent from $844 million for the second quarter last year. In the first quarter, growth in this category year over year was 60 percent. So make of that what you will.”
Could Amazon’s nature be catching up with it, or is it just operating in a more competitive market? A set of emails went around from some of the CEOs of our companies talking about this followed by a broader discussion on our Foundry Group EXEC email list. It contained, among other comments:
- AWS is not the low price provider.
- AWS is not the best product at anything – most of their features are mediocre knock offs of other products.
- AWS is unbelievably lousy at support.
- Once you are at $200k / month of spend, it’s cheaper and much more effective to build your own infrastructure.
While we are in the middle of a massive secular shift from owned data centers to outsourced data centers and hardware, anyone who remembers the emergence of outsourced data centers, shared web hosting, dedicated web hosting, co-location, and application service providers will recognize many of the dynamics going on. Predictably in the tech industry, what’s old is new again as all the infrastructure players roll out their public clouds and all the scaled companies start exploring ways to move off of AWS (and other cloud services) into much more cost effective configurations.
Let’s pick apart the four points above a little bit.
1. AWS is not the low price provider. When AWS came out, it was amazing, partly because you didn’t need to buy any hardware to get going, partly because it had a very fine grade variable pricing approach, and mostly because these two things added up to an extremely low cost for a startup relative to all other options. This is no longer the case as AWS, Microsoft, and Google bash each other over the head on pricing, with Microsoft and Google willing to charge extremely low prices to gain market share. And, more importantly, see point #4 below in a moment. Being low priced is in Amazon’s nature so this will be intensely challenging to them.
2. AWS is not the best product at anything – most of their features are mediocre knock offs of other products. We’ve watched as AWS has aggressively talked to every company we know doing things in the cloud infrastructure and application stack, and then rather than partner eventually roll out low-end versions of competitive products. We used to think of Amazon as a potential acquirer for these companies, or at least a powerful strategic partner. Now we know they are just using the bait of “we want to work more closely with you” as market and product intelligence. Ultimately, when they come out with what they view of as a feature, it’s a low-end, mediocre, and limited version of what these companies do. So, they commoditize elements of the low end of the market, but don’t impact anything that actually scales. In addition, they always end up competing on every front possible, hence the chatter about Dropbox moving away from AWS since AWS has now come out with a competitive product. It appears that it’s just not in Amazon’s nature to collaborate with others.
3. AWS is unbelievably lousy at support. While they’ve gotten better at paid support, including their premium offerings, these support contracts are expensive. Approaches to get around support issues and/or lower long term prices like reserved instances are stop gaps and often a negative benefit for a fast growing company. I’ve had several conversations over the years with friends at Amazon about this and I’ve given up. Support is just not in Amazon’s nature (as anyone who has ever tried to figure out why a package didn’t show up when expected) and when a company running production systems on AWS is having mission critical issues that are linked to AWS, it’s just painful. At low volumes, it doesn’t matter, but at high scale, it matters a huge amount.
4. Once you are at $200k / month of spend, it’s cheaper and much more effective to build your own infrastructure. I’ve now seen this over and over and over again. Once a company hits $200k / month of spend on AWS, the discussion starts about building out your own infrastructure on bare metal in a data center. This ultimately is a cost of capital discussion and I’ve found massive cost of capital leverage to move away from AWS onto bare metal. When you fully load the costs at scale, I’ve seen gross margin moves of over 20 points (or 2000 basis points – say from 65% to 85%). It’s just nuts when you factor in the extremely low cost of capital for hardware today against a fully loaded cost model at scale. Sure, the price declines from point #1 will impact this, but the operational effectiveness, especially given #3, is remarkable.
There are a number of things Amazon, and AWS, could do to address this if they wanted to. While not easy, I think they could do a massive turnaround on #2 and #3, which combined with intelligent pricing and better account management for the companies in #4, could result in meaningful change.
I love Amazon and think they have had amazing impact on our world. Whenever I’ve given them blunt feedback like this, I’ve always intended it to be constructive. I’m doubt it matters at all to their long term strategy whether they agree with, or even listen to, me. But given the chatter over the weekend, it felt like it was time to say this in the hope that it generated a conversation somewhere.
But I worry some of the things they need to be doing to maintain their dominance is just not in their nature. In a lot of ways, it’s suddenly a good time to be Microsoft or Google in the cloud computing wars.
As we gear up to release Uncommon Stock, our first FG Press book, we just had an internal discussion about book blurbs. The concept of a blurb was apparently invented in 1907. The origin story of the blurb is amusing – according to Wikipedia:
“The word blurb originated in 1907. American humorist Gelett Burgess’s short 1906 book Are You a Bromide? was presented in a limited edition to an annual trade association dinner. The custom at such events was to have a dust jacket promoting the work and with, as Burgess’ publisher B. W. Huebsch described it, “the picture of a damsel — languishing, heroic, or coquettish — anyhow, a damsel on the jacket of every novel” In this case the jacket proclaimed “YES, this is a ‘BLURB’!” and the picture was of a (fictitious) young woman “Miss Belinda Blurb” shown calling out, described as “in the act of blurbing.”
While the history lesson is cute, the blurb has long since ceased to be useful. As a reader, I’m incredibly suspicious of them because as a writer, I know how they are manufactured. More on that in a bit, but for now, take a few minutes and check out some #HonestBlurbs.
Our internal back and forth on whether to include blurbs on our FG Press books resulted in the following rant from me.
I think endorsements like this are bullshit. I’m literally getting asked daily (5 times / week – sometimes more) to endorse books. I used to do it, now I say no unless it’s a friend, and even then they usually write the endorsement.
It’s an artifact of the publishing business that existed before “earned media” – blog posts, reviews, etc.
I’d love to just BLOW UP blurbs.
I think we should be focusing on real earned media, real reviews, real substantive support, rather than marketing nonsense the industry has been pushing since the early 1900s.
We had a little more back and forth but the more I thought about it, the more I have no interest in blurbs. I’ve been saying no to a lot of the requests I get recently, after having my name on probably 50 blurbs for other books in the last few years. At first, I always read the book before writing the blurb. Then, I started skimming the book before writing the blurb. Recently, I’ve been either asking the writer to send me a draft of the blurb they’d like, or I’ve just said something generically positive but non-substantive.
I’ve watched the other direction work the same way. It’s similar to press release quotes – it ends up being manufactured PR stuff, rather the authentic commentary. The idea that a static, short, manufactured blurb from a well known person as an endorsement of a book is so much less authentic than Amazon reviews, GoodReads, and blog posts from people who actually read the book.
When people send me a note that they liked my book, I ask them to put up a review on Amazon if they are game. When someone writes with constructive feedback on a book I’ve written, I ask them to put up a review on Amazon, with the constructive feedback, if they are game. I appreciate all the serious feedback – both good and bad. Sure – I get trolled by some people who say things like “Feld is a moron, this book is another stupid thing he’s done.” I ignore that kind of thing, and feel that most rational humans can separate the signal from the noise.
So, at least for now, we aren’t going to do blurbs on FG Press books. Instead, we’ll ask people to put up reviews on Amazon, GoodReads, their blog, and other sites that make sense. And, when someone requests a blurb from me, I’m going to start passing and defaulting to writing a review on this site and putting up the review on Amazon on GoodReads, like I have for many of the books I’ve read.
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.
Colorado HB10-1193 – also known as the “Amazon Tax” – really upset me as I wrote about in Amazon Fires Its Affiliates in Colorado (Including Me) Because of Colorado HB 10-1193. While I discovered a partial solution via a service from a company called Viglink which I wrote about in I’m An Amazon Affiliate Again – Sort Of I’m still really annoyed with the myopia of our Colorado state representatives around this issue.
I’m also disgusted by the protectionist turn this took as our governor, many representatives, and several progressive organizations that I’ve supported called for a ban on Amazon because of the need to “level the playing field for local merchants.” When I talked to a number of folks about this, including the organizations that I had previous supported, they demonstrated that they didn’t really understand the issue, were getting confused about states rights vs. federal rights (an issue I expect we’ll see come up a lot over the next few years given our federal, state, and local government search for additional revenue wherever they can find it), and didn’t get that a protectionist attitude was actually offensive to most business people (except, presumably, those being protected by the government.)
Finally, legislation like this is completely tone deaf to both the growing impact of technology on our society as well as a huge shift in the way information based goods are bought and sold.
I’ve been told by several Colorado representatives that didn’t support this bill that there is no way this tax will be repealed, but I haven’t given up yet. I’ve enlisted my friend David Binetti to crank up another Twitter Campaign To Repeal Colorado’s Internet Tax. If you are a Colorado citizen with a twitter account, it’ll take less than a minute to tweet out this message along with delivering a physical letter to your specific representatives.
Let’s make sure our representatives know that this is a piece of legislation that should be repealed.