Solaris 8 Vintage Support

As well as providing the sustaining engineering for the newer versions of Sun's products we also get to manage them once development really stops and they eventually go into EOL and finally EOSL, Solaris 8 recently went from what is known as phase 1 into phase 2 support, in fact in the last two months, on April 1st.

When Solaris reaches this phase in its lifecycle we offer what is called a "Vintage Patch Service". I often get asked when Solaris reaches this stage in its lifecycle what does it all mean and why.

Solaris 8 first shipped in February 2000 and was in the planning for a few years before that, Sun has released two versions of Solaris since then and you can already see where Solaris is heading by using OpenSolaris (which incidentally is what I'm running on my laptop I'm typing this on, but that is another blog entry).

Like all things Solaris 8 is starting to reach its limits and in some cases is being pushed beyond its design limits, which results in all sorts of performance impacts in the field, it also does not support our latest generation of HW platforms, such as the recently announced Nehalem chipset from Intel and our Niagara architecture in any form.

The hardware which Solaris 8 was designed to run on is also approaching EOL to varying degrees, plus in these economic times Sun has hardware like the aforementioned Niagara based machines that bring many benefits.

It is kind of like owning a car, you keep it and keep it and you keep spending money on it, but eventually you get to a point in time where you need to do that major upgrade and all of sudden you have a new car with a manufacturers warranty and your saving money on that, running costs etc.

Sun recognises the impact of such major upgrades and provides many things to make everyones life easier Solaris 8 containers for example and our Application Binary Guarantee which seems to be one of our best kept secrets. In simple terms what it says is that if you follow the published stable interfaces and write your application to them if you compile it on that release of Solaris you can pick up your application and run it on later releases with no recompilation necessary. The legal boys will now tell you it has some caveats, and it does but I've seen great success where people have "just done it" and I cannot think of a case where it has failed if people have followed the rules.

I've also seen a number of our large accounts use the Solaris 8 container technology and move everything from a Solaris 8 machine and pick it up and put onto a newer platform running Solaris 10 under the hood and in many cases with multiple machines now consolidated onto one newer platform.

The cost benefit in doing this was described to me by one customer like this..."I need to spend $ on new applications but I have an ever shrinking IT budget. By using Solaris 8 containers I was able to consolidate my existing estate (a lot of E450 type machines) onto the T series platforms and with the savings I made on HVAC plus maintenance cost reductions I had the $ I needed to re-invest in application development and deployment." which is great and especially as that was one of the reasons we designed the product and it does as they say "exactly what it says on the tin".

I also get asked why you have to pay extra to keep getting engineering support on Solaris 8 in phase 2, it is simple really, Solaris keeps marching on and otherwise we'd move that resource onto developing the next generation of products. Again back to the car analogy as parts become in short supply and with continuing demand the price goes up.

I've worked with a lot of customers over the last 9 months since we announced this programme and a lot of account teams, the business arguments for migrating are compelling even for an engineering guy and even more compelling in these economic times.


Post a Comment:
Comments are closed for this entry.

Chris is the Senior Director of Solaris Revenue Product Engineering


« June 2016