Manage Learn to apply best practices and optimize your operations.

Software stacks: Mixing proprietary and open source

In this tip, the author of Wiley's "Open Source: The Unauthorized White Papers" recommends some basic rules for designing your own software stack, what components to upgrade and when to consider replacing the whole stack or just a piece of it.

When designing a stack with proprietary and open source software components, be as modular as possible, says Don...

Rosenberg, President of Stromian Technologies. This will allow IT shops to switch software in and out more easily.

More on open source software:
Open source code: Incorporation, release and enterprise evaluation

How to switch an enterprise to OSS, part one

In this tip, the author of Wiley's Open Source: The Unauthorized White Papers recommends some basic rules for designing your own software stack, what components to upgrade and when to consider replacing the whole stack or just a piece of it.

What are some rules for designing a mixed stack with open source and proprietary software?

Don Rosenberg: In the old days, the same vendor sold you your hardware, operating system and apps, and you had no choice. If you still like buying it all in the same place, Sun and IBM are still happy to oblige.

While some people like buying the "best of breed" for various applications, there is also a tendency to like simplified choices. The office suite, for instance, gives you once of each kind of commonly-used desktop software. Not only do customers like this simplified approach but many vendors like it, too.

The software stack presents us with the same sort of problem: best-of-breed or single-supplier? It is widely-distributed industry standards (and open standards) that have pushed the software stack, the ability to pick OS, utility layer, databaseand applications.

The vendor faces the same pressures and choices as you in how the stack is constructed. The crucial difference is that the vendor is likely to wrap his stack tightly to discourage you from tampering with it (that's what his maintenance contract is for). On the other hand it is vital for you to be as modular as possible in designing your own stack so that you can substitute components more easily.

Modularity is a fundamental building block of open source. You can't get experts to volunteer if they have to learn all the intertwined code of a project, rather than just working on one portion of it (it's the project leader who keeps the modules coordinated). By ensuring the components are kept modular, that is, loosely connected with as few interdependencies as possible, you add to your ease in switching them in and out.

How can mixed stacks be cost-efficient? Wouldn't it be better just to go completely open source?

Rosenberg: Both you and the stack vendor want to keep the cost down, so you will both use open source components at the bottom. The OS will be open source. As you move up the stack, look for open source components that will do the job. As open source and commoditization move up the stack, it becomes easier to find such components.

The components that make the difference and give you a significant ($) business advantage are at the top of the stack. If these components are really cutting-edge and confer a significant benefit, they are very likely proprietary (if everyone could have them for free, how would they give you an edge over everyone else?). If they really earn you more money than free components would, then they are worth paying for.

Or you could build your own high-level, advantage-giving components. Then no one else would have them. Do you have the in-house developer power to do this?

Once again, you are facing the same decisions as the stack vendor. The stack vendor is going to deliver a mixed stack because he believes that the proprietary software will be worth the money to the buyer, and earn him more money than would a stack made up of only open source software. Most solution stacks sold today are mixed proprietary and open source.

Application vendors have to keep adding features to their applications to stimulate buyers to purchase and to upgrade. Now that the action is moving to stacks, they are trying to make their stacks as tall as possible, from OS at the bottom to proprietary apps on top. IBM is an example, so is Sun,and Novell is offering a mixed stack has SUSE Linux on the bottom and IBM WebSphere on top. Because this is a complete solution, the vendor had better be able to show the buyer that not only are the components superb, every one, but that they work so well with each other as to provide a value beyond the sum of their parts.

If you are still building your own stack, then you will have to do all the tuning and testing that you would expect to find in a vendor-supplied stack. Your distro will work only on certain hardware, and your layers and applications above that will be tuned for the distro you choose. So you need to build your stacks from the machine up to make sure they will work properly, and that you will have minimal trouble switching components in and out. Your stack vendor would take care of all this for you, but then you would be locked in, and unable to make fundamental changes in the system.

But if you build your own, you can make it work the way you want it to, and hopefully in a way that surpasses your competitors. And because you will not be distributing this software outside your company, you don't have to worry about relations between GPL 2.0 software and other software. Nor will you have to share any secrets just because you are using open source software.

What is a partial stack upgrade? Can an IT shop upgrade part of the stack without affecting the rest of the components?

Rosenberg: In answering many of the questions, you may notice that I vary between the Geek Answer and the Suit Answer. The Geek will take advantage of open source to do everything in house, relying on his own capabilities. The Suit is often more inclined to outsource solutions, unless he is convinced that in-house staff can handle them. Suits may figure that it is easier to change vendors than to hire/train employees.

The short answer is, if you are changing only one component in a stack that works, then you will need to tune and test to make sure that the upgrade hasn't broken anything. This is the in-house solution. The supplier of the stack component you are changing may be able to tell you whether it has been tested with the configuration you are using, but always verify for yourself.

If you don't believe you have the necessarily capability in-house, then there are vendors who will sell you stacks that are guaranteed to work properly; these vendors will also sell you upgrade and support plans to cover problems along the way and supply improvements as they become available.

So, when should IT shops consider upgrading a LAMP stack?

Rosenberg: This is a pretty general question, so there are number of ways to answer it. The simplest is to guess that you probably got all the elements for your LAMP stack from the same place: your Linux distribution,the "L" part of the stack. This is fine. It's part of the added value of a distro to give you lots of software, all of it tuned and tested to work with the distro you receive. So the simple answer is: upgrade your LAMP stack when you upgrade your operating system.

Other than that, is there some performance objective that is not being met? Would you like a more secure version of Apache, for instance? In that case you might find one for free, or you might want to pay for one, and then substitute it in the stack for the one that came with your distro. You may find that your substitute comes in different flavors to work with different distros.

Dig Deeper on Linux servers

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.