While many Sun customers are up in arms over the silence over at Oracle, there have been a few blurbs here and there as to the future of the products we depend upon. Here are two good resources:
These atleast give some idea that Oracle is investing in Solaris, OpenSolaris, and a huge amount of Sun's software portfolio. This should ease some tensions, but Oracle definitely has to spend more effort to reassure customers. I am very happy to see commercials on TV again for Sun products:
Wednesday, June 09, 2010
Virtualization Product Landscape
The virtualization space has been growing by leaps and bounds. It has attracted vendors from all over the map to the party. Not to mention the evolution of virtualization into cloud computing. There has been an explosion of software products for creating, brokering, monitoring, securing, and managing virtual infrastructures. Keeping track of all of these developments is challenging to say the very least. However, I have found a good reference table that I wanted to share with everyone. Enjoy!
Brocade and Juniper Gang Up on Cisco
Over the past year, there has been a lot of buzz in the industry over Cisco with its UCS and Nexus 7000 products providing a converged fabric for virtualization, consolidation, and cloud computing needs. However, the problem with the Cisco party is that you're stuck with their framework and products. And while UCS is impressive, it doesn't address the need for 4-8 way socket servers, high performance I/O, or traditional I/O needs beyond networking and storage. And you may say, what kind of server would need that? How about a Netbackup media server, payment processing server with crypto cards, or a data warehouse? UCS is really targeted for general purpose usage. Many companies are finding that while blade servers have their place, rackmount servers have greater flexibility and less vendor lock-in. To help aid companies in this effort and still get the benefits of converged networks, Brocade and Juniper have jumped into the ring with their own converged networking products. Both products have different architectures, protocols, and features that will change the way networks are designed and used. Brocade seems to have a really innovative solution with its VCS architecture, TRILL protocol, QoS capabilities, and VM profiling.
These types of products will be the foundation of cloud computing by enabling low latency, scalable, and agile infrastructure for virtual machines, storage, and networking services. Would definitely like to test out these products with LDoms, Containers, and of course VMware.
These types of products will be the foundation of cloud computing by enabling low latency, scalable, and agile infrastructure for virtual machines, storage, and networking services. Would definitely like to test out these products with LDoms, Containers, and of course VMware.
Oracle and Fujitsu Signing up for APL2?
It would appear that Fujitsu and Oracle are going to renew the APL agreement for the next generation servers which should be based on the eight-core SPARC64 VIIIfx processor. This is the processor that is being used by the Japanese government to build a supercomputer. I wrote about this about a year ago and have been waiting to see if these processors would see the light of day in a commercial setting. It is interesting how the Sun and Fujitsu agreement back in 2004 lead to the M-Series servers, which have filled the gap left in the mid-range and high-end servers from Sun after the venerable UltraSPARC-IV+ servers were EOL'd. With an eight-core base, the next generation M-Series servers should be pretty impressive. I am curious if there will be over-lap between the T3 servers and these future M-series? Perhaps the T3 and T4 series will cover entry level up to something like an M5000 and the SPARC64 VIIIfx will cover the high-end. Only the future will tell.
More Layoffs? Really?
Well needless to say there are more lay-offs happening for freshly converted ex-Sun employees. I'm not surprised considering the size of the acquisition. But I do hope that these employees will either find their way back to Oracle or another company soon. These have been difficult economic times and hope the best for them.
UltraSPARC-T3 vs. Power 7
While we await the release of the UltraSPARC-T3 servers from Sun Oracle, the big question is how does it stack up against IBM's Power 7 processor?
Ars Technica took an interesting look at the feature set of the processors themselves in this article. One of the best lines in the article describing the differences between these processors is, "If Niagara 3 is an army of guys with shovels, POWER7 is a giant bulldozer". The T3 processor definitely takes prize for the largest amount of cores, threads, and I/O options integrated(Crypto, PCI-E, and 10GbE). However, the Power 7 processor makes up for this with heavy cores, higher clock speeds, an on-chip 32MB L3 cache, and large I/O and memory pipes. In many ways you can see how IBM learned a lot from Sun on building multi-core designs. One could even argue that IBM took the idea of a 32MB cache right from the UltraSPARC-IV+ playbook for addressing latency issues for heavy cores. And to think a few years ago IBM was laughing at Sun for the T1 processor saying that CMT wasn't relevant. Well always nice to see someone eat their own words and invest millions!
Hopefully we'll see the UltraSPARC-T3 servers appear soon before long to compete with IBM and show that Sun Oracle can still pack a bunch. Having a 1-4 socket server with UltraSPARC-T3 processors could lead to a new wave of ultra-dense SPARC servers for web, database, and throughput processing. When combined with LDoms and many of the networking and storage virtualization advancements in OpenSolaris, one has a killer product for new projects and consolidations.
Ars Technica took an interesting look at the feature set of the processors themselves in this article. One of the best lines in the article describing the differences between these processors is, "If Niagara 3 is an army of guys with shovels, POWER7 is a giant bulldozer". The T3 processor definitely takes prize for the largest amount of cores, threads, and I/O options integrated(Crypto, PCI-E, and 10GbE). However, the Power 7 processor makes up for this with heavy cores, higher clock speeds, an on-chip 32MB L3 cache, and large I/O and memory pipes. In many ways you can see how IBM learned a lot from Sun on building multi-core designs. One could even argue that IBM took the idea of a 32MB cache right from the UltraSPARC-IV+ playbook for addressing latency issues for heavy cores. And to think a few years ago IBM was laughing at Sun for the T1 processor saying that CMT wasn't relevant. Well always nice to see someone eat their own words and invest millions!
Hopefully we'll see the UltraSPARC-T3 servers appear soon before long to compete with IBM and show that Sun Oracle can still pack a bunch. Having a 1-4 socket server with UltraSPARC-T3 processors could lead to a new wave of ultra-dense SPARC servers for web, database, and throughput processing. When combined with LDoms and many of the networking and storage virtualization advancements in OpenSolaris, one has a killer product for new projects and consolidations.
The State of Things
Well the OpenSolaris OGB elections went well, but I did not make it onto the board this year. I'll try again next time. However, seeing how difficult things have been in the OpenSolaris community it can't be an easy time for the OGB. With the acquisition by Oracle, users, customers, and enthusiasts alike have been struggling to understand what the direction is at Oracle across the board for Sun products and even the communities. There was supposed to be another distribution release of OpenSolaris 2010.x, but it has not materialized which of course had caused "great confusion and delay". Many community members such as myself and Ben Rockwood have been vocal and cautious at the same time.
However, as Ben as pointed out, OpenSolaris was never fully out in the open and has always relied on the employed engineers at Sun, now Oracle. There are many reasons behind this that originate in politics, internal Sun processes, committees, etc. As a community we are truly left on the outside to take either the source code or the OpenSolaris distribution to use and tinker with. It does take discussions on the mailing lists, through bugs and RFE's, and community coordination with the perspective Oracle developers to cause change. Every time I find something, I'm not happy about, I file a bug or RFE on the OpenSolaris site and keep my eyes on things. Sadly this is as good as it gets right now. But what should it really be like?
One might think that having the code and processes completely opened would solve all of the issues. Unfortunately, one only has to look at Linux and any of the BSD's to see that any changes to the Kernel or core utilities is controlled by a tight-knit group of developers. Some are friendly and others are down right ruthlessly rude to out-siders. In much the same way that the OpenSolaris community struggles to get it's hands deep into the development cycle and sift through the bureaucracy of Sun/Oracle, developers in the Linux and BSD spaces have the same issues. The only real difference is that OpenSolaris development is owned and controlled by a company. The rest of the open source tools, libraries, and applications that all Unices leverage have their own ups and downs for developers and distribution builders alike.
So what is the real issue here in the OpenSolaris community? I would summarize the issues as the following:
So how should the community address these issues? Well the OGB should be focusing on addressing these issues in the open. That would mean they would have to pressure Oracle to be more involved, open, and to communicate. While the community is indeed very passionate about Solaris and OpenSolaris, I do believe the voice of reason bring things to a level playing field where all the stakeholders can mutually agree on how to address these issues. The OGB should organize a townhall meeting to tackle the issues at hand. Oracle has everything to gain by working with the community. It'll help build credibility, mind-share, and most importantly trust.
For example, if the community and the developers at Oracle were to work on building better processes and even standards for OpenSolaris, it would go a long way to mending the situation at hand. But the first step is for the OGB to act now and push Oracle into the right direction. Oracle has to listen to our community, because many of us are also their customers whether they know it or not.
However, as Ben as pointed out, OpenSolaris was never fully out in the open and has always relied on the employed engineers at Sun, now Oracle. There are many reasons behind this that originate in politics, internal Sun processes, committees, etc. As a community we are truly left on the outside to take either the source code or the OpenSolaris distribution to use and tinker with. It does take discussions on the mailing lists, through bugs and RFE's, and community coordination with the perspective Oracle developers to cause change. Every time I find something, I'm not happy about, I file a bug or RFE on the OpenSolaris site and keep my eyes on things. Sadly this is as good as it gets right now. But what should it really be like?
One might think that having the code and processes completely opened would solve all of the issues. Unfortunately, one only has to look at Linux and any of the BSD's to see that any changes to the Kernel or core utilities is controlled by a tight-knit group of developers. Some are friendly and others are down right ruthlessly rude to out-siders. In much the same way that the OpenSolaris community struggles to get it's hands deep into the development cycle and sift through the bureaucracy of Sun/Oracle, developers in the Linux and BSD spaces have the same issues. The only real difference is that OpenSolaris development is owned and controlled by a company. The rest of the open source tools, libraries, and applications that all Unices leverage have their own ups and downs for developers and distribution builders alike.
So what is the real issue here in the OpenSolaris community? I would summarize the issues as the following:
- Lack of communication on the roadmap and direction for OpenSolaris from Oracle
- Lack of community, customer, and end-user involvement in design decisions and standards
- Community dependence on an Oracle release of the official OpenSolaris distribution
- Difficult processes for developers to follow to contribute
- No accountability between the OGB and Oracle
So how should the community address these issues? Well the OGB should be focusing on addressing these issues in the open. That would mean they would have to pressure Oracle to be more involved, open, and to communicate. While the community is indeed very passionate about Solaris and OpenSolaris, I do believe the voice of reason bring things to a level playing field where all the stakeholders can mutually agree on how to address these issues. The OGB should organize a townhall meeting to tackle the issues at hand. Oracle has everything to gain by working with the community. It'll help build credibility, mind-share, and most importantly trust.
For example, if the community and the developers at Oracle were to work on building better processes and even standards for OpenSolaris, it would go a long way to mending the situation at hand. But the first step is for the OGB to act now and push Oracle into the right direction. Oracle has to listen to our community, because many of us are also their customers whether they know it or not.
Subscribe to:
Posts (Atom)