Congratulations to RightScale!

It's great to see your projects (and friends!) find success. RightScale was a venture I helped co-found with Thorsten von Eicken in its pre-seeding stages. With my hands full with RightCart and ELC, I transitioned out of the team, but we have continued to collaborate with our customers to bring disruptive technologies into play for the right problems. RightScale just closed a round of funding from Benchmark capital--a great show of support of the concept, their vision and ability to execute. The RightScale team is filled with experienced leaders and it is exciting to see their success grow. RightScale today makes Amazon's platform usable for real businesses. This is much bigger than most people outside of the EC2 tech community appreciate. Two years ago if I mentioned EC2 or cloud computing the responses were "technology is great for grid computing and research" and "not ready for web applications." And they were right! There's a whole slew of reasons for this. Some technical--no static IPs, resilient hard disk devices, etc. Some are part of the adoption cycle--need evangelists and early adopters to prove out a platform before mainstream interest. Some were brought on by the vendors in the space--SUN had a grid computing platform that was 10x the cost of Amazon's EC2 and relatively "unsexy" for the web crowd; Amazon's approach was a bit fly-by-night in its early stages--and particularly (and purposely!) lacked support and management tools. The technology concerns have by-and-large been addressed by Amazon's offering of today--and then some. The adoption cycle has had time to prove itself with early and chasm-crossing wins. And RightScale has done WONDERS in terms of providing the know-how and infrastructure to make EC2 work for grid AND web applications. All working together--I have a different set of conversations with CIO's and technology leads today. They wonder why their organizations are trying to build NOCs and POPs at huge capital expense. They wonder why a new development initiative is stalled because of a committee-eqsue email exchange over who had priority rights to the power allotment remaining in a rack at an overburden internal West Coast datacenter (that's a real one!). They wonder why development partners like ELC are able to spin up entire development and staging configurations in a matter of minutes thanks to EC2 and RightScale--while they wait and wait for IT to respond. And the final straw is cost. When you run numbers on a web deployment, leaving room for growth, bursty traffic, auxiliary servers, staging and support servers--you find that EC2 is a great value for many, many applications. So a little sleight of hand happened--early adopters braved the wilds with Amazon. RightScale heard their pains and made solutions every step of the way. First it really was large grid users that were attracted with real budgets. But many web applications today have a HUGE grid component to them--think YouTube and all that backend video transcoding (user uploads to optimal-sized web-ready flash). So the next round of EC2 interest were part web apps and part grid apps--and RightScale helped tailor solutions for them as well. Amazon heard this as well and all parties moved towards an offering that really satisfies a nice portion of the web market today. And why does RightScale make EC2 ready for real businesses? Real businesses want someone to know their problems well and already have answers for them. What happens when an instance fails? Ask RightScale! How much redundancy should I build into my configuration and how? Ask RightScale! What type of monitoring do I need and what hooks into EC2 are there to leverage an automatic recovery? Ask RightScale! Amazon wants to engage these dialogs. Especially at the tech level--they have great insightful forums--but they don't want to be hand-holding their customers and setting best practices for network configurations. Without these answers, a business can't consider EC2 ready for business--and RightScale has the right team, experience and technology to provide really good solutions. Where to next? Commoditized servers are an interesting concept. It's reasonable to think of a commodity server platform as part of a component in a product deployment. In other words--when building a product--you need some processing power. BUT, the processing power needs to be told what to do at many levels--by code, by application/database configuration, and by network configurations. So you may have these areas of concern:

1. YOUR APPLICATION CODE
1. Ex: The coding logic and schemas behind RightCart.com, YouTube.com, or others.
2. YOUR LANGUAGE OF CHOICE
1. Ex: Ruby, Python, PHP, Java
3. YOUR FRAMEWORK OF CHOICE
1. Ex: Rails / TurboGears / CakePHP / J2EE
4. GLUE TO CONFIGURE A DEPLOYMENT
1. Ex: Ant / Capistrano / Shell scripts / By Hand
5. THE SERVERS
1. Ex: RackSpace / EC2 / Your IT Dept
6. THE NETWORK
1. Ex: Cisco routing config / EC2 groups / VM virtual nets
7. MONITORING AND UPKEEP
1. Ex: Monit / External Ping / Automated failover

The next step as I see it will be to decide which of these areas are high-value and advantageous to keep under ones organizational walls and which areas are low-value and advantageous to outsource to the best provider. Making all but (1) low-value means picking a direction like Google App Engine. But then again, that today implies a language/platform choice of Python and Google's infrastructure (http library replacements, etc)--which are often tightly linked into your team efficiency, problem domain and existing code assets. Maybe it won't be a necessary choice in the future--and Google or others will support your choice of deployment language and framework (like the way we used to guard our deployment OS of choice). Amazon is heading deep into #5 and gradually adding to #6. RightScale has attacked #4, #6, and #7 where it applies to the server infrastructure. Assuming the diversity of languages exists for a positive purpose--then that still leaves a good heaping of growth before #4-7 all "just work." In other words, can we imagine a day when develop an app in a framework of our choice and then hit "deploy to application engine: Google, Amazon+RightScale, M$ft.NET, Sun.Java." As long as we are jointly solving common web paradigms, this is--in my mind--where the next step leads.