The firm that swallowed the Sun: Is Oracle happy as Larry with hardware and systems? One Sun swallow doesn’t make a hardware summer, and while it certainly hasn’t for Oracle, it is far from being in a hardware winter for the firm. Oracle's gulp of Sun Microsystems on 27 January 2010 – five years ago today – has resulted in a generally flagging Sun hardware product business and the growing Engineered System …
The Oracle aquisition of Sun makred the beginning of the end of my Solaris affair. We were already migrating to Linux and that speeded things up. Sun had it's problems but you could get to a human with a brain stem when you needed support and it was (more or less) affordable. Oracle support was a pile of poo and the Oracle support tool a dogs dinner. It was impossible to argue that we should not just buy commodity hardware that could run Windoze or Linux as needed. Ergo no need for SPARC hardware.
i know we were small beer as far as Sun and Oracle were concerned but there were a lot of organisations like us around. Now I work for a university and they are trying to get rid of their Sun kit and migrate to Intel with linux. If Oracle had continued to support OpenSolaris it might have become a real competitor to Linux which would have benefited the Open Source community but they pulled the plug on that. They also messed up with Open Office for what that is worth.
I don't see a long term future for the SPARC hardware which is a shame.
>I don't see a long term future for the SPARC hardware which is a shame.
Indeed. Sparc has the potential to be far better than the crufty old x86 with all its historical baggage. But Sun really only have themselves to blame for their demise - continuing to charge ridiculous money for systems when PCs were beginning to match them. 10K for a Ultra desktop with the same performance as a P3? Who were they kidding? Not the customers thats for damn sure who walked.
And that comment hides the bigger problem with Oracle's acquisition of Sun.
I understand from a friend who use to use their kit at work that Oracle's price boosts made Sun's pricing seem reasonable. Within a year of Oracle acquiring Sun, they replaced all their Solaris systems with Unix because it was cheaper than buying Oracle support contracts. This friend once bought a data array from Sun and got the computer kicked in for free. OK, not really but it was the end result. He priced out an array, priced a Sun system with an array of the same size, and the Sun system with array was cheaper than just the array. So I count is as them kicking in the computer for free.
>Sun had it's problems but you could get to a human with a brain stem [...] Oracle support was a pile of poo
ex-Sun UK Solaris/SPARC support engineer here.
Don't blame Oracle for ruining Sun support - Sun were actively engaged in doing that for years before the purchase. e.g. We were outsourcing L2 support functions to Poland as early as 2005. Financial pressure on the company made it inevitable I think.
The support from Poland was fine, considering the pitiful access they had to Sun hardware. They had some good brains out there with creative solutions to problems.
Sun's demise was an example of the triumph of marketing over product quality. it's a bit ironic that another marketing driven company* bought them and heartening that the marketing company have finally realised that they have a have high quality products to sell.
*I will grudgingly admit that they gradually turned a technically inferior database into something that was at least rock solid.
Where Oracle is weak is in supplying public cloud providers and web-scale app service suppliers such as Amazon, Facebook and Google
To be fair to Oracle (Not something I'm comfortable doing) IBM, HP, Dell, Cisco, et al probably don't have much traction in that area either. Don't Facebook, Google, and I'm guessing Amazon, cut their own servers?
I am a lowly programmer not versed in ways of big hardware but I wonder if someone can explain to me why anyone would buy Sun / Oracle systems over a system built from regular x86 servers? I realize by buying Oracle you are getting a package but I'm sure similar packages are available with more mainstream hardware. It seems to me that by buying Oracle you are locking yourself into a single vendor essentially for ever. I can understand how companies that grew up with development of computing would be locked into Oracle but surely any business making the choice now would go x86 (and probably Linux)?
The short answer is massively better performance for some workloads. Database reports than took hours on x86 systems, and run in minutes on optimized SPARC-based systems, for example.
General-purpose hardware is fine for general-purpose problems, but at a certain point, for certain workloads, it runs out of steam. Not that the x86/Linux folks who've never used really big systems want to believe that, of course.
Why do you believe that Sun/Oracle systems would be a lock-in anymore than choosing HP servers would be a lock in to HP (HP blades only run in HP blade chassis for example), Linux is a lock in to either RedHat or SUSE for the enterprise (can't get RHEL Linux support from SUSE or vice versa), or for that matter, choosing an iPhone from Apple where you can't install someone else's OS, etc?
At the end of the day, you need to pick a vendor that will be your support provider and having one vendor that could possibly support the entire HW/SW stack will clearly reduce risk and certainly costs. The days of building your own infrastructure from multiple vendors and the complexities that come with integrating & supporting it are quickly disappearing.
Oracle's end to end product line are in no way a lock-in, especially not for the hardware. Oracle leverages both standard Intel x86 Xeon architecture, selling both standard x86 servers as well as Engineered Systems based on x86 (wnd SPARC) as well as developing its SPARC systems (which are actually based on IEEE open standard and Fujitsu also sells/manufacturers their own version of SPARC), and so all of which offers choice and are just as easy to move on to the platform as it would be to get off, therefore not getting "locked-in". Sure, choosing Linux, or Oracles own branded Linux or Solaris (runs on both x86 and SPARC) are choices to be made, however any of these support multiple architectures and vendors and are fully mission critical ready for the CLOUD and digital transformation going on today.
@Phil 4 - "can't get RHEL Linux support from SUSE or vice versa"
Yes you can! If you switch from RHEL to Suse, Suse will support your existing RHEL servers. Suse claim that their prices are half of those of Red Hat. Furthermore, seeing as we are talking about Oracle, Oracle's own Linux is simply a clone of RHEL.
What is more, pretty much any of the bog standard packages such as mail, print, file, or web servers are available and supported on all major Linux distros. All distros offer the same packages from the same sources (minus some of the more obscure stuff for some distros). What distinguishes between them is the quality of their software integration and support. The software is free, it's the support that you pay for. Switching between distros is quite feasible, and companies do switch suppliers from time to time. You really can make a realistic threat to switch when you sit down to contract negotiations.
The reason why customers like Linux is that it gives them what they always wanted from Unix but never really had - market competition.
"The reason why customers like Linux is that it gives them what they always wanted from Unix but never really had - market competition."
OK. Show me working the same stable equivalent of ZFS, DTrace or end2end consistency data checking on Linux.
Specially ZFS still has no working equivalent on Linux (btrfs still is not supported by any company .. even RH is not supporting it)
Core functionalities of ZFS comes from using free list instead allocation structures. Variable record size, COW with transactional semantics, RAID not on block devices level but on each block level, ARC, L2ARC .. and Solaris shadowfs (which can be used without zfs as well)
After more than decade when DTrace and ZFS are available in source code these technologies are still not even closer to gain on Linux mature form.
@IOS6 user - "Specially ZFS still has no working equivalent on Linux (btrfs still is not supported by any company .. even RH is not supporting it)"
Btrfs is supported in Suse, and has been for several years. It's their default file system. I suggest that you really ought to read up on what Linux is like, you seem to be very unfamiliar with it.
> Btrfs is supported in Suse, and has been for several years. It's their default file system. I suggest that you really ought to read up on what Linux is like, you seem to be very unfamiliar with it.
You must distinguish between providing some technology and supporting it commercially.
All Linux distributions now allows you to use btrfs but it doesn't mean that SuSE will take responsibility fixing some issues if problem will be found under commercial support.
@IOS6 user - "You must distinguish between providing some technology and supporting it commercially. All Linux distributions now allows you to use btrfs but it doesn't mean that SuSE will take responsibility fixing some issues if problem will be found under commercial support."
Here's what SUSE says in their release notes: "With SUSE Linux Enterprise 11 SP2, the btrfs file system joins ext3, reiserfs, xfs and ocfs2 as commercially supported file systems." Note that SLES 12 is the current version, and this change came in with SLES 11, there previous release, so it's not all that new.
So, BTRFS is in fact commercially supported by SUSE and that isn't a new thing either.
>Specially ZFS still has no working equivalent on Linux
These technologies are really good (on larger systems), but a major reason Solaris/SPARC is declining anyway is that some of the really cool stuff doesn't matter to business or it runs into natural barriers.
There was a time when the more expensive and reliable electronics in SPARC systems were critical. These days everyone who would spend extra to get that reliability puts in redundant systems & sites anyway... and then much of the need for enhanced reliability on one site/system goes away.
Don't get me wrong, I started my unix life on Solaris/SPARC and I like it, but the days of needing it to host the corporate services for reliability reasons, are over, not because the PC is more reliable, but because the architectures are more reliable. The reliability requirement has moved from the compute engine to the load-balancer. Oracle just use SPARC to push their services which is fine and is very lucrative for Oracle, but probably not needed elsewhere. Mirror your transaction journal and replay it if you need to. Yes DTRACE is very cool. Do you have the techies needed to use it properly though? Not many companies do. Not many companies want to.
Obviously there are instances where you really do want reliability in the compute engine. SPARCs and PowerPC etc are still there for the midrange and mainframes for the top end of that requirement. I think it makes sense for service providers (such as Oracle) because the enhanced reliability makes problems go away and you would have decent techies anyway. Problems are always more "catastrophic" when third-parties are involved than if your own IT dept messed up..
Perhaps its just me, but if I were planning and I had the choice of going SPARC or putting in F5's, I wouldn't be going with the SPARCs.
Some of the problems come from the applications end. The big IT suppliers including Oracle, SAP, IBM, and Microsoft have been buying up small to medium size business application companies, primarily to get their customer base. Once they get their mitts on the new product, they "integrate" it with the rest of their product line and drop support for anything belonging to their competitors.
The reason to buy oracle/sparc instead of several cheap x86 servers is simple. There are workloads (typically business workloads or databases) that can not run fast on a cluster. You need a large SMP server with as many as 16 or even 32 sockets. In fact there have never existed a larger Linux server than 8 sockets (standard IBM/hp/oracle servers). I invite anyone to post links to a Linux server with more than 8 sockets. And unix servers such as IBM p795 with Linux tucked on top, does not count. It is a unix server, not a Linux server. Besides, Linux scales awful beyond 8 sockets, google big tux. It is a hp unix server with 40% CPU utilization running Linux! under full load.
All large Linux servers with 10.000s of cores, such as SGI altix or UV2000 servers or ScaleMP servers, are clusters. And are exclusively used for HPC number crunching workloads, serving one scientist. In contrast, tightly coupled SMP servers such as huge Unix servers with 32 sockets or IBM mainframes, typically run business workloads serving thousands of users.
Clusters run number crunching for loops in separate nodes with bad latency to nodes far away, you can not run monolithic software, all code is embarrassingly parallel. In SMP servers you run code that branches everywhere with good latency to other CPUs, such as business or database workloads. No one use distributed databases for large workloads, it is too difficult to synchronize data between all nodes. It is much cheaper to buy a huge 32socket unix server.
In fact, SGI and ScaleMP both say their servers are not used for business SMP workloads, and instead only are used for HPC number crunching, I have links where they say that.
Oracle will release the spare m7 CPU with 32 cores, this year which is at least twice as fast than the fastest x86 CPU, and power8 (probably much faster than so). One CPU can do 120GB/sec SQL queries (no typo, x86 and power8 can do... 5gb/sec queries?). It is also immune to the heart bleed bug and others, because of unique security functions. The m7 server will have 32 sockets, 64TB ram and 8.192 threads. It will crush everything. SAP talks about HANA their distributed clustered ram database, but you need a single SMP server for true database performance. With compression you can run very large databases from memory in the sparc M7 server. Wicked fast. A cluster with x86 stands no chance.
And with the SPARC hardware, you can also:
o Use zones or LDOMs for mass consolidation for no extra cost.
o Easy upgrade and patching of OS.
o Ops Center included with maintenance contract for building and patching servers.
o Add one of the flash devices which will allow you to boost your database's performance with the Oracle DB flash cache feature -- one of the features that drives ExaData.
o And some of the other usual perks with Solaris: ZFS, Dtrace, binary compatibility
o Anyone using Oracle DB 12c?
I've also seen a SPARC SuperCluster clobber HP's beefy ArcSight config. It did such a good job HP wanted information on how it was done. SuperCluster comes with some ExaData storage nodes, and being able to run the Apps on the SPARC nodes gave great performance. I would not be surprised if HP didn't try to re-pkg it as a solution for ArcSight if they aren't already.
'Lock-in' is a very over-used term, and almost always when someone is trying to justify why someone should choose opensource or generic x86 rather than something else. The reality is that most layers of the architecture below the application are fairly interchangeable. Linux as an OS will run on almost any hardware, and most of the (decent) middle tier platforms will care little about the OS.
e.g. Oracle database is available on a number of operating systems and CPU types, and Oracle databases running on Windows, Solaris, HP-UX, Linux and AIX are pretty much exactly the same with no database functionality or interface difference. Even when running on the Engineered Systems described above, the application level database functionality is exactly the same.
Obviously switching between database platforms is a little harder, but many applications support this as it's fairly easy to stick an abstraction layer between the database and the application (JDBC, Perl DBI Python SQLAlchemy etc). If your application is tied to a certain database vendor then that's the application designer's fault, not the database vendor. Similarly with middleware, if written to reasonable standards then a switch of container should not be an issue.
Application level switching is harder of course as there are no useful standards for interopability. When the application is in the cloud, then it's the hardest of all as switching SaaS cloud vendor will likely impact the business process and require user training.
> 'Lock-in' is a very over-used term, and almost always when someone is trying to justify why someone should choose opensource or generic x86 rather than something else.
Exactly. I have many examples of Linux to Solaris migrations where Linux as free product was more expensive than Solaris with paid support. All of such cases had reason to do exact such migration in use ZFS with compression.
I saw may times kind of fear of such migration only by lack of knowledge that such migration may save a lot of money. From this point of view such cases been pure proofs of 'lock-in' state but on mental level.
I don't know much about this product, but it has cannibalized pieces of Solaris into a VM-centric environment:
https://smartos.org/
This goes much further than OpenIndiana - it pulled KVM out of Linux and sunk it into the Illumos kernel.
Simple Solaris userspace can be implemented as a zone, or you can have a real Linux kernel if you want.
The node.js people came up with this. It's nice to see Solaris live on in new products.
> Oracle bought Sun so as to ...
No, Oracle bought Sun's HW business because Larry lost a game of golf with Scott.
The deal was if Larry won he was allowed to just buy the SW business which is the bit he wanted. If he lost he had to do what Scott wanted and buy the whole schbang.
I thought you guys covered this at the time.
What an odd article. No large computing platform uses Oracle hardware or software: Google, Facebook, Amazon, and so on. They don't even subcontract Oracle's engineering expertise to construct their own internal-use products.
What's left is really the crumbs, with an "enterprise" label whacked on. And those crumbs are under threat from the products developed or maintained by the large computing platforms: from Linux to OpenStack to Software Defined Networking. Worse still, despite the increased costs over Google, Facebook, etal the performance and uptime of enterprise applications is typically worse than the cloud applications.
Oracle is notorious for gobbling up companies only to assimilate, down-size and move on to the next venture, they remind me of the "Borg" from Star Trek. American companies get bought up only to be down sized and people let go and jobs eventually get outsourced to different “cost centers”. This is layman’s terms are areas in the world for where they can hire “support staff” cheaper than what they can hire them for in the US. All done to add to the black and increase revenue, all while Larry’s private islands gets a little bit bigger… Yes this is free enterprise and what a lot of big companies do, doesn’t make it right though…
They get companies that buy into the Oracle mindset of you need Oracle this and Oracle that. Once they drink the kool aid they are too far invested to get out. Java, java, java is also part of their sell... Java and kool aid don't mix and outside of Oracle, Java is not talked about very highly in my experience. Why doesn’t Google and Amazon use Oracle? Because they have probably seen the inside of an Oracle datacenter… Oracle is trying to move into that market, but I don’t think they can keep up... I personally wouldn't recommend drinking the big red O's kool aid... "Oh yeah!"
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
