Mixed OS’s In An IDM Environment, Is It Kosher?
Over the years I have worked with a variety of environments running IDM instances. In most cases I have found that the environments are all kept the same. For example one instance was running all Microsoft Windows servers with similar processors, RAM, disk space, NIC cards, etc. Another instance was entirely run on VM’s using Linux with all VM’s configured to use the same amount of RAM and processor cores.
However, there have been times where I have come across environments where the IDM servers were not so similar. One in particular had multiple IDM servers where some servers were running Linux and some were running Windows. When I run across these configuration oddities it always prompts conversation. Usually that conversation consists of me wondering why they have an environment like that and them asking me if that is a bad thing. Ultimately the conversation always ends the same.
So, is it a bad thing to run an IDM environment with mismatched OS’s and/or hardware?
Mixed OS’s is never kosher for an IDM environment. In fact, I would suggest that is largely frowned upon for most applications, not just IDM, that support multiple OS’s. But for this article’s purpose I will focus on why you should not mix operating systems in an IDM environment.
There are many reasons why your IDM environment would be better served in a uniform environment. Let us count the ways…
Let’s face it, most operating systems require a license per instance that has be renewed at a fairly regular interval. If you are maintaining multiple operating systems within your IDM environment you are essentially requiring that you maintain multiple different licenses that may need to be renewed at different times at different costs. By keeping all servers in the environment similar it makes it much easier to ensure the servers are properly licensed at all times (which is a big help when it comes to audits!). This also helps in determining licensing budgets at it is easier to calculate how many licenses are needed.
While it is generally accepted that the IDM version that runs on Windows is the same as the version that runs on Linux we all know that is not entirely true. While the core application and functionality is the same between those versions there are inherent differences between them that allows them to run in their respective environments. The Windows version of IDM uses DLL’s and leverages things that are only available on a Windows server while the Linux version uses Linux specific code. It is what makes the operating systems different and as a result the applications running on them are different too. This means that in the core source code that there could be a bug that impacts the Windows version of IDM but not the Linux version of IDM or vice versa. So just because something is working on one server doesn’t mean that it will work on the other server and conversely just because something is broke on one server doesn’t mean it will be broke on the other server. This can make troubleshooting these types of issues very difficult because the different OS version is the last thing that is suspected because it is all the “same application”.
Getting help for a mixed environment can be challenging. Some support techs may be very knowledgable for one OS but not the other. Not to mention that as pointed out in #2 that some issues are present in IDM versions on one OS but not another. And to add to that fact, some versions of IDM are more popular than others. For example, IDM running on SUSE Linux is more commonly found than IDM running on Windows Server 2008 R2. This means that if you are running IDM on a Windows server and encounter a problem you are more likely to be the first to report the issue simply because there are fewer instances like yours in operation. This also means that since there are fewer versions of IDM running on Windows that bugs not only take longer to be found but also to be fixed. The reality is that if I have bug in a version being run on 80% of all instances and a bug in a version being run on 10% of all instances I will most likely fix the first bug as it has a greater impact on the user community.
Like everything else different OS versions will have different security issues and different security solutions. A firewall on a Linux server is vastly different than a firewall on a Windows server. So why complicate your life by needing to manage the same thing through different methods and interfaces? It is much easier and quicker to keep a consistent process across the environment, especially when it comes to security. The more variety you have to deal with between servers the more likely you are to make a mistake.
And similar to the security obstacles you have maintenance. Vendors are constantly issuing patches for this and for that. In a mixed environment you have to deal with different patch cycles, patch fixes, change control management, etc. And if you have a large environment with many servers this issue is only compounded because of the time and effort it can take to push patches out, restart servers/services and so on.
Maintenance issues are not only limited to the OS either. Sure there is “one” version of IDM running on all of the servers despite the OS but each one may be patched differently. There may be a patch to fix a memory leak in the Windows server but a different patch to fix a SOAP issue on a Linux server.
Let’s be real; we are not all experts in everything. This means that just because I am a Windows guy does not mean that I will be able to manage a Linux server with the same level of ease or speed. The same could be said for a Linux admin who is thrust into a Windows environment. The two operating systems are very far apart in management styles and skills needed to perform the various operations required to maintain a healthy server and IDM environment. Not many companies have administrators that are skilled equally in all operating systems. Most specialize in a particular vendor environment so when you have a mixed environment you either require multiple admins to gain the skill set needed to maintain all of the servers or leverage administrators who may have some knowledge limitations on one or more of the environment’s systems that could inhibit your ability to grow or resolve issues as quickly as you could.
From here we could just get into more nit-picky reasons why it is considered a bad idea to mix your OS versions and vendors in your IDM environment but I hope you get the gist of it by now. The number one reason most companies look to implement an IDM solution is to make things more efficient by automating and streamlining processes. When the IDM environment is built to match it allows for similar automation and streamlining of processes at the sever level that only enhances the system and its capabilities while reducing the amount of effort it takes administrators to build out and maintain that environment. If your company is willing to invest that kind of time and money to take that next step forward into the IDM space don’t make them take a step backwards by mix.