Where are operating systems heading? I haven't done any in depth evaluations of operating systems in a very long time. I've been working the application development side for a long while now. I still find the need to keep my working knowledge of the systems going from time to time. I recently, with the help of Sun's VirtualBox and Microsoft's Virtual Desktop, installed some of the latest releases of Fedora, OpenSolaris, SUSE and Microsoft's latest Windows 7.
First of all let me say that all of the operating systems installed without any issues at all. It was completely painless. The one interesting note, funny actually, was that Microsoft's Windows 7 beta would not install in their own virtual manager but installed without any issues in Sun's VirtualBox.
Looking at the OS's from a strictly desktop perspective the big thing that jumped out at me was nothing. Yep I saw nothing of real interest. That lead me to the question, have operating systems for the desktop reached a maturity level where changes now are incremental and uninteresting from business use perspective? Yes I can see where the technical operating system enthusiast would like the latest and greatest, but what is there or coming that would drive a corporation to want to upgrade? Upgrades of operating systems, especially desktop, can be pretty expensive and painful. There usually has to be a significant justification.
Microsoft has in the past been pretty successful at pushing folks to upgrade by simply forcing the issue. That strategy as of late hasn't worked as well. So where do operating systems go to make upgrading compelling? What does the typical operating system need to do for the corporate user? It needs security, it needs to run their office productivity apps (Work, Excel or OpenOffice etc) and it needs to be an effective container for their web applications. Is there really more than that? What is going to drive upgrades now?
Tuesday, January 13, 2009
Monday, January 12, 2009
Oracle Patching
Oracle has plans for a big security set of patches. Can we not just go Jack Bauer on these folks? I mean seriously enough is enough. Can't we just get some people with machine guns to go after these people, the hackers/crackers I mean, not Oracle. :)
Sunday, January 11, 2009
The Benefits of Open-Source Software
I was reading this thread on Open-Source ESB's at The Server Side and that got me pondering why more companies don't go after open-source software. While I am a fan of open-source in general I do see several issues for enterprise wide adoption. It also started me thinking why folks who are proponents of open-source in their enterprises really like open-source. Is it truly because it's open or is it because it is generally cheaper to initially acquire?
Let's start with the issues of open-source software. The two main ones are probably support and longevity. I haven't done any studies so this is just based of my experience but typically support is not used heavily for an enterprise class application. There maybe a few "serious" tickets in a given year for an application. Out of these "serious" tickets, how many are actually resolved by the vendor? There is a pretty big premium paid for that availability of support that is not used all that regularly. However it is there if you need it. The perception of open-source software is that in general you are on your own.
That perception is not always based in reality. A lot of the better open-source vendors have similar support offerings as the major proprietary vendors. Of course the cost of those open solutions goes up a lot when the support contracts are added on to the price. If you take a look at SUSE or Redhat on the OS side of things, you will find their support contracts comparable to Microsoft, Sun or HP in terms of cost. The down side to support contracts is that they can also require you to upgrade on the vendors schedule instead of yours.
The other issue with open-source is longevity of the vendor. The perception is that going the open-source route can be a gamble in terms of whether the vendor or users who maintain the code base will continue to exist. This is a legitimate concern but with a caveat. If the vendor or users no longer maintain the code, the source is open and in your possession. The real question is, is that a useful thing? Most enterprises usually negotiate with their proprietary software vendor a clause in their contract that says if the vendor goes out of business the company does get the source code. Is that useful? Would most enterprises be capable of doing anything with the source code?
I have never really bought into the proprietary argument of software. My opinion on this has always been the vast majority of enterprises are not equipped to or even should take advantage of having source code. Enterprise IT shops are there to provide business solutions not spend time on the platforms or packages that deliver those solutions.
There are some quality open-source software out there that many large enterprises and smaller companies should consider. There are cost savings and quality that can be gained by going that route. But you have to evaluate those cost closely with you existing proprietary solutions on an even basis. The upfront cost of software acquisition usually pales in comparison to the cost to maintain it. So while open-source is generally easier and cheaper to initially acquire, the long term maintenance of the software can be just as expensive as its proprietary counterpart.
Let's start with the issues of open-source software. The two main ones are probably support and longevity. I haven't done any studies so this is just based of my experience but typically support is not used heavily for an enterprise class application. There maybe a few "serious" tickets in a given year for an application. Out of these "serious" tickets, how many are actually resolved by the vendor? There is a pretty big premium paid for that availability of support that is not used all that regularly. However it is there if you need it. The perception of open-source software is that in general you are on your own.
That perception is not always based in reality. A lot of the better open-source vendors have similar support offerings as the major proprietary vendors. Of course the cost of those open solutions goes up a lot when the support contracts are added on to the price. If you take a look at SUSE or Redhat on the OS side of things, you will find their support contracts comparable to Microsoft, Sun or HP in terms of cost. The down side to support contracts is that they can also require you to upgrade on the vendors schedule instead of yours.
The other issue with open-source is longevity of the vendor. The perception is that going the open-source route can be a gamble in terms of whether the vendor or users who maintain the code base will continue to exist. This is a legitimate concern but with a caveat. If the vendor or users no longer maintain the code, the source is open and in your possession. The real question is, is that a useful thing? Most enterprises usually negotiate with their proprietary software vendor a clause in their contract that says if the vendor goes out of business the company does get the source code. Is that useful? Would most enterprises be capable of doing anything with the source code?
I have never really bought into the proprietary argument of software. My opinion on this has always been the vast majority of enterprises are not equipped to or even should take advantage of having source code. Enterprise IT shops are there to provide business solutions not spend time on the platforms or packages that deliver those solutions.
There are some quality open-source software out there that many large enterprises and smaller companies should consider. There are cost savings and quality that can be gained by going that route. But you have to evaluate those cost closely with you existing proprietary solutions on an even basis. The upfront cost of software acquisition usually pales in comparison to the cost to maintain it. So while open-source is generally easier and cheaper to initially acquire, the long term maintenance of the software can be just as expensive as its proprietary counterpart.
Wednesday, January 07, 2009
Sun's xVM VirtualBox
If you are looking for a cheap(free) VM solution for your desktop, take a look at Sun's xVM VirtualBox. I was amazed and just how simple and easy it was to get up and running. I had Solaris 11 and the latest Fedora up and running in less than 1/2 hour. And most of that was download time. Sun really doesn't do a very good job of advertising some very good software products. Netbeans for example is a better Java IDE than Eclipse. But you would never know it.
Monday, January 05, 2009
SOA versus SOI continued
Five or six years into the discussion (or 20 depending on who you ask), the debate is still going on what SOA is and what SOA is not. Is it any wonder folks are questioning SOA's value? We are still having debates on what it is. Here are a few links in case you are still recovering from New Years. My take on this is below the links.
David Linthicum's take
Anne Thomas Manes take. Love the cartoon by the way.
Zapthink's take
Joe McKendrick's take
Most of the current discussion is around the role of Integration in SOA. The discussion is fairly well covered in the above posts. I would add that agility was a goal of EAI. Agility was achieved by the construction of loosely coupled services within the EAI framework. Yes services existed, do exist, within the EAI space. EAI was not about connecting System A to System B. It was not about data synch or data replication. That stuff is basic integration. EAI was about abstraction, reuse and agility. Don't believe me? Do a search on EAI and see what the vendors and analyst were talking about.
The problem with EAI then is the same problem with SOA now. Only a handful of companies understood it and even fewer could implement it. It was hard and it took more effort. A lot folks went out and bought EAI packages and thought that was going to do it for them. Abstraction, reuse, agility, decoupling the enterprise comes from hard work, solid architecture and standards. There are not any shortcuts that software or packages provide. At the same time it doesn't have to be rip and replace. Start small and get good at it.
David Linthicum's take
Anne Thomas Manes take. Love the cartoon by the way.
Zapthink's take
Joe McKendrick's take
Most of the current discussion is around the role of Integration in SOA. The discussion is fairly well covered in the above posts. I would add that agility was a goal of EAI. Agility was achieved by the construction of loosely coupled services within the EAI framework. Yes services existed, do exist, within the EAI space. EAI was not about connecting System A to System B. It was not about data synch or data replication. That stuff is basic integration. EAI was about abstraction, reuse and agility. Don't believe me? Do a search on EAI and see what the vendors and analyst were talking about.
The problem with EAI then is the same problem with SOA now. Only a handful of companies understood it and even fewer could implement it. It was hard and it took more effort. A lot folks went out and bought EAI packages and thought that was going to do it for them. Abstraction, reuse, agility, decoupling the enterprise comes from hard work, solid architecture and standards. There are not any shortcuts that software or packages provide. At the same time it doesn't have to be rip and replace. Start small and get good at it.
Subscribe to:
Posts (Atom)