Adrian Cockcroft

I can think of four reasons for Oracle staying at Solaris 11.x instead of planning a new Solaris 12 release:

1. Some enterprises have a general policy of only running versions N and N-1 of software. The release of Solaris 12 would trigger a review of Solaris 10 in those environments, which would accelerate the trend away from Solaris. (The Solaris 10 to Solaris 11 upgrade is particularly disruptive due to the switch to IPS packaging and the networking changes, so migration to Linux is of comparable complexity.) Immediate loss of legacy support revenue for both Solaris and SPARC hardware.

2. Solaris 11 support is promised until at least 2031, or 2034 if customers pay for extended support [1]. A new release would just add another stream to support with at least 15 years of overlap.

3. The old SVR4 packaging was so slow and Live Upgrade so unreliable that new releases were required to stop patch bundles from getting too unwieldy. IPS is much faster and safer so it is more technically feasible to stick with the same major release.

4. I'd tend to agree with Adrian Cockcroft that the interesting things are happening elsewhere now [2]. There may not be enough reason for customers to upgrade. Oracle can avoid the story of a failed release by not doing the release in the first place.

[1] http://www.oracle.com/us/support/library/lifetime-support-hardware-301321.pdf

[2] http://perfcap.blogspot.com.au/2010/08/open-letter-to-my-sun-friends-at-oracle.html

The 80% number was for a "dedicated instance". A dedicated instance is not the same as a reserved instance.

Dedicated instances, charged on top of the regular price, are where you are guaranteed not to have anyone else on the same host server as you. Dedicated instances already cost 10% more than their regular counterparts (small/dedicated/on-demand costs 6.6/c hr vs 6c/hr.)

At any point, the most you could be "wasting", was the leftover capacity on a host that only had one small server on it (they didn't do micro). Imagine a simplified version of EC2 as per [1], which fits 12 small instances on one physical host, and you could therefore be wasting 11 slots that you could run a m1.small in. They can't sell these to any other customer. If you buy a second instance, they put that on your first host; you are now wasting 10 slots. Carry on down to when you fill up your first host and spill over onto a second, back to wasting 11 slots.

Previously they were charging $10/hour for those wasted 11 slots, which you could have filled by paying 72.6c/hr. Now, they're only charging $2.

[1] http://perfcap.blogspot.co.uk/2011/03/understanding-and-using-amazon-ebs.html

Thanks for sharing the experience. In your particular case it seems the right decision to move to a dedicated provider. The reasoning was similar to GitHub's (https://github.com/blog/493-github-is-moving-to-rackspace) Cloud environments make the most sense at either end of the spectrum. It works if you are Netflix, where the choice is not to purchase a few servers but build your own Cloud infrastructure (http://perfcap.blogspot.com/2011/08/i-come-to-use-clouds-not-to-build-them.html) or if you are getting started, when you are cash-constrained and there are a lot of uncertainties, allows you to run quick experiments etc. Take our case, we provide a cloud hosting tool (http://bitnami.org/cloud) but we don't run all of our systems there, they are divided between "traditional" providers (one of them Softlayer) and AWS. It is a bit of a pain, but for our current requirements and budget, it works nicely.

Adrian Cockcroft updated his blog post, which inspired this TechCrunch article, and clarified that he was not in fact referring to HTML5 video, as the TechCrunch article (currently) states.

"MG Siegler at TechCrunch decided that I was talking about streaming video and Silverlight, which I wasn't. I was thinking of HTML5 features that let us build very cool user interfaces with drag-and-drop, canvas transforms etc. for the web site, and for embedded TV devices specifically."

http://perfcap.blogspot.com/2010/05/netflix-in-cloud-and-html5.html

A blunt summary would be that everything is unreliable and disposable. You have to design for failure, because most things will almost certainly fail (or just slow down) at some point.

I learned a lot when I was first moving to the cloud from Adrian Cockroft. He has a ton of material out there from Netflix's move to the cloud. I recommend googling around for his conference talks. (I haven't watched these, but they're probably relevant: http://perfcap.blogspot.com/2012/03/cloud-architecture-tutorial.html)

Plainly they're not immune to _all_ failures; I think you've made a parsing error there.

http://techblog.netflix.com/2011/04/lessons-netflix-learned-from-aws-outage.html
http://www.zdnet.co.uk/news/cloud/2012/03/18/netflix-how-we-got-a-grip-on-awss-cloud-40095277/
http://perfcap.blogspot.com/2012/01/thoughts-on-simpledb-dynamodb-and.html

There's also all the "soft" statements they made; I'll let you search for them yourself.